Web shop prerasta u marketplace onda kada na istoj platformi ne prodajete samo sopstveni katalog, već omogućavate i drugim prodavcima da ponude robu ili usluge kupcima. Tada više nije dovoljno dodati još jedan filter, kategoriju ili način plaćanja. Potrebno je rešiti odnose između kupca, platforme i prodavca, kao i pitanje ko upravlja proizvodima, porudžbinama, isporukom, povraćajima i novcem.
Ova razlika je važna i za planiranje izrade. Klasičan web shop ima jednog trgovca, dok marketplace uvodi više naloga sa različitim pravima, potencijalno različitim uslovima prodaje i složenijim tokom transakcije. Zato izrada web shopa može biti početna osnova, ali marketplace funkcionalnost treba posmatrati kao poseban poslovni i tehnički model, a ne kao dodatak koji se uključuje na kraju projekta.
Kako prepoznati da je potreban marketplace model
Najkorisnije pitanje nije „da li nam treba marketplace funkcionalnost“, već „ko učestvuje u prodaji i čiji se podaci i novac obrađuju“. Ako platforma treba da poveže više nezavisnih prodavaca sa kupcima, marketplace model je verovatno opravdan.
- Više prodavaca: različite kompanije ili preduzetnici samostalno nude proizvode.
- Jedna korisnička pretraga: kupac pronalazi ponude različitih prodavaca kroz isti katalog ili kategorije.
- Odvojeno upravljanje: prodavac treba da uređuje svoj katalog, cene, zalihe ili status porudžbine.
- Platformska provizija: vlasnik platforme naplaćuje članarinu, proviziju, naknadu po transakciji ili kombinaciju modela.
- Više strana u isporuci i podršci: prodavac može biti odgovoran za pakovanje i slanje, dok platforma upravlja pravilima i komunikacijom.
Suprotan primer je web shop sa jednim pravnim prodavcem koji nabavlja robu od više dobavljača, ali kupcu prodaje pod jednim brendom i kroz jedan ugovor. Takav katalog može biti velik i operativno zahtevan, ali sam po sebi nije marketplace.
Marketplace nije samo veći katalog
U klasičnom shopu proizvod pripada jednom trgovcu, a porudžbina se najčešće obrađuje kroz jednu prodajnu organizaciju. U marketplace-u se jedan checkout može odnositi na više prodavaca, pa sistem mora da zna kako se glavna porudžbina deli, kome pripada koja stavka i kako se prate različiti statusi.
Na primer, kupac može u jednoj korpi izabrati telefon od prodavca A i masku od prodavca B. Platforma tada mora da odluči da li kupac plaća jednu ukupnu dostavu ili više njih, da li se porudžbina razdvaja po prodavcu, kako se obračunava provizija i ko obrađuje eventualni povraćaj samo jedne stavke.
| Oblast | Klasičan web shop | Marketplace |
|---|---|---|
| Prodajni nalog | Jedan trgovac ili jedna organizacija | Više prodavaca sa sopstvenim nalozima |
| Katalog | Jedna kontrola nad proizvodima | Deljeni standardi i kontrola po prodavcu |
| Porudžbina | Jedan tok obrade | Moguće deljenje na podporudžbine |
| Plaćanje | Novac ide jednom trgovcu | Potrebno je obračunati provizije i raspodelu |
| Podrška | Jedna odgovorna strana | Jasno definisane obaveze platforme i prodavca |
Ključne funkcionalnosti marketplace platforme
Registracija i onboarding prodavaca
Prodavac ne bi trebalo da bude samo još jedan tip korisnika bez jasno definisanog procesa. Potrebni su registracija, unos osnovnih podataka, prihvatanje uslova, eventualna verifikacija i status odobrenja. U zavisnosti od modela poslovanja, mogu biti potrebni podaci o pravnom licu, poreskom statusu, računu za isplatu i osobi ovlašćenoj za upravljanje nalogom.
Važno je predvideti statuse kao što su nacrt, na proveri, aktivan, privremeno blokiran i zatvoren. Tako se razdvaja prijem prodavca od njegove dozvole da objavljuje ponude ili prima porudžbine.
Profil prodavca i upravljanje ponudama
Profil može sadržati naziv, opis, kontakt, lokaciju, ocene i pravila isporuke. Prodavac kroz svoj panel treba da upravlja samo podacima za koje ima ovlašćenje. Platforma, s druge strane, mora da zadrži kontrolu nad kategorijama, obaveznim atributima, kvalitetom sadržaja i pravilima objavljivanja.
Posebnu pažnju zahtevaju proizvodi koje nudi više prodavaca. Tada treba odlučiti da li postoji jedan zajednički proizvod sa više ponuda ili svaki prodavac kreira zaseban proizvod. Prvi model olakšava poređenje cena, dok drugi daje veću slobodu prodavcima, ali može dovesti do duplikata i neujednačenog kataloga.
Korpa, checkout i podela porudžbine
Checkout mora jasno da prikaže šta kupac kupuje, od koga, po kojoj ceni i pod kojim uslovima. Kada korpa sadrži proizvode više prodavaca, sistem može formirati jednu glavnu porudžbinu sa povezanim podporudžbinama. To omogućava da se dostava, statusi i komunikacija prate odvojeno, dok kupac i dalje dobija koherentno iskustvo.
Ne treba unapred pretpostaviti da je objedinjeni checkout uvek najbolji. Ako prodavci imaju različite zone dostave, rokove, načine plaćanja ili pravila povraćaja, razdvajanje korpe može biti razumljivije i operativno sigurnije. Za odluku je korisno mapirati konkretne scenarije, uključujući otkazivanje jedne stavke, delimičan povraćaj i neuspešnu isporuku.
Pravila za kupovinu bez registracije ostaju važna i u marketplace modelu. Guest checkout u web shopu treba povezati sa identifikacijom porudžbine, obaveštenjima i podrškom, bez kreiranja nejasnog naloga za svakog prodavca ili kupca.
Provizije, isplate i finansijski statusi
Marketplace mora da razlikuje iznos koji plaća kupac, prihod prodavca, proviziju platforme, naknade procesora plaćanja, troškove dostave, popuste i eventualne poreze. Ovi iznosi ne smeju biti samo tekstualna polja u administraciji. Potrebno je definisati pravila obračuna i sačuvati trag o tome kako je određeni iznos nastao.
Isplata prodavcu može biti trenutna, periodična, odložena do potvrde isporuke ili uslovljena drugim događajem. Izbor zavisi od poslovnog modela, ugovora, rizika povraćaja i podržanog payment rešenja. Servisi za marketplace plaćanja, poput Stripe Connect-a, imaju posebne tokove za povezivanje naloga, prikupljanje uplata i transfer sredstava, ali konkretna implementacija mora da prati dostupnost servisa, lokalne uslove i pravnu procenu.
Administracija bi trebalo da prikazuje najmanje: bruto iznos porudžbine, iznos provizije, neto iznos prodavca, status plaćanja, status isplate i korekcije. Bez toga je teško rešavati reklamacije, uskladiti finansije i objasniti prodavcu zašto je isplaćen određeni iznos.
Porudžbine, dostava, povraćaji i reklamacije
Marketplace treba unapred da definiše ko menja status porudžbine i ko dobija obaveštenje. Prodavac može ažurirati pripremu i slanje, dok platforma prati rokove, eskalacije i komunikaciju. Ako se statusi automatski sinhronizuju sa eksternim sistemom, treba rešiti i situacije u kojima podaci kasne ili se razlikuju.
Povraćaj novca nije samo dugme u administraciji. Za svaku stavku treba znati ko je prodavac, koji iznos se vraća, kako se koriguje provizija i da li se vraćaju troškovi dostave. Pravila treba prikazati kupcu pre kupovine, a ne tek kada nastane problem.
Čak i kada platforma ne skladišti robu, kupac je doživljava kao jedinstveno mesto kupovine. Zato treba odrediti da li platforma prima prvi zahtev, prosleđuje ga prodavcu ili ima sopstveni proces medijacije.
Katalog, pretraga i kvalitet ponude
Marketplace katalog brzo postaje heterogen: različiti prodavci mogu koristiti različite nazive, jedinice mere, fotografije i opise za slične artikle. Zato su taksonomija, obavezni atributi i validacija važniji nego u jednostavnom katalogu.
Filteri mogu pomoći kupcu, ali loše modelovani atributi stvaraju duplikate, prazne kombinacije i veliki broj indeksabilnih URL-ova. Pre dizajna faseta treba odrediti koji atributi služe za filtriranje, koji za poređenje, a koji su samo informativni. Više o toj odluci objašnjava tekst filteri i faceted navigation: kako izbeći UX i SEO probleme.
Promocije su još složenije kada popust finansira platforma, prodavac ili obe strane. Pravilo mora da navede na koje proizvode se odnosi, da li se može kombinovati sa drugim popustom, kako se deli na stavke i kako utiče na proviziju. Za praktičan nastavak pogledajte modelovanje kupona i promocija bez tehničkog duga.
Model odgovornosti pre izbora tehnologije
Najskuplje greške nastaju kada se tehničko rešenje bira pre nego što su definisana pravila poslovanja. Pre razvoja treba odgovoriti na nekoliko pitanja:
- Ko je formalni prodavac prema kupcu?
- Ko odobrava prodavce i njihove proizvode?
- Ko određuje cenu, popust, dostavu i rok isporuke?
- Ko prima novac i kada se vrši isplata?
- Ko rešava povraćaj, reklamaciju i spor između kupca i prodavca?
- Da li jedna porudžbina može obuhvatiti više prodavaca?
- Koji događaj menja finansijski status transakcije?
Odgovori utiču na arhitekturu, korisničke uloge, administraciju, integraciju plaćanja i sadržaj uslova korišćenja. Ako je potreban širi sistem sa portalima, internim procedurama i integracijama izvan prodaje, korisno je razmotriti i izradu sajta kao šire digitalne platforme, umesto da se sve pokušava smestiti u postojeći shop.
Kako ograničiti prvi obim marketplace projekta
Prva verzija ne mora da podrži svaki mogući model. Razumnije je izabrati ograničen scenario, na primer jednu kategoriju, jedan tip prodavca, jedno pravilo provizije i jednu logističku proceduru. Tako se proverava da li korisnici razumeju ponudu i da li prodavci mogu samostalno da obavljaju osnovne zadatke.
U početni obim obično imaju smisla:
- registracija i odobravanje prodavaca;
- upravljanje profilom i osnovnim katalogom;
- moderacija ponuda;
- korpa i checkout sa jasno definisanim scenarijem;
- statusi porudžbine i osnovna obaveštenja;
- obračun provizije i izveštaj za administraciju;
- pravila povraćaja i kontakt za podršku.
Napredne ocene, aukcije, pretplate, više valuta, automatska raspodela složenih dostava i detaljna analitika mogu doći kasnije, ako za njima postoji potvrđena potreba. Ograničen početak nije isto što i površno rešenje: ključni model podataka i finansijski trag treba postaviti tako da kasnije proširenje ne zahteva prepravku svake porudžbine.
Marketplace kao sledeća odluka, ne kao ukrasna funkcija
Pravi trenutak za marketplace nastaje kada poslovni model zaista zavisi od više prodavaca i kada postoji jasan razlog da kupac njihove ponude vidi na jednom mestu. Ako je cilj samo proširenje sopstvenog kataloga, klasičan web shop može biti jednostavniji, pregledniji i lakši za operativno upravljanje.
Sledeći korak je da se nacrta tok jedne konkretne porudžbine: od registracije prodavca i objave ponude, preko checkouta i isporuke, do isplate i eventualnog povraćaja. Taj scenario otkriva koje funkcionalnosti su stvarno potrebne i daje dobru osnovu za specifikaciju, procenu i izbor tehnologije. Tek nakon toga ima smisla razmatrati konkretno marketplace development rešenje i njegovu integraciju sa web shopom.
