De vraag ‘waar is mijn bestelling?’ is een van de meest gestelde vragen in eCommerce en legt een veel groter probleem bloot: Geen enkel systeem kent het hele verhaal.
Vier systemen. Vier dashboards. Vier stukjes informatie.
Vier systemen geven vier verschillende statussen. Alle vier kloppen ze. En toch kan de medewerker van Customer Service de klant geen antwoord geven.
Een klant stuurt een simpele e-mail: kun je me vertellen waar mijn bestelling is? Dat zou eenvoudig te beantwoorden moeten zijn.
De medewerker opent eerst de webshop. Orderstatus: Fulfilled. Dat klinkt goed, maar betekent alleen dat de webshop zijn eigen deel van het proces als afgerond beschouwt.
Dan het ERP. Orderstatus: Released. De bestelling is vrijgegeven, maar daaruit blijkt niet of er fysiek iets uit het magazijn is vertrokken.
Vervolgens het WMS. Fulfilmentstatus: Packed. Dat helpt. Het pakket bestaat in ieder geval.
Tot slot het portaal van de vervoerder. Verzendstatus: Label created. Geen afhaalscan. Geen depotscan. Geen beweging.
Dus waar is de bestelling?
Staat het pakket nog op een inpaktafel? Wacht het ergens bij de expeditie? Heeft de chauffeur het meegenomen zonder dat het is gescand? Of is er ergens tussen het magazijn en de vervoerder iets misgegaan?
Vier systemen. Vier dashboards. Vier stukjes informatie. En één heel gewone vraag waarop niemand met zekerheid antwoord kan geven.
‘Waar is mijn bestelling?’ is geen uitzondering
‘Waar is mijn bestelling?’ behoort structureel tot de meest gestelde vragen aan Customer Service binnen eCommerce. Benchmarks verschillen over het exacte aandeel. Afhankelijk van de manier waarop wordt gemeten, gaat het om ongeveer een vijfde tot twee vijfde van alle klantvragen. Tijdens piekperiodes kan dat aandeel verder oplopen.
Eigenlijk is dat opmerkelijk. Een van de meest alledaagse vragen binnen eCommerce, die in de sector iedere week duizenden keren wordt gesteld, kan vaak door geen enkel afzonderlijk systeem binnen de organisatie met zekerheid worden beantwoord.
Vaak wordt het verkeerde probleem opgelost
Op dit punt trekken veel bedrijven de verkeerde conclusie. Ze denken dat ze meer overzicht nodig hebben: een centraal dashboard, een reportingomgeving of een Customer Service-console waarin alle statussen bij elkaar worden gebracht.
Dat kan het zoeken absoluut sneller maken. Maar het lost het onderliggende probleem niet noodzakelijk op. Zet alle vier de statussen op één scherm en je ziet nog steeds:
- Webshop: Fulfilled
- ERP: Released
- WMS: Packed
- Vervoerder: Label created
De informatie is nu gemakkelijker te vinden. De onzekerheid is precies hetzelfde gebleven.
Een dashboard vraagt in feite aan ieder systeem: wat denk jij dat op dit moment waar is? Het vraagt niet: wat is er daadwerkelijk gebeurd?
Een status is de interpretatie van een systeem op basis van de events die het heeft ontvangen. Een event is het bewijs dat er daadwerkelijk iets is gebeurd.
Vier interpretaties op één scherm vormen daarom niet automatisch één betrouwbaar antwoord.
Soms zorgen ze er alleen voor dat een medewerker sneller dezelfde afweging moet maken.
Je hebt geen distributed system gekocht: je hebt er één opgebouwd.
Geen retailer besluit op een ochtend om een distributed system te bouwen. Je kiest een webshop, daarna een marketplace connector, een ERP, een WMS, een fulfilmentpartner, een carrier-integratie, een retourenplatform en een boekhoudpakket. Iedere keuze is op zichzelf logisch.
Maar uiteindelijk heb je wel degelijk een distributed system opgebouwd: onafhankelijke systemen zonder gezamenlijke klok, zonder gedeelde taal en zonder één systeem dat het volledige proces kan overzien.
Distributed systems hebben bekende faalpatronen:
- Events komen in de verkeerde volgorde binnen.
- Berichten worden twee keer afgeleverd.
- Eén onderdeel stopt ongemerkt terwijl de andere systemen gewoon verdergaan alsof er niets aan de hand is.
Dat zijn geen theoretische IT-problemen. In de dagelijkse praktijk zie je ze terug als:
- Producten die worden oversold omdat een voorraadupdate te laat binnenkwam
- Dubbele pakketten omdat een magazijn dezelfde order twee keer ontving,
- Annuleringen die wel de webshop bereiken maar niet de fulfilmentpartner
- Retouren die fysiek zijn ontvangen maar nooit tot een terugbetaling leiden.
Op het eerste gezicht zijn dat allemaal verschillende problemen. Structureel hebben ze dezelfde oorzaak.
In dit voorbeeld was niets kapot
Kijk nog eens naar het voorbeeld hierboven. Er hoefde geen enkel systeem te crashen. Er was ook geen duidelijke integratiefout nodig. Iedere applicatie kan volkomen correct rapporteren op basis van het event dat zij kent: de webshop beschouwt de bestelling als afgehandeld, het ERP heeft de order vrijgegeven, het WMS of de fulfilmentpartner heeft het pakket ingepakt en de vervoerder weet alleen dat er een verzendlabel is aangemaakt.
Vier systemen die ieder gelijk hebben. En toch één vraag die niet betrouwbaar kan worden beantwoord.
Dat is het verschil tussen applicaties met elkaar verbinden en een Data Journey onder controle hebben.
Dit raakt ook aan een onderwerp uit onze KoneX Community Talks™: wat gebeurt er wanneer groei de complexiteit tussen systemen en processen zichtbaar maakt?
In Episode 3 van ‘When Growth Stalls’ bekijken we dit vanuit een andere invalshoek: waarom meer systemen en koppelingen niet automatisch betekenen dat je processen ook beter onder controle zijn.
Het doel is niet één ‘single source of truth’
Bedrijven krijgen vaak te horen dat ze één ‘single source of truth’ nodig hebben. Het klinkt aantrekkelijk, maar het is niet het juiste doel.
Verschillende systemen zijn namelijk terecht eigenaar van verschillende feiten.
De payment provider is eigenaar van de betaling, het WMS of de fulfilmentpartner weet wat daadwerkelijk is gepickt en verpakt, en de vervoerder is eigenaar van de fysieke scan. Al die informatie in één applicatie proberen onder te brengen is niet alleen onpraktisch, maar ook onwenselijk.
Het doel is dat de systemen die iets met een event moeten doen, het met elkaar eens zijn over wat er is gebeurd. Daarvoor zijn vier dingen nodig die een dashboard op zichzelf niet kan leveren.
Vier voorwaarden voor een betrouwbare Data Journey
- Identity : Een ordernummer uit de webshop, een ERP-order, een magazijnreferentie en een shipmentnummer van de vervoerder moeten met elkaar verbonden blijven. Anders kun je niet aantonen dat vier verschillende records over dezelfde transactie van dezelfde klant gaan.
- Ownership : Voor iedere status die tot een actie leidt, moet duidelijk zijn welk systeem leidend is. Zonder die afspraak gaan systemen ongemerkt elkaars informatie overschrijven.
- Meaning : Achter iedere status moet een duidelijk gedefinieerd event zitten, met een duidelijke betekenis voor wat er daarna moet gebeuren.
- Recovery : Events komen soms te laat, twee keer of helemaal niet binnen. De keten moet daarmee om kunnen gaan zonder bijvoorbeeld een zending of terugbetaling dubbel uit te voeren. Tegelijk moet zichtbaar zijn welke transactie is gestopt en waar dat is gebeurd.
Een betrouwbare eCommerce Data Journey ontstaat niet doordat webshop, ERP, WMS, fulfilmentpartner en vervoerder dezelfde data opslaan.
Ze moeten dezelfde transactie herkennen, weten welk systeem eigenaar is van welk event en correct reageren wanneer dat event plaatsvindt.
Als die vier zaken goed zijn geregeld, wordt een dashboard juist wél waardevol. Dan rapporteert het namelijk over een proces dat onder controle is, in plaats van dat het dashboard het gebrek aan controle probeert te compenseren. Het kan laten zien welke orders aandacht nodig hebben, welk event is mislukt, welk systeem verantwoordelijk is en of de klant daar last van heeft. Wat een dashboard nooit zou moeten doen, is een medewerker vier tegenstrijdige statussen laten vergelijken en vervolgens laten raden welke waarschijnlijk klopt.
AI maakt de gevolgen van dit probleem groter
Jarenlang was de echte integratielaag binnen veel retailers gewoon een mens: iemand die wist dat de cijfers in het ERP een uur achterliepen, dat de feed vanuit het magazijn na zes uur niet helemaal betrouwbaar was en welke status je op maandagochtend beter wel of niet kon vertrouwen.
Die kennis stond nergens beschreven. En automatisering neemt die kennis niet vanzelf over. Een AI-agent heeft geen instinct dat vertelt welke informatie verouderd is of welke status hij beter kan wantrouwen. Hij ziet de data die beschikbaar wordt gesteld en handelt op basis daarvan. Als de webshop bijvoorbeeld aangeeft dat een bestelling nog kan worden geannuleerd terwijl het magazijn het pakket al heeft ingepakt, kan een terugbetaling worden uitgevoerd terwijl het pakket alsnog wordt verzonden.
Een goede data-integratie en correcte data flows zijn doorslaggevend voor het succes van AI-agents.
Uit het Salesforce and MuleSoft 2026 Connectivity Benchmark Report blijkt dat de onderzochte ondernemingen gemiddeld 957 applicaties gebruiken, waarvan slechts 27% geïntegreerd is. Tegelijkertijd beschouwt 96% van de ondervraagde IT-leiders data-integratie als doorslaggevend voor het succes van AI-agents.
Het punt is niet dat AI onbetrouwbaar is. Het punt is dat automatisering precies dat laatste informele vangnet weghaalt op het moment dat verschillen tussen systemen machineleesbaar worden.
Automatisering is uiteindelijk zo betrouwbaar als de Data Journey waarop zij draait.
Een test die je deze week kunt uitvoeren
Je hoeft geen groot project te starten om te ontdekken waar je staat. Neem één recente bestelling waarbij iets is misgegaan en volg die van checkout naar betaling, voorraad, fulfilment, vervoerder, retour en financiële verwerking.
Dat is een Data Journey.
Schrijf bij iedere stap op:
- Welk systeem was eigenaar van de beslissing?
- Welk event had moeten plaatsvinden?
- Waar hielden de systemen op het met elkaar eens te zijn?
Komt bij meerdere probleemorders steeds dezelfde overdracht tussen systemen terug, dan heb je waarschijnlijk iets waardevollers gevonden dan een nieuw dashboard: een concreet onderdeel van de Data Journey dat aandacht nodig heeft.
Van gekoppelde applicaties naar een Data Journey onder controle
KoneX is ontwikkeld voor precies die laag. Je webshop, marketplaces, ERP, WMS, fulfilmentpartners, vervoerders en retoursystemen blijven doen waar ze goed in zijn.
KoneX stuurt de events tussen die systemen, zodat wat op de ene plek gebeurt op de juiste manier wordt begrepen door alle andere systemen die daarop moeten reageren : “from Pixel to Parcel”.
Het doel is niet om je bestaande applicaties te vervangen, maar om ervoor te zorgen dat wanneer er iets belangrijks gebeurt, ieder systeem dat daarvan moet weten het met de andere systemen eens is over wat er is gebeurd.
Je bedrijf heeft geen nieuw dashboard nodig.
Je systemen moeten het met elkaar eens zijn. De Data Journey moet kloppen.
Als de test hierboven onduidelijk eigenaarschap, tegenstrijdige statussen of overdrachtsmomenten blootlegt die steeds opnieuw handmatig moeten worden uitgezocht, zit het probleem waarschijnlijk niet in je reporting.
Breng je Data Journey in kaart
Plan een gratis Data Journey Audit. We brengen in kaart hoe een transactie door je webshop, ERP, WMS en vervoerders beweegt. We kijken waar informatie inconsistent wordt, events niet verder komen of handmatig ingrijpen nodig wordt en laten zien waar je de Data Journey weer onder controle kunt brengen.
