Primer prenove B2B prodajnega portala

Prodajnik pokliče podporo, ker kupec ne vidi svoje pogodbeno dogovorjene cene. Skladišče medtem preverja zalogo v drugem sistemu, naročilo pa prispe po e-pošti brez jasne povezave s preteklimi nakupi. Tak primer prenove B2B prodajnega portala ni težava oblikovanja, temveč poslovnega procesa. Portal mora kupcu omogočiti samostojno in hitro naročanje, ekipi pa odstraniti ročno delo, napake in nepotrebno preverjanje podatkov.

B2B portal ni klasična spletna trgovina z lepšim prijavnim obrazcem. Je del prodajne infrastrukture podjetja. Če ne pozna pogodbenih cen, ne prikazuje realnih zalog, ne podpira nabavnih procesov in ne komunicira z obstoječimi sistemi, bo zaposlenim ustvarjal dodatne naloge namesto prihranka časa.

Izhodišče: portal, ki je posloval mimo uporabnika

Predstavljajmo si distributerja tehničnega materiala z več sto poslovnimi kupci. Obstoječi portal je omogočal prijavo, ogled osnovnega kataloga in oddajo naročila. Na papirju je imel vse ključne funkcije. V praksi pa so kupci še vedno pošiljali naročilnice po e-pošti ali klicali komercialiste.

Razlog ni bil odpor do digitalnih kanalov. Kupec v portalu ni videl svojih cen, ni mogel preveriti, ali je izdelek res dobavljiv, niti ni hitro našel artiklov, ki jih redno naroča. Iskanje je vračalo neuporabne rezultate, podatki o izdelkih so bili neenotni, naročilni proces pa je zahteval preveč korakov. Portal je obstajal, vendar ni olajšal dela.

Takšno stanje je pogosto posledica razvoja po delih. Najprej se doda katalog, kasneje prijava, nato povezava z ERP-sistemom in na koncu še posebna cenovna pravila. Brez enotne zasnove nastane rešitev, ki skuša zadovoljiti vse, vendar nobene naloge ne opravi zares dobro.

Kaj mora razkriti analiza pred prenovo

Prenova se ne sme začeti z izbiro barvne palete ali predloge uporabniškega vmesnika. Začeti se mora pri vprašanjih, kje danes nastajajo zastoji in katere podatke uporabniki dejansko potrebujejo za nakup.

Pri takem projektu je smiselno pregledati tri vidike: pot kupca, delo interne ekipe in tok podatkov med sistemi. Kupec mora hitro najti pravi artikel, videti pogoje, ki veljajo zanj, ter naročilo oddati brez dodatne komunikacije. Komercialist mora imeti vpogled v naročila in možnost pomoči, ne pa vloge ročnega prepisovalca. Podatki pa morajo iz zalednih sistemov prihajati zanesljivo in dovolj ažurno.

Posebno pozornost zahtevajo različni tipi kupcev. Velik partner lahko naroča po dogovorjenih rabatih, manjši kupec po ceniku, tretji pa potrebuje odobritev naročila pred oddajo. Če portal vse obravnava enako, bo nekaterim kupcem poenostavil delo, drugim pa ga zapletel. Zato rešitev po meri ni razkošje, ampak način, da digitalni kanal sledi dejanskemu poslovnemu modelu.

Podatki niso tehnična podrobnost

Pri B2B prodaji kakovost podatkov neposredno vpliva na zaupanje. Napačna zaloga, zastarela cena ali nejasen rok dobave kupca hitro vrnejo k telefonu. Lep uporabniški vmesnik tega ne popravi.

Pred razvojem je zato treba določiti, kateri sistem je glavni vir za posamezen podatek. ERP je lahko vir cen, zalog in kupcev, PIM-sistem vir opisov ter tehničnih specifikacij, portal pa mesto, kjer se podatki smiselno prikažejo in uporabniku omogočijo dejanje. Jasno lastništvo podatkov prepreči podvojene vnose in poznejša usklajevanja.

Primer prenove B2B prodajnega portala v praksi

Pri prenovi bi se najprej uredila struktura kataloga. Namesto dolgega seznama izdelkov bi kupca pričakale jasne kategorije, tehnični filtri in iskalnik, ki razume šifre artiklov, nazive ter pogoste oznake. Pri tehničnih izdelkih je to pomembneje od promocijskih pasic. Nabavnik pogosto ne išče navdiha, ampak točno določen kos, kompatibilno izvedbo ali hitro zamenjavo za izdelek, ki ga je že kupil.

