Orderstatus bewaken over leveranciers en kanalen: één statusbord voor de hele keten

Kort antwoord. Een overzicht van openstaande orders over al je leveranciers maak je door elke order langs één statusbord te leggen dat de hele keten dekt: ingekocht, betaald, verzonden, onderweg, binnen, doorgestuurd en geleverd. Je trekt statussen automatisch uit leveranciersportals, vervoerders en je verkoopkanalen samen, en je markeert per stap wat te laat is.

Een order is pas klaar als de klant het pakket in handen heeft. Alles daartussen is keten, en die keten staat verspreid over plekken waar je niet de baas bent. De leverancier heeft een eigen portal, de vervoerder een eigen track-en-trace, en bol en Amazon hebben hun eigen weergave van dezelfde order. Ik heb dat jaren zo gedraaid, en het probleem is nooit dat de informatie ontbreekt. Het probleem is dat niemand hem op één plek samenbrengt.

Waarom orderstatus over leveranciers en kanalen versplintert

Een doorsnee resellerorder doorloopt een vaste keten. Ontvangen op je kanaal, ingekocht bij de leverancier, betaald, verzonden door de leverancier, onderweg, binnengekomen bij jou, doorgestuurd naar de klant, geleverd, en soms retour. Elke stap leeft op een ander systeem. De inkoopstatus staat in de leveranciersportal of een orderbevestiging per mail. De zending onderweg staat bij PostNL, DPD of een buitenlandse vervoerder. De klantkant staat in je webshop, bij bol of bij Amazon.

Niemand van die partijen heeft er belang bij om jouw keten compleet te tonen. De leverancier stopt bij "verzonden". De vervoerder begint pas bij "label aangemaakt". Jouw kanaal weet alleen wat jij hebt teruggemeld. Het gat zit er precies tussenin, en dat gat is waar orders blijven hangen zonder dat iemand het ziet.

Wat één statusbord over de hele keten moet tonen

Het doel is grip, niet alleen tijdwinst. Ik wil op één scherm kunnen zien welke orders nog open staan, in welke stap ze hangen en welke daarvan kritiek zijn omdat een klant zit te wachten. Dat statusbord heeft per order minimaal nodig:

• de huidige stap in de keten, niet de status van één deelsysteem
• de leverancier en het kanaal waar de order vandaan komt
• de datum waarop de stap is ingegaan, zodat je verloop kunt meten
• een markering "te laat" zodra een stap zijn afgesproken doorlooptijd overschrijdt
• een markering "kritiek" als er een klant aan de andere kant op wacht

Het verschil tussen een leverancier die traag is met intern doorsturen en een leverancier die jouw klant laat wachten, is het hele punt. Het eerste is hinderlijk, het tweede is een refund of een slechte review. Een statusbord dat dat onderscheid niet maakt, is een lijst, geen stuurinstrument.

Eerst het proces doorlichten, dan pas bouwen

Voordat ik iets bouw, leg ik de bestaande keten plat op tafel. In een operatie die jaren is gegroeid zitten bijna altijd stappen die er ooit logisch waren en nu alleen ruis toevoegen. Een handmatige tussencontrole die een systeem inmiddels zelf doet. Een leverancier die je nog via mail najaagt terwijl zijn portal een nette statusexport heeft. Een dubbele invoer omdat twee tools nooit aan elkaar zijn geknoopt.

Dit is een bewuste stap, geen excuus om niets te bouwen. Sommige stappen kunnen weg, sommige kunnen slimmer, en pas wat overblijft is het waard om te automatiseren. Wie zijn rommel automatiseert, krijgt snellere rommel. De automatisering moet er komen, maar ze moet de goede keten bedienen.

Build versus buy: waar standaardpakketten stoppen

Er zijn goede standaardoplossingen voor delen van dit verhaal. Ordermanagementtools als Picqer, ChannelDock en GoedGepickt brengen orders uit meerdere kanalen samen, en verzendsoftware als Sendcloud of MyParcel geeft je een realtime overzicht van uitgaande zendingen met track-en-trace en signalen bij vertraging. Voor de kanaal-en-verzendkant moet je dat soort tools serieus overwegen voordat je zelf iets bouwt.

Waar het standaardpakket stopt, is de inkoopkant en jouw uitzonderingen. De meeste pakketten dekken het gelukspad: order in, label eruit, klant blij. Ze koppelen zelden netjes met de portals van twintig kleine leveranciers, ze rekenen geen kosten toe per leverancier en kanaal, en ze kennen jouw uitzonderingen niet. De order die deels uit voorraad gaat en deels op inkoop wacht. De leverancier die alleen een Excel mailt. De cross-border zending die door twee vervoerders gaat. Dat is de moat. Een statusbord dat ook die gevallen dekt, knoop je zelf aan elkaar: scrapers en portal-koppelingen voor de inkoopkant, je vervoerders-API voor onderweg, je kanalen voor de klantkant, en daaroverheen jouw eigen drempels voor te laat en kritiek.

Wanneer geldt een order als te laat

Te laat is geen vast getal, het is een afspraak per stap. Per leverancier en per kanaal stel je een verwachte doorlooptijd in, en alles wat daaroverheen gaat springt op je bord. Een leverancier met een vaste levertijd van twee dagen is op dag drie te laat. Een dropship-order die na 24 uur nog geen verzendbevestiging heeft, is verdacht. Door die drempels expliciet te maken, jaag je niet meer alle orders na, maar alleen de orders die het verdienen. De rest laat je met rust, omdat het systeem garandeert dat hij hem oppikt zodra het wel misgaat.