Waar B2B-kopers een leveranciersportaal echt op beoordelen
Consumenten e-commerce is een ontdekkingsvraagstuk. B2B e-commerce is een verificatievraagstuk. De koper weet meestal wat hij wil voordat hij arriveert, en de taak van de site is om prijs, beschikbaarheid en levering nauwkeurig genoeg te bevestigen zodat ze tot aankoop overgaan zonder elders te kijken.
Dat draait de prioriteiten om. Zoekfuncties en merchandising zijn minder belangrijk dan de meeste webshopdemo's suggereren. Correctheid is belangrijker dan bijna alles. Een verkeerde prijs op een B2B-bestelling is geen slechte klantervaring, maar een commercieel geschil en een creditnota.
De functies die adoptie stimuleren zijn daarom weinig glamoureus. Kopers willen hun prijs, actuele voorraad, hun historie en een leverdatum waar ze op kunnen plannen. Een portaal dat die vier zaken goed op orde heeft, wint het altijd van een portaal met een betere interface maar verouderde data.
De functies die in werkelijkheid datastromen zijn
Het meeste van wat op een B2B-checklist staat, is de webshop die iets weergeeft wat in een ander systeem thuishoort.
- Klant-specifieke prijzen: contractprijzen, staffelkortingen en accountkortingen die in het ERP staan en worden toegepast per ingelogd account
- Real-time beschikbaarheid: een 'available-to-promise' cijfer uit het magazijnsysteem, netto na reserveringen, in plaats van een dagelijkse snapshot
- Bestelhistorie en nabestellen: eerdere bestellingen via elk kanaal, inclusief die telefonisch of via EDI zijn geplaatst, gepresenteerd als één lijst
- Krediet- en betalingsvoorwaarden: de limiet en voorwaarden van het account vanuit de financiële administratie, afgedwongen bij het afrekenen in plaats van achteraf ontdekt
- Offerte naar bestelling: een goedgekeurde offerte die zonder opnieuw invoeren wordt omgezet in een bestelling, waarbij de geoffreerde prijs wordt gerespecteerd
De webshop kan alle vijf weergeven. Hij genereert er geen enkele. Dat is de reden waarom een platformmigratie zelden een B2B-portaal repareert dat kopers niet vertrouwen, en waarom de oplossing meestal achter de webshop ligt in plaats van erin.
Waarom gaan klant-specifieke prijzen zo vaak mis?
B2B-prijzen zijn op een manier voorwaardelijk die consumentenprijzen niet zijn. De prijs van een enkele regel kan afhangen van het account, het contract, de bestelhoeveelheid, de valuta, de afleverlocatie en of er op die datum een promotie actief is. Het ERP lost die voorwaarden correct op omdat het over alle informatie beschikt.
Problemen ontstaan wanneer prijzen volgens een schema naar de webshop worden gekopieerd. Een gesynchroniseerde prijstabel is een momentopname van een berekening en is verouderd zodra een contract wordt heronderhandeld of een staffelkorting wordt aangepast. Erger nog, het laat stilletjes de voorwaarden weg die het niet kon weergeven, waardoor een uitzonderlijk geval tegen de verkeerde prijs wordt getoond zonder dat er ergens een foutmelding verschijnt.
Het alternatief is om de prijs op het moment van weergave te bepalen door het ERP aan te roepen via de integratielaag, zodat de webshop de vraag stelt in plaats van deze te onthouden. Dit houdt de prijsbepaling op één plek en lost het reconciliatieprobleem volledig op.
Klant-specifieke prijzen in real-time bepaald
Leveranciers die dit het minst snel zullen proberen, zijn degenen wiens contractvoorwaarden in een decennia oud ERP-systeem staan, in de veronderstelling dat een systeem van die leeftijd geen webshop kan beantwoorden terwijl een koper wacht. Leeuwerik Plaat is een Nederlandse leverancier van plaatmaterialen die al meer dan honderd jaar bestaat, een magazijn van 20.000 vierkante meter beheert en meer dan 3.000 producten aanbiedt aan zakelijke klanten. Hun kopers bestellen op basis van contractvoorwaarden, wat nauwkeurige prijzen een voorwaarde maakt voor een bruikbare webshop.
Leeuwerik koppelde zijn Kerridge ERP aan Adobe Commerce via het Alumio iPaaS, waardoor producten, voorraad, klanten, leveringen, bestellingen en klant-specifieke prijzen in real-time worden uitgewisseld. Zakelijke klanten kunnen nu 24/7 bestellen met live inzicht in prijzen, in plaats van alleen tijdens kantooruren op basis van een prijs die telefonisch is bevestigd.
Het uitgangspunt is wat het nuttig maakt. Dit was een traditionele leverancier met een gevestigd ERP-systeem zonder de wens om dit te vervangen; ze overbrugden de kloof tussen hun systemen en hun klanten door ze te koppelen in plaats van alles opnieuw op te bouwen.
Hoe een integratieplatform een B2B-webshop ondersteunt
Een B2B-webshop moet twee dingen tegelijk doen: een vraag stellen aan het ERP en antwoord krijgen terwijl de koper wacht, en een voltooide bestelling terugsturen. Het Alumio iPaaS bevindt zich tussen de webshop en de systemen die die antwoorden bevatten, en regelt beide richtingen. Synchrone aanroepen bepalen de prijs en beschikbaarheid op het moment dat een koper een product bekijkt, zodat het getoonde bedrag overeenkomt met wat in het ERP staat.
Event-driven flows verwerken het verkeer in de andere richting. Een bestelling die in de webshop wordt geplaatst, verschijnt direct in het ERP en de verzendstatus wordt teruggestuurd naar het account van de koper zonder dat iemand gegevens opnieuw hoeft in te voeren. Transformers lossen het structurele verschil op tussen een e-commercebestelling en een verkooporder in het ERP. Dit omvat de klant-, contract- en belastingreferenties die het ERP vereist en die de webshop niet standaard bevat.
Dezelfde laag accepteert bestellingen die via EDI binnenkomen van grotere kopers, waardoor de bestelgeschiedenis over alle kanalen heen compleet blijft in plaats van alleen te tonen wat via de webshop is binnengekomen. Logging legt elke uitwisseling vast, zodat een prijsvraag een antwoord heeft in plaats van een onderzoek. Dit patroon is gebruikelijk in B2B-distributie, waar het ERP leidend is en de webshop een van de vele kanalen is die daaruit leest.
B2B e-commercefuncties kiezen op basis van hun afhankelijkheden
De praktische manier om een B2B-roadmap te evalueren, is door elke voorgestelde functie te nemen en te vragen welk systeem de data erachter beheert en hoe actueel die data moet zijn. Functies waarvan de data in de webshop leeft, zijn snel te realiseren. Functies die afhankelijk zijn van ERP- of magazijndata zijn integratiewerk, ongeacht of het platform ze als ondersteund vermeldt.
De volgorde volgt daaruit. Zorg dat prijzen en beschikbaarheid live worden bepaald voordat je offertes, punchout of goedkeuringsworkflows toevoegt, omdat die latere functies afhankelijk zijn van de nauwkeurigheid die de eerste twee hebben vastgesteld. Ze bouwen op een verouderde prijstabel betekent dat je ze later opnieuw moet opbouwen.
Leveranciers die op deze manier werken, eindigen met minder functies maar meer gebruik, omdat de functies die ze aanbieden de functies zijn die kopers genoeg vertrouwen om niet meer te hoeven bellen.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