Naslednji korak bi bil osebni prikaz podatkov po prijavi. Kupec vidi svoje dogovorjene cene, razpoložljivost, predvideni rok dobave, odprta naročila in zgodovino nakupov. S tem se portal spremeni iz splošnega kataloga v uporabno delovno okolje. Funkcija ponovnega naročila je v takem primeru pogosto vrednejša od kompleksnih marketinških modulov, saj zmanjšuje čas pri rednih nabavah.

Naročanje bi podprlo tudi realne navade kupcev. Nekateri naročajo posamezne artikle, drugi vnašajo več šifer hkrati, tretji uvažajo seznam iz preglednice. Dober portal ne zahteva, da kupec spremeni svoj ustaljeni proces samo zato, ker je tako lažje razviti sistem. Vendar tudi tu velja meja: smiselno je podpreti postopke, ki jih uporablja dovolj velik delež kupcev ali imajo jasen poslovni učinek. Vsaka izjema ne upraviči posebne funkcionalnosti.

Pomemben del prenove je uporabniški račun podjetja. Več uporabnikov znotraj istega kupca lahko potrebuje različne pravice: eden pripravlja košarico, drugi jo potrdi, tretji spremlja račune in dobave. Če podjetje prodaja večjim organizacijam, so takšni potrditveni tokovi pogosto odločilni. Če prodaja manjšim obrtnikom, bi bili lahko nepotrebna ovira. Prava rešitev je odvisna od načina prodaje, ne od seznama funkcij konkurence.

Integracije, ki morajo delovati tudi po objavi

Povezava z ERP-sistemom je pogosto jedro projekta, vendar ni dovolj, da podatki enkrat uspešno potujejo med dvema aplikacijama. Treba je opredeliti pogostost sinhronizacije, obravnavo napak in odgovornost, ko podatek manjka ali se ne ujema.

Za zaloge je lahko primerna pogosta osvežitev, za cenike sinhronizacija ob prijavi ali ob oddaji košarice, za tehnične opise pa redkejši prenos. To je odvisno od količine artiklov, hitrosti spreminjanja podatkov in zmogljivosti zalednih sistemov. Realnočasovni prenos zveni privlačno, vendar ni vedno nujen ali gospodaren. Če podatki o zalogi niso kritični iz minute v minuto, lahko premišljen interval zagotovi stabilnejše delovanje in nižje stroške.

Enako velja za povezave z logistiko, računovodstvom, CRM-jem ali sistemi za upravljanje dokumentacije. Dobra arhitektura ne pomeni največjega števila integracij. Pomeni, da so povezani sistemi, ki odstranijo konkretna ročna opravila in kupcu zagotovijo točne informacije.

Varnost in upravljanje nista dodatka

B2B portal pogosto vsebuje cenike, popuste, dokumente, zgodovino naročil in podatke o podjetjih. Zato morajo biti prijava, pravice uporabnikov, beleženje ključnih aktivnosti, varnostne kopije ter redne posodobitve vključeni v načrt od začetka.

Prav tako je pomemben administrativni vmesnik. Ekipa mora brez razvijalca urejati izpostavljene vsebine, osnovne podatke o kategorijah, obvestila in uporabniške pravice v okviru dogovorjenih pravil. Pri tem pa preveč odprt administrativni dostop ni prednost. Cene, zaloge in drugi ključni poslovni podatki naj ostanejo vezani na sistem, ki je zanje odgovoren. Tako se zmanjša tveganje nedoslednosti.

Kako meriti, ali prenova deluje

Uspeha portala ne ocenjujemo po dnevu objave. Spremljati je treba, ali se povečuje delež naročil prek portala, koliko časa kupci porabijo za ponovna naročila, koliko klicev se nanaša na cene ali zaloge in koliko ročnega vnosa je ostalo v prodajni ekipi.

Koristno je opazovati tudi nedokončane košarice, neuspešna iskanja in artikle, pri katerih uporabniki pogosto zapustijo stran. To niso zgolj statistike. So neposredni signali, kje portal ne odgovarja na vprašanje kupca. Če ljudje vztrajno iščejo izraz, ki ne vrne rezultatov, morda manjka sopomenka, filter ali celoten segment ponudbe.

Prenova zato ni enkraten projekt, temveč postavitev boljše osnove. Po objavi sledijo izboljšave na podlagi dejanske uporabe, poslovnih sprememb in povratnih informacij kupcev. Moxy Web pri takšnih rešitvah združuje oblikovanje, razvoj po meri in dolgoročno tehnično podporo, ker brez tega tudi dobro zasnovan portal sčasoma izgubi prednost.

Najboljši naslednji korak ni vprašanje, katero funkcijo dodati prvo. Vprašajte se, katero opravilo vaš kupec danes še vedno rešuje po telefonu, e-pošti ali v preglednici. Če ga portal lahko varno in jasno prevzame, je to funkcija, ki ima poslovni smisel.