Zakaj je marketplace aplikacija zahtevnejša od običajne mobilne aplikacije

Marketplace aplikacija je zahtevnejša, ker ne podpira samo enega uporabniškega toka. Uskladiti mora dve ali več strani trga, njuno razpoložljivost, zaupanje, komunikacijo, plačila, odpovedi in spore. Poleg mobilnega vmesnika potrebuje tudi operativna orodja za ljudi, ki skrbijo za delovanje platforme.

Rezervacija ali naročilo je vidni del sistema. Zahtevnost nastane pri vseh stanjih pred njim in po njem.

Dve strani pomenita dva onboardinga

Kupec in ponudnik ne potrebujeta iste registracije.

Kupec običajno želi hitro raziskati ponudbo in izvesti dejanje. Ponudnik mora morda vnesti profil, območje delovanja, razpoložljivost, način izplačila in dokazila.

Za vsako stran določite:

• katere podatke potrebuje;
• kdaj jih mora vnesti;
• kaj je treba preveriti;
• kdo lahko profil odobri;
• kaj se zgodi ob zavrnitvi;
• kako pozneje spremeni podatke.

Če od ponudnika zahtevate preveč pred prvo zaznano vrednostjo, onboarding postane ovira. Če zahtevate premalo, lahko manjkajo podatki, potrebni za varno izvedbo naročila.

Zaupanje zahteva pravila in moderiranje

Marketplace mora pomagati neznanim stranem oceniti, ali lahko sodelujeta.

To lahko vključuje profile, preverjanje podatkov, ocene, poročanje, fotografije, pogoje odpovedi in podporo. Vsak mehanizem potrebuje pravila:

• Kdo lahko odda oceno?
• Po katerem dogodku?
• Ali jo je mogoče izpodbijati?
• Kaj pomeni preverjen profil?
• Kdo pregleda prijavo?
• Kdaj se račun omeji?
• Kako se prepreči povračilno ocenjevanje?

Moderiranje ni samo gumb »prijavi«. Potrebuje čakalno vrsto, kontekst, odločitev in zapis ukrepa.

Pravila ter pravne obveznosti so odvisni od modela, podatkov in trgov. Zahtevajo ustrezno strokovno presojo zunaj samega razvoja aplikacije.

Iskanje mora upoštevati resnično razpoložljivost

Marketplace katalog ni nujno statičen seznam.

Rezultati so lahko odvisni od:

• lokacije;
• termina;
• zmogljivosti;
• območja dostave;
• kategorije;
• cene;
• statusa ponudnika;
• posebnih omejitev.

Če se razpoložljivost spreminja, mora sistem preprečiti, da dva uporabnika potrdita isti omejeni termin ali vir. To zahteva jasna stanja rezervacije, časovne omejitve in pravila ob sočasnih dejanjih.

Razvrščanje rezultatov mora biti razložljivo vsaj ekipi, ki upravlja platformo. Skriti ali nenadzorovani kriteriji otežijo podporo in lahko ustvarijo nepredvidljive rezultate.

Plačilo ni enako izplačilu

Običajna aplikacija lahko sprejme plačilo za lasten produkt. Marketplace pogosto posreduje med kupcem in ponudnikom.

Določiti mora:

• kdaj se kupca bremeni;
• kdaj se sredstva izplačajo;
• kdo zadrži provizijo;
• kaj se zgodi ob odpovedi;
• kdo lahko odobri vračilo;
• kako se obravnava delno opravljena storitev;
• kaj se zgodi ob neuspelem izplačilu;
• kdo vidi finančno stanje.

Ponudnik plačilnih storitev, države delovanja in poslovni model vplivajo na razpoložljive možnosti. Teh pravil ni smiselno odložiti do izdelave checkout zaslona, saj vplivajo na podatkovni model naročila.

Spori potrebujejo dokazljivo časovnico

Ko strani ne soglašata, podpora potrebuje več kot zadnje stanje naročila.

Koristni so:

• čas rezervacije in sprememb;
• sprejeti pogoji;
• komunikacija;
• status plačila;
• odpovedi;
• predloženi dokazi;
• posegi administratorja.

Pomembna dejanja naj tvorijo revizijsko sled. S tem lahko ekipa ugotovi, kaj se je zgodilo, ne da bi ugibala iz nepovezanih sporočil.

Vnaprej določite tudi, katera dejanja lahko podpora izvede: vračilo, ponovitev izplačila, omejitev računa ali popravek statusa.

Obvestila morajo slediti stanjem

Marketplace pogosto uporablja e-pošto, push obvestila in sporočila v aplikaciji. Vsak kanal naj ima jasen namen.

Obvestilo mora nastati ob zanesljivem dogodku, na primer potrditvi, spremembi termina, odpovedi ali sporu. Pri tem preverite:

• komu se pošlje;
• ali vsebuje občutljive podatke;
• kaj se zgodi ob neuspešni dostavi;
• ali uporabnik isto informacijo vidi v aplikaciji;
• ali ponoven dogodek ustvari podvojeno sporočilo.

Obvestilo ni vir resnice. Končno stanje mora ostati v aplikaciji.

Operativni panel je del produkta

Ekipa potrebuje način za upravljanje ponudnikov, naročil, prijav, sporov, vračil in sistemskih napak.

Administratorski vmesnik mora imeti lastne vloge, omejitve in beleženje dejanj. Popoln dostop za vsakega člana podpore je preprost za razvoj, vendar tvegan za delovanje.

Operativna orodja vključite v obseg prve izdaje. Brez njih platforma morda podpira idealen tok, ne pa resničnih težav.

Prvo izdajo omejite po trgu in poteku

Dober MVP za tak produkt lahko začne z:

• enim tipom ponudbe;
• enim trgom ali območjem;
• enim načinom rezervacije;
• omejenim številom vlog;
• enim plačilnim tokom;
• ročno podprtim reševanjem izjem.

Odložite funkcije, ki ne preverjajo osrednje predpostavke, vendar ne odložite osnovne izolacije podatkov, statusov naročila, podpore in finančne sledljivosti.

Tehnološko odločitev dodatno obravnava primerjava React Native in native razvoja. Za načrtovanje mobilne aplikacije lahko glavni tok in strani trga opišete prek kontakta.

← Nazaj na blog