NL
German
English
Een B2B-webshop met selfservice achter de inlog is een klantportaal. Het zijn geen twee systemen die je naast elkaar zet, maar twee taken van dezelfde omgeving: nieuwe klanten binnenhalen en bestaande klantrelaties beheren.
Groothandels vragen zich vaak af of ze naast hun B2B-webshop ook een klantportaal nodig hebben. Dat is de verkeerde vraag. De vraag wordt zo vaak als keuze gesteld omdat het bij veel groothandels feitelijk twee dingen zijn geworden. Dat is er in de loop van de jaren ingeslopen, zonder dat iemand er ooit voor heeft gekozen.
Waarom het vaak alsnog twee omgevingen zijn
Veel B2B-webshops zijn ontworpen voor de eerste order. Zoeken, winkelwagen, afrekenen. De vragen die na die order komen, zoals waar staat mijn zending en klopt deze factuur, bleven bij de binnendienst liggen. Toen dat te veel werd, kwam er een oplossing bij: een portaal van de ERP-leverancier, een los dealerplatform, een my-account-sectie die niet meer doet dan een paar PDF's tonen, of een klantomgeving die ooit voor één grote afnemer is gebouwd.
Het resultaat is een gesplitste omgeving, en dat kost meer dan het oplost:
- Twee waarheden over dezelfde data. De shop toont een prijs, het portaal toont een andere. De klant belt om te vragen welke klopt.
- Twee inlogpaden. De inkoper weet niet waar hij moet zijn voor een pakbon, dus mailt hij.
- Twee beheerlasten. Gebruikers, rollen en prijzen worden op twee plekken onderhouden, met de bijbehorende afwijkingen.
- Een gebroken bestelroute. De klant ziet in het portaal wat hij vorige maand kocht, maar moet naar de shop om het opnieuw te bestellen.
Eén omgeving die na het inloggen omschakelt naar klantspecifieke prijzen, orderhistorie, openstaande facturen en herbestellen lost dat op. Voor de bezoeker is het één site. Technisch is het één datamodel met één bron: je ERP.
Wat je dan wel moet beslissen
Als de vraag niet is of je een portaal naast je webshop zet, wordt de vraag welke selfservicelagen je wanneer toevoegt. Dat is een echte afweging, want elke laag stelt eisen aan je data.
| Selfservicelaag | Data die het ERP moet ontsluiten | Wat het wegneemt | Afhankelijkheid |
|---|---|---|---|
| Orderhistorie en orderstatus | orders en orderregels, inclusief orders die buiten de shop om zijn geplaatst, met deelleveringen | statusvragen, verzoeken om een pakbonkopie | status moet op regelniveau beschikbaar zijn, niet alleen per order |
| Klantspecifieke prijzen | prijsafspraken, staffels, contractcondities, toegestaan assortiment | prijscontroles, creditnota's na een verkeerde prijs | de condities in je ERP moeten actueel en schoon zijn |
| Herbestellen | orderhistorie plus actuele voorraad en levertijd | zoekwerk in de catalogus, bestellijsten per mail | voorraad mag niet achterlopen, anders bestelt de klant mis |
| Facturen en openstaande posten | facturen, betaalstatus, openstaande bedragen | factuurkopieën, betaalvragen, handmatige herinneringen | financiële data moet aansluiten op wat je administratie ziet |
| Gebruikers, rollen en vestigingen | contactpersonen, debiteurnummers, kostenplaatsen | verkeerd geboekte orders, onterechte inzage | je klantstamdata moet de werkelijke organisatiestructuur volgen |
De volgorde bepaal je niet op basis van welke functie het mooist demo't, maar op basis van twee dingen: welke vraag je binnendienst het vaakst krijgt, en welke data je ERP betrouwbaar kan ontsluiten. Die twee vallen zelden samen, en waar ze niet samenvallen zit je eerste project.
Een portaal maakt slechte data zichtbaar voor de klant
Zolang prijsafspraken en voorraadstanden alleen in het ERP staan, ziet vooral je binnendienst de afwijkingen. Die worden in het gesprek gecorrigeerd, meestal zonder dat de klant het merkt. Zet dezelfde data achter een inlog en de inkoper ziet ze rechtstreeks. Een verouderde staffel is dan geen intern aandachtspunt meer, maar een discussie met je klant.
Dat is geen argument om selfservice uit te stellen. Het is een argument om per laag eerst te controleren of de onderliggende data klopt. In de praktijk betekent dat drie situaties waarin je beter begint met opschonen of ontsluiten dan met bouwen:
Het ERP kan de data niet leveren. Zijn orderregels, openstaande posten of prijsafspraken niet via een koppeling beschikbaar, dan bouw je een weergave die achterloopt. Dat kost vertrouwen dat je moeilijk terugkrijgt.
De klant- en prijsdata zijn niet betrouwbaar. Verouderde condities, dubbele contactpersonen, debiteurnummers die niet met de werkelijke vestigingen overeenkomen, kortingen die ooit mondeling zijn afgesproken. Dit is het meest onderschatte onderdeel van elk traject.
Het probleem is adoptie, niet functionaliteit. Komt een klein deel van je orders online binnen terwijl de functies er al zijn, dan helpt meer functionaliteit niet. Dan gaat het over onboarding van inkopers en over de vraag of je eigen accountmanagers de digitale route stimuleren of eromheen werken. Gedragsverandering duurt aanzienlijk langer dan de implementatie.
Voor het inrichten van de functionele kant zelf schreven we eerder uitgebreider over hoe je een B2B-klantportaal bouwt dat je binnendienst ontlast.
Eén platform of een portaal erbovenop?
Omdat het één omgeving hoort te zijn, verschuift ook de platformvraag. Die gaat niet over welk portaal je naast je shop hangt, maar of je platform selfservice als onderdeel van hetzelfde datamodel behandelt. Vijf vragen die verder helpen dan een featurevergelijking:
- Hoe diep gaat de standaardintegratie met jouw specifieke ERP, en wat is maatwerk?
- Welke data kan het platform realtime ontsluiten en welke niet?
- Hoe worden bedrijfsaccounts met meerdere gebruikers, rollen en vestigingen gemodelleerd?
- Wat gebeurt er bij een release: beweeg je mee of blijf je achter op een oude versie?
- Wie is verantwoordelijk als de koppeling faalt, en hoe merk je dat voordat je klant het merkt?
Een platform dat als consumentenwebshop is ontworpen en waaraan later B2B-functionaliteit is toegevoegd, loopt tegen grenzen aan zodra klantspecifieke prijzen, offerteworkflows, rechten per vestiging en goedkeuringsstappen samenkomen. Die grenzen merk je zelden in de demo en bijna altijd in jaar twee.
CloudSuite is opgezet vanuit de operationele logica van groothandels en merkfabrikanten, met B2B-e-commerce voor groothandels en selfservice in hetzelfde platform in plaats van als losse laag. Hoe verschillend dat uitpakt, laten de klantcases zien: Secrid bestelt zakelijk via een mobile-only B2B-platform met daarnaast een headless B2C-webshop op dezelfde backend, Beko Groothandel bedient als inkooporganisatie bakkers, patissiers en chocolatiers, en Versluis stapte als groothandel in schildersgereedschap over van een verouderde webshop. Drie heel verschillende bestelprocessen, met dezelfde onderliggende eis: de data komt uit het ERP en moet kloppen. Welke koppelingen mogelijk zijn, staat in het overzicht van ERP-integraties.
Waar je morgen mee kunt beginnen
Twee inventarisaties, beide zonder project of budget uit te voeren, die de rest van het traject richting geven.
Tel je binnendienstvragen, twee weken lang. Categoriseer grofweg: orderstatus, factuur of betaling, prijs of conditie, voorraad, correctie op een lopende order, overig. Daarna heb je je eigen cijfers en hoef je niet te leunen op branchegemiddelden.
Breng per datasoort uit de tabel hierboven in kaart wat je ERP kan ontsluiten. Beschikbaar via een koppeling, hoe actueel, en hoe betrouwbaar de inhoud vandaag is.
Waar die twee lijsten elkaar kruisen, ligt je eerste selfservicelaag. In de gids Het B2B-klantportaal staan een scorekader met vijf dimensies om platforms te vergelijken en een uitwerking van wat realtime moet en wat batch mag. De PDF is zonder formulier te openen.
