Waarom loopt de levertijdbevestiging steeds vast?
De meeste groothandelaren werken met een ERP dat een standaard doorlooptijd terugstuurt. Die doorlooptijd staat ingesteld per artikel of per klant, maar houdt geen rekening met de actuele voorraad, lopende inkooporders of pickdrukte in het magazijn. Het gevolg: de bevestiging gaat er wel snel uit, maar de levertijd klopt niet. De klant belt alsnog, het orderbeheer legt het handmatig recht, en ergens later in de keten zit een creditnota of een spoedverzending. Dat is het basisprobleem. Wat er in de praktijk boven op komt, is het volgende.
Vastlopen 1: de voorraadcheck zit op artikelniveau, niet op regelniveau
Een order van vijf regels kan op vier regels prima leverbaar zijn en op één regel geblokkeerd zitten door een tekort. Het ERP toont de order als 'leverbaar', omdat de artikelcheck groen is op productniveau maar niet splitst naar de gevraagde hoeveelheid per orderregel. Wat er dan gebeurt: de bevestiging gaat eruit met een levertijd die alleen voor vier van de vijf regels haalbaar is. De klant verwacht een complete zending. Die komt niet. Het handmatigwerk begint pas als de pick-bon er al ligt. Op dat moment is de schade al gedaan: een teleurstelling bij de klant en extra handelingen in het magazijn. De oplossing is niet complexer dan een check op regelniveau vóórdat de bevestiging de deur uitgaat. Maar dat vereist dat het systeem die twee stappen koppelt, en de meeste standaardpakketten doen dat niet standaard.
Vastlopen 2: inkooporders zitten niet in het bevestigingsproces
Een artikel is uitverkocht, maar staat over vier dagen op de kade. Die informatie zit in het inkoopmodule, niet in het orderbevestigingsproces. De medewerker die de order behandelt, moet zelf overschakelen naar een ander scherm, de verwachte ontvangstdatum opzoeken, en die datum verwerken in een handmatige bevestiging. Als het druk is, slaat iemand die stap over en stuurt een vage termijn. De klant merkt het als de zending niet komt. Het systeem dat de bevestiging uitstuurt, heeft simpelweg geen zicht op de inkoop. Koppel je die twee, dan kun je een realistische datum berekenen: beschikbare voorraad levert morgen, de rest volgt op dag X als de inkoopontvangst geregistreerd is. Dat is beter dan een standaardtermijn die voor niemand iets zegt.
Vastlopen 3: klantspecifieke afspraken worden niet meegenomen
Veel groothandelaren hebben klanten met specifieke afspraken: vaste leverdag per week, minimale order per zending, of een contractlevertijd van 24 uur. Die afspraken staan soms in het CRM, soms in een aparte spreadsheet, soms alleen in het hoofd van de accountmanager. De automatische bevestiging heeft er geen weet van. De klant die een afspraak heeft voor levering op dinsdag krijgt een bevestiging voor donderdag, belt zijn accountmanager, die corrigeert handmatig. Drie minuten per order klinkt niet veel, maar tel het op over honderd orders per dag en je hebt een structureel capaciteitsprobleem. De fix is niet ingewikkeld: klantspecifieke leverparameters moeten in het systeem zitten dat de bevestiging genereert, niet ernaast.
Wat werkt dan wel?
Een automatische levertijdbevestiging die klopt, combineert drie databronnen op het moment van orderontvangst: actuele voorraad per orderregel, verwachte inkoopontvangsttijden, en klantspecifieke leverafspraken. Dat klinkt als een groot project, maar in de praktijk gaat het om drie gerichte koppelingen bovenop het bestaande ERP. Je hoeft het kernsysteem niet te vervangen. Een AI Worker die de orderregel leest, de drie bronnen raadpleegt en een datum berekent, kan dit voor het overgrote deel van de orders overnemen. De uitzonderingen, een artikel dat nergens in zit of een klant met een ongebruikelijke afspraak, leg je neer bij een medewerker. Die beslist. Zo blijft het handelingsvolume beheersbaar en gaat de bevestiging de deur uit met een datum die je kunt nakomen. Dat is het verschil tussen een orderbevestiging als administratief formaliteit en een orderbevestiging als afspraak.