En B2B-webbutik som byggs som en konsumentbutik med inloggning löser fel problem. Konsumenthandelns svåra delar är att locka besökare, presentera sortimentet och få kassan att konvertera. I B2B är kunden redan kund, vet vad hen vill ha, och det svåra ligger någon helt annanstans.
Vad som faktiskt skiljer
| Konsument | B2B | |
|---|---|---|
| Kund vid ankomst | Okänd | Inloggad och känd |
| Pris | Publikt och lika för alla | Kundspecifikt, ofta förhandlat |
| Betalning | I kassan | Mot faktura, inom kreditgräns |
| Köpmönster | Enstaka köp | Återkommande, ofta samma rader |
| Beslutsfattare | En person | Flera roller på samma kund |
| Efter köpet | Spårningslänk | Orderstatus, restnoteringar, dokument |
Sista raden är den som brukar underskattas. I B2B står en betydande del av kundens frågor efter beställningen, inte före.
Priset måste vara kundens eget
En B2B-kund som ser listpris på nätet och ett annat pris på fakturan slutar använda nätbutiken. Priset måste komma ur samma prisberäkning som en order lagd av en säljare: kundspecifikt pris först, sedan volympris, sedan prislista.
Detsamma gäller ramavtal. Ligger avtalet i affärssystemet men inte i butiken kommer avropet läggas till fel pris, och sedan får någon rätta det manuellt.
Tillgänglighet i stället för exakt saldo
B2B-kundens fråga är oftast när, inte om. Kan hen se att varan finns läggs ordern direkt, annars ringer hen och frågar, och då har poängen med självbetjäningen gått förlorad.
Många väljer att visa tillgänglighet grovt: i lager, fåtal kvar, beräknad leverans ett visst datum. Det räcker för beslutet och undviker att exponera exakta saldon för konkurrenter som råkar ha ett kundkonto.
Portalen är mer än beställning
En del av det som ger mest nytta är inte att lägga order utan att slippa ringa om dem:
- Orderstatus på pågående order, inklusive vad som är restnoterat.
- Orderhistorik att beställa om ifrån, vilket är den vanligaste vägen till en ny order i B2B.
- Dokument: orderbekräftelser, följesedlar, fakturor.
- Egna artikelnummer, så att kunden kan söka på sin egen benämning i stället för din.
Det sista är en liten sak som ger stor effekt hos kunder som har en egen artikelstruktur.
Samma saldo, inte en kopia
Den vanligaste tekniska fällan är att butiken får en kopia av artiklar och saldon som synkas med jämna mellanrum. Då uppstår översäljning, prisdifferenser och en ständig frågan om vilket system som har rätt.
Ligger butiken på samma data som ordersystemet försvinner hela den kategorin av problem. Det är också det som gör att en order från portalen kan gå direkt till plock utan mellansteg.
I Fluit
Fluit har en portal för både kunder och leverantörer, på samma data som resten av systemet. Kunden ser sina order, sin historik och sina dokument, och priser hämtas ur samma prisberäkning som gäller när en säljare lägger ordern.
Vid sidan av portalen finns e-handel med kanaler, kundvagnar och innehållssidor, där samma artikelregister och samma lagersaldo används. Det är alltså inte två sortiment som ska hållas i takt, utan ett.
