B2B web shop treba da prilagodi kupovinu odnosu između firmi, a ne samo da prikaže katalog proizvoda na internetu. U praksi to najčešće znači da različite firme vide različite cenovnike, da jedna firma može imati više korisnika, da se nalozi odobravaju po pravilima i da se veleprodajna porudžbina obrađuje drugačije od maloprodajne.
Najvažnija odluka nije izbor boje ili teme, već model poslovnih pravila: ko sme da vidi cene, ko može da naruči, ko odobrava porudžbinu, kako se određuju minimalne količine i kako se podaci o firmi prenose u administraciju, ERP ili računovodstveni proces. Ako su ta pravila precizna, izrada web shopa može da bude zasnovana na stvarnom procesu prodaje, umesto na naknadnim zakrpama.
Ovaj vodič se fokusira na B2B pod-intent: cenovnike, firme, korisničke naloge, odobrenja i veleprodajnu logiku. Ne zamenjuje opštu stranicu o izradi prodavnice, već pomaže da se pre projekta definiše šta B2B kanal mora da radi.
Šta B2B web shop mora da razlikuje od maloprodajnog
U maloprodajnom web shopu kupac je često jedna osoba sa jednom adresom, jednom cenom i jednostavnim checkoutom. U B2B okruženju kupac je najčešće organizacija sa više kontakata, ugovorenim uslovima i internim procedurama. Zbog toga se isti proizvod može prikazivati različito zavisno od firme, korisničke uloge ili statusa naloga.
- Firma: pravno ili poslovno lice kome pripadaju narudžbine, adrese, uslovi plaćanja i cenovnik.
- Korisnik firme: osoba koja pregleda katalog, pravi korpu, šalje zahtev ili odobrava kupovinu.
- Cenovnik: skup cena i pravila koji važi za određenu firmu, grupu kupaca ili kanal.
- Odobrenje: korak između kreiranja korpe i konačnog slanja porudžbine.
- Veleprodajna logika: minimalne količine, pakovanja, količinski popusti, dostupnost i posebni uslovi isporuke.
Ove funkcije ne moraju sve biti uključene u prvu verziju. Važno je, međutim, da se od početka zna koje pravilo pripada katalogu, koje nalogu firme, a koje procesu obrade porudžbine.
Model firmi i korisničkih uloga
Prvi korak je definisanje strukture naloga. Jednostavan model „jedan email = jedan kupac“ brzo postaje ograničenje kada firma želi da više zaposlenih koristi isti B2B kanal.
Jedna firma, više korisnika
Firma može imati glavnog administratora, komercijalistu, osobu koja kreira porudžbine i osobu koja ih odobrava. Svi mogu raditi u okviru iste organizacije, ali sa različitim dozvolama. Na primer, komercijalista može da vidi ugovorene cene i pripremi korpu, dok finansijski ili nadređeni korisnik potvrđuje slanje.
Pre razvoja treba zapisati najmanje sledeće:
- da li jedna firma može imati više lokacija i adresa isporuke;
- da li korisnici vide sve porudžbine firme ili samo svoje;
- ko menja podatke firme i kontakt osobe;
- da li je registracija otvorena ili je nalog aktivan tek nakon provere;
- da li jedan korisnik može biti povezan sa više firmi;
- šta se dešava kada korisnik napusti firmu ili mu se promeni uloga.
Ovo nisu samo UX detalji. Pogrešna dozvola može omogućiti da korisnik vidi tuđi cenovnik, narudžbine ili poslovne podatke. Zato se matrica uloga definiše pre izrade interfejsa i testira kroz konkretne scenarije.
Otvorena registracija ili ručno odobrenje
Otvorena B2B registracija može ubrzati dolazak novih kupaca, ali zahteva proveru podataka i kontrolu pristupa. Ručno odobrenje daje veću kontrolu nad time ko dobija veleprodajne cene, ali uvodi dodatni korak u prodajni proces.
Čest kompromis je da korisnik može da pošalje zahtev za B2B nalog, ali da cene, naručivanje i posebni uslovi postanu dostupni tek nakon interne provere. Statusi poput „zahtev primljen“, „u proveri“, „odobren“ i „odbijen“ treba da budu jasni i administratoru i korisniku.
Cenovnici: više od jedne cene po proizvodu
B2B cenovnik može biti jednostavan, na primer „svi odobreni kupci dobijaju veleprodajnu cenu“, ali često postoji više nivoa. Cena može zavisiti od firme, kategorije kupca, količine, proizvoda, perioda važenja ili kombinacije tih faktora.
| Pravilo | Primer | Rizik za proveru |
|---|---|---|
| Grupa kupca | distributer, reseller, poslovni korisnik | šta se dešava kada firma promeni grupu |
| Poseban cenovnik | dogovorene cene za konkretnu firmu | prioritet u odnosu na opšti popust |
| Količinski prag | druga cena od određene količine | da li se prag računa po artiklu ili korpi |
| Vremensko pravilo | akcijska ili ugovorena cena do određenog datuma | isticanje i povratak na osnovnu cenu |
| Pakovanje | prodaja po kutiji, paleti ili minimalnoj seriji | jasan prikaz jedinice mere |
Pre implementacije treba napraviti tabelu prioriteta. Ako firma ima individualnu cenu, količinski popust i promociju, sistem mora znati koje pravilo ima prednost. Bez toga administrator može dobiti neočekivanu cenu, a kupac nejasan obračun u korpi.
Prikaz cena i pristup katalogu
Postoje najmanje tri uobičajena modela:
- Cene vidljive svima: javni katalog sa B2B cenama ili početnim cenama.
- Cene vidljive nakon prijave: neregistrovani posetioci vide proizvode, ali ne i ugovorene iznose.
- Cene vidljive nakon odobrenja: nalog može biti kreiran, ali se cenovnik prikazuje tek kada administrator potvrdi firmu.
Izbor zavisi od prodajne politike. Ako je cena poslovno osetljiva, skrivanje može biti opravdano, ali ne treba da zameni jasnu komunikaciju. Korisnik treba da zna da li će cenu dobiti nakon registracije, upita ili odobrenja naloga.
Odobrenja i interna kontrola porudžbine
Odobrenje je potrebno kada osoba koja naručuje nema pravo da samostalno obaveže firmu. Najjednostavniji tok je: korisnik pravi korpu, šalje je na odobrenje, odobravalac proverava stavke i porudžbina tek tada prelazi u obradu.
Složeniji model može imati različite pragove. Na primer, porudžbine do internog limita šalju se direktno, dok veće zahtevaju dodatnu potvrdu. Druga varijanta je da se odobrenje traži samo za određene kategorije ili kada se koristi posebna adresa isporuke.
Šta treba definisati u procesu
- ko može da kreira nacrt porudžbine;
- ko dobija zahtev i kroz koji kanal;
- da li odobravalac može da menja količine ili samo da prihvati i odbije;
- da li odbijanje zahteva obavezno obrazloženje;
- da li se po izmeni zahtev vraća na novo odobrenje;
- koliko dugo zahtev može ostati otvoren;
- koji statusi se prikazuju korisniku i administratoru.
Posebno treba razdvojiti zahtev za ponudu od porudžbine. Zahtev može biti predmet pregovora i ručne izmene, dok porudžbina predstavlja potvrđen komercijalni događaj. Ako se ova dva toka mešaju, lako nastaje zabuna oko cene, zaliha i obaveze isporuke.
Veleprodaja: količine, pakovanja i dostupnost
Veleprodaja često ne prodaje pojedinačne komade pod istim uslovima kao maloprodaja. Proizvod može biti dostupan samo u pakovanju od 10 komada, uz minimalnu porudžbinu po artiklu ili uz minimalnu vrednost cele korpe.
Na stranici proizvoda zato treba jasno prikazati:
- jedinicu prodaje: komad, kutija, paket, paleta ili druga poslovna jedinica;
- minimalnu i eventualno maksimalnu količinu;
- korak količine, na primer naručivanje samo u višekratnicima pakovanja;
- da li se cena odnosi na komad ili celo pakovanje;
- status dostupnosti i moguću zamenu za nedostupan artikal;
- rok ili način isporuke ako se razlikuje po količini.
Najčešća greška je da se poslovno pravilo prikaže tek na checkoutu. Ako kupac tek tada sazna da mora da naruči punu kutiju, vraća se u katalog, menja korpu i gubi pregled nad cenom. Pravilo treba prikazati tamo gde donosi odluku: na listi proizvoda, stranici artikla i u korpi.
Kada B2B narudžbine zavise od više načina isporuke, statusa i obračuna transporta, korisno je unapred razdvojiti prodajni tok od logističke integracije. Za detaljniji pregled tog dela pogledajte vodič Dostava i kurirske integracije: statusi, cene i tracking.
Checkout, plaćanje i podaci za poslovnu obradu
B2B checkout ne treba da prikuplja više polja samo zato što je „poslovni“. Svako polje treba da ima svrhu u fakturisanju, isporuci, proveri kupca ili internoj obradi. Podaci firme, kontakt osoba, adresa isporuke i napomena za skladište treba da budu organizovani tako da se ne ponavljaju bez potrebe.
Pre izrade treba odlučiti da li se koriste:
- online plaćanje;
- plaćanje po predračunu;
- odloženo plaćanje za odobrene firme;
- plaćanje prilikom isporuke, ako je deo poslovnog modela;
- kombinacija načina plaćanja po firmi ili tipu kupca.
Odobren način plaćanja ne mora biti dostupan svakom nalogu. Ako se plaćanje po predračunu ili odloženo plaćanje odobrava ručno, to pravilo mora biti vidljivo i u administraciji. Za konkretne poreske, računovodstvene i fiskalne zahteve treba uključiti odgovorne stručnjake i proveriti važeća pravila pre puštanja sistema.
Integracije i administracija
B2B web shop postaje koristan tek kada podaci mogu da se obrade bez dvostrukog ručnog rada. Integracija sa ERP-om, CRM-om, skladištem ili računovodstvenim sistemom zavisi od postojećeg procesa i dostupnih interfejsa. Ne treba pretpostaviti da će svaka platforma automatski uskladiti cenovnike, zalihe, firme i status porudžbine.
Mapa podataka treba da odgovori na pitanja:
- koji sistem je glavni izvor za proizvode i zalihe;
- gde se održavaju B2B cene;
- kako se identifikuje firma i sprečavaju duplikati;
- da li se porudžbina šalje kao zahtev ili kao potvrđena prodaja;
- ko vraća status obrade u web shop;
- šta se dešava kada sinhronizacija ne uspe.
Administracija mora omogućiti pregled bez oslanjanja na programera za svaku promenu. To može uključiti odobravanje firmi, dodelu cenovnika, izmenu korisničkih uloga, pregled zahteva i izvoz podataka. Istovremeno, više administrativnih opcija nije automatski bolje: interfejs treba da bude prilagođen stvarnim ulogama i odgovornostima.
Kako proceniti da li je B2B funkcionalnost dovoljno dobro definisana
Pre početka razvoja prođite kroz realne scenarije, ne samo kroz listu funkcija. Na primer:
- Nova firma šalje zahtev za registraciju i još ne vidi veleprodajne cene.
- Administrator odobrava firmu i dodeljuje joj cenovnik.
- Dva korisnika pripadaju istoj firmi, ali samo jedan može da odobrava porudžbine.
- Korisnik pokušava da naruči količinu manju od minimalne.
- Cena se menja kada količina pređe definisani prag.
- Odobravalac odbija zahtev uz obrazloženje.
- Porudžbina se prosleđuje u interni sistem, a status se vraća u nalog firme.
Za svaki scenario zapišite očekivani rezultat, poruku korisniku, podatke koji se čuvaju i osobu koja rešava izuzetak. Tako se ranije uočavaju nejasnoće oko prioriteta cena, duplih naloga i odgovornosti za odobrenje.
Ako B2B kanal uključuje korisničke naloge, bodove ili različite statuse kupaca, odvojeno definišite program lojalnosti i prava poslovnih korisnika. Vodič Loyalty program u web shopu: bodovi, statusi i korisnički nalog može pomoći da se te funkcije ne pomešaju sa cenovnikom firme.
Ako se prodaja zasniva na ponavljanju porudžbina ili ugovorenim obnovama, pogledajte i Subscription web shop: pretplate, obnove i lifecycle plaćanja. To je drugačiji proces od klasične veleprodajne porudžbine i treba ga projektovati kao zaseban tok.
Praktičan obim prve verzije
Za prvu verziju često je razumno krenuti od ograničenog, ali jasnog modela: odobrena firma, jedan ili više korisnika, jedan dodeljeni cenovnik, minimalne količine, definisan način plaćanja i ručna ili osnovna integracija obrade porudžbine. Kasnije se mogu dodati složenija hijerarhija odobrenja, više lokacija, individualni ugovori i automatizovana sinhronizacija.
Takvo fazno uvođenje ne znači da treba zanemariti budući razvoj. Model podataka treba da ostavi prostor za više korisnika, cenovnika i adresa, ali interfejs prve verzije ne mora odmah da izloži svaku moguću opciju.
Pre odluke o platformi ili specifikaciji projekta, korisno je pripremiti: spisak tipova kupaca, pravila cena, matricu korisničkih uloga, tok odobrenja, pravila pakovanja, načine plaćanja, izvore podataka i listu izuzetaka. Ako je potreban širi rad na strukturi sajta, sadržaju i poslovnim stranicama, relevantna može biti i izrada sajta, ali B2B prodajna pravila moraju ostati posebno dokumentovana.
Sledeći korak je da se jedan stvarni proces od početka do kraja pretvori u specifikaciju: od registracije firme do potvrđene porudžbine i njenog statusa u administraciji. Tek tada se može realno proceniti koje funkcije su obavezne, koje su faza dva i gde su potrebne integracije ili ručna kontrola.
