B2B-webshop: det der adskiller den fra B2C

De fleste B2B-virksomheder, vi møder, har allerede "en webshop" i et slide. Når vi kigger efter, er det et katalog med en kurv, og den rigtige pris lever i et regneark. Kunden logger ind og ser alligevel det forkerte. Sælgeren sender et tilbud i mailen. Bogholderiet taster ordren. Butikken var dekoration.

Det er derfor, spørgsmålet ikke er "Shopify eller custom" som religion. Spørgsmålet er, hvilke regler der skal være sande, når en indkøber trykker køb. Hvis reglerne er listpris plus fragt, er I tættere på B2C, end I tror. Hvis reglerne er pris pr. kunde, minimumsordre, kredit og en godkender i en anden afdeling, har I et andet produkt.

Vi ser også det omvendte: teams, der bestiller en fuld B2B-suite, fordi de har hørt ordet punchout, mens deres egentlige smerte er, at stamkunder ikke kan se restordrer. Så bygger I det tunge først og lader det daglige arbejde ligge. En B2B-webshop, der ikke fjerner en konkret, gentaget opgave, er et projekt — ikke en kanal.

Det her er rammen, vi bruger, før nogen vælger platform. Den er bevidst tæt på vores guide om kundeportaler, fordi de to produkter ofte forveksles. Forskellen er retningen: butikken er købet. Portalen er livet efter købet. Mange B2B-setups har brug for begge. Næsten ingen har brug for at lade som om, de er det samme.

I B2C er gæsten ukendt, indtil betalingen går igennem. I B2B er organisationen ofte kendt, før kataloget giver mening. Prisen, sortimentet og fragtreglerne kan afhænge af, hvem der er logget ind. Hvis I viser listpris til alle og "retter det i ERP'en bagefter", har I ikke en B2B-webshop. I har et showroom med ekstra arbejde.

Ordren er heller ikke den samme genstand. B2C-ordren er typisk betalt, lille og færdig. B2B-ordren kan være et tilbud, der skal godkendes, en rammeaftale, der trækkes på, eller en indkøbskurv, der skal landes i kundens eget indkøbssystem. Checkout er ikke en kreditkortformular. Checkout er den proces, der gør ordren sand i jeres bagkant.

Roller slår person-login. En indkøber lægger i kurv. En leder godkender. En bogholder henter fakturaen. Hvis jeres butik kun kender "en bruger med en e-mail", vil I opfinde organisationer i supporten. Det er den slags gæld, der føles usynlig i et MVP-slide og meget synlig, når den første mellemstore kunde får to afdelinger.

Endelig er self-service i B2B ofte mere værd end selve købet. At se restordre, hente certifikater, genbestille sidste måneds linjer — det er det, der fjerner telefonen. En butik uden det lag bliver et sted, man køber første gang, og et sted, man ringer anden gang. Så har I betalt for en kanal, der ikke erstatter kanalen, I hadede.

Kundespecifik pris er ikke et tema i Shopify-admin. Det er kernen. Hvis to kunder ikke må se hinandens nettopris, skal I have organisationer, prislister og et sted, den pris er sand — typisk ERP eller en prisengine, ikke et felt, en intern redigerer i nattens mulm. Når prisen er forkert i butikken, ringer kunden ikke til support. Kunden mister tillid til kanalen.

Tilbud er det næste trin, mange presser ind for tidligt. Et tilbud er en låst pris i en periode, ofte med linjer, der ikke findes som SKU'er, og ofte med en sælger i loopet. Hvis 80 procent af jeres ordrer allerede er listelinjer, I kan vise til den rigtige kunde, så byg det. Hvis 80 procent er forhandlede pakker, så er en butik, der ikke kan bære tilbud, et sidespor — og I skal være ærlige om det, før I køber en platform.

Netto-vilkår, kreditramme og minimumsordre er ikke "checkout-options". De er beslutninger om, hvem der må lægge en ordre, der ikke er forudbetalt. En B2C-platform, der kun kender kort og rater, vil enten blokere jeres stamkunder eller lade alle købe på faktura. Ingen af delene er acceptabelt, når bogholderiet har en holdning.

Vi anbefaler at skrive de tre regler ned, før I vælger stack: hvordan prisen findes, hvornår et tilbud er nødvendigt, og hvem der må bestille uden at betale nu. Hvis I ikke kan, er I ikke klar til at implementere. I er klar til at kortlægge, hvordan I sælger i dag — og det er det arbejde, der faktisk afgør prisen på projektet, ikke hvilket tema I kan lide.

B2C-login er "min ordre og mine adresser". B2B-login er "min virksomhed, mine aftaler, mine kolleger". Hvis I kun opretter brugere, ender I med at dele adgangskoder på tværs af indkøb. Hvis I opretter organisationer uden roller, kan praktikanten se priser, I lovede at holde internt, eller godkende over kreditrammen.

Det er også her, kundeportalen og webshoppen overlapper. Samme identitetslag kan bære begge: køb i den ene flade, restordre og dokumenter i den anden. Det, der går galt, er at bygge to logins, fordi to leverandører hver især solgte "B2B". Én organisation, ét sæt roller, to opgaver.

SSO og IdP kommer, når kunden er stor nok til at kræve det — ikke fordi det står på et enterprise-tjekliste. For de fleste danske mellemstore kunder er en indbydelse pr. e-mail og en admin hos kunden, der kan tilføje kolleger, det rigtige v1. Overbyg, når en konkret kontrakt siger noget andet.

Dataisolation er ikke til forhandling. En bruger må ikke kunne gætte sig til en anden virksomheds ordrer ved at skifte et id i URL'en. Det lyder basalt, og det er præcis det, der bliver glemt, når en B2C-shop får "et B2B-login" boltet på. Hvis I bygger selv, så er RLS og org-scope en del af produktet. Hvis I køber, så spørg, hvordan de isolerer — ikke om de har et B2B-badge.

Hvis den handling, I vil have digital, er "læg de her SKU'er i kurv til den pris, vi har aftalt", har I en webshop. Hvis handlingen er "se mine ordrer, hent dokumenter, godkend en levering", har I en portal. Hvis det er begge, så byg identitet og org-model én gang, og lad de to flader dele den. Det er billigere end to produkter, der ikke kender hinanden.

Shopify er nok, når jeres B2B ligner handel: katalog, prislister, organisationer, og I kan acceptere deres model for kunder og checkout. Den er det forkerte svar, når hver ordre er et projekt, når prisen kun findes som et tilbud i mailen, eller når I har brug for dybe roller, som deres B2B-lag ikke kan bære uden workarounds, I kommer til at hade.

Custom — typisk Next.js foran jeres data — er det rigtige, når købsflowet er jeres forretning, ikke et tema. Konfigurator, reservedele pr. serienummer, eller en butik, der i praksis er en bestillingsflade oven på et eksisterende kundeportal-login. Det er dyrere at eje. Det er billigere end at tvinge et fremmed checkout til at lyve.

Vi har skrevet separat om, hvornår I overhovedet har brug for en kundeportal, og om, hvornår Shopify er nok som handelsplatform. Det her indlæg er det midterste spørgsmål: hvis I siger "B2B-webshop", mener I så køb, efterkøb — eller et håb om, at ét login løser begge dele? Svar på det, før I skriver kontrakt.