Op orders@ komt om half negen een mail binnen: "Goedemorgen, in order 24-1342 wil ik graag 10 stuks in plaats van 40. De rest mag blijven zoals het is."
Om tien uur leest een collega hem. Ze opent het ERP en ziet dat de order om negen uur is gepickt en klaarstaat voor verzending. Nu moet er iemand naar het magazijn, de doos weer open, en anders gaan er 30 stuks naar een klant die ze niet wil hebben.
Het verzoek was op tijd. De mail lag alleen te lang.
Waarom juist deze mail niet kan wachten
De meeste mail in een gedeelde mailbox wordt niet slechter van een uur wachten. Een vraag om een offerte is om tien uur net zo goed te beantwoorden als om half negen. Een verzoek om een order te wijzigen of te annuleren is anders: de waarde ervan neemt af met elke stap die de order in uw bedrijf zet. Zolang de order openstaat, is het een kleine aanpassing in het ERP. Is hij gepickt, dan is het werk in het magazijn. Is hij verzonden, dan is het een retour.
Toch komt zo'n verzoek op dezelfde stapel als al het andere. Het onderwerp is vaak nietszeggend, zoals "order 24-1342" of "Re: uw orderbevestiging". Wie de mailbox van boven naar beneden afwerkt, ziet niet dat er een klok loopt.
Wat de verwerking doet
Uw mailbox wordt elke minuut gecontroleerd. Een wijzigingsverzoek dat om half negen binnenkomt, is dus niet afhankelijk van wanneer iemand de mailbox opent.
Ze herkent het verzoek. Een AI-model haalt uit de mail wat er nodig is: dat de klant iets wil veranderen aan een bestaande order, welk ordernummer het is, en wat er anders moet. Annuleren, een ander aantal, een artikel erbij of eraf, een ander afleveradres. Dat zijn vaste velden, geen samenvatting in losse tekst. Noemt de klant geen ordernummer omdat hij reageert op uw orderbevestiging, dan haalt de verwerking de eerdere mails uit dezelfde wisseling erbij. Daar staat het nummer wel in. Hoe dat werkt, leest u in Waarom een losse mail niets zegt.
Ze kijkt hoe ver de order is. Met het ordernummer vraagt de verwerking de order op bij uw ERP, via de API van uw systeem. Ze controleert of de order bij de afzender hoort, en op welke status hij staat. Dat bepaalt de route.
Ze legt de wijziging voor. Staat de order nog open, dan krijgt een collega een mail met de vraag erin: de order, de huidige status, en wat de klant wil veranderen. Met één klik kiest ze wat er gebeurt, bijvoorbeeld "wijziging doorvoeren" of "niet doorvoeren, ik neem contact op". Reageert ze niet binnen de tijd die u instelt, dan gaat de vraag naar een volgende collega. Want bij dit soort verzoeken is een vraag die blijft liggen precies het probleem. Hoe zo'n escalatie doorloopt, staat in Spoedmail die niemand oppakt.
Ze voert het door in uw ERP. Na de klik zet de verwerking de wijziging zelf in het ERP, als de API van uw systeem dat toelaat: de order annuleren, een regel aanpassen of een adres wijzigen. Biedt uw ERP die mogelijkheid niet via de API, dan doet de collega het zelf. Ze heeft dan wel alles al voor zich en hoeft niets meer op te zoeken.
Ze bevestigt het aan de klant. De klant krijgt antwoord op zijn eigen mail, in hetzelfde gesprek. De tekst schrijft u zelf, met de gegevens uit het ERP erin:
Goedemorgen,
Uw order 24-1342 is aangepast. U ontvangt 10 stuks in plaats van 40. De leverdatum blijft dinsdag 14 oktober.
Waarom er een collega tussen zit
Een statusvraag beantwoorden is lezen. Er verandert niets in uw systeem, en daarom kan dat helemaal automatisch, zoals beschreven in Waar blijft mijn bestelling? Het antwoord staat al in uw ERP.
Een order wijzigen is schrijven. Een verkeerd gelezen aantal of een annulering van de verkeerde order heeft gevolgen voor uw klant, uw voorraad en uw magazijn. Daarom staat er een klik van een collega tussen het verzoek en de wijziging. Wat de verwerking haar bespaart, is het zoeken: welke order, welke status, wat wil de klant precies. Het besluit blijft bij haar. Meer over die afweging leest u in Mail automatiseren zonder de controle kwijt te raken.
Wilt u na een tijd een eenvoudig geval wel automatisch laten doorgaan, zoals een annulering van een order die nog niet in behandeling is, dan kan dat. Dat is een keuze die u maakt per soort wijziging, niet een instelling voor alles tegelijk.
Als de order al verder is
Niet elk verzoek komt op tijd. De verwerking ziet aan de status in uw ERP hoe ver de order is, en kiest een andere route:
- Gepickt, nog niet verzonden. De vraag gaat naar de collega die het magazijn kan bereiken, met de status erbij, zodat ze kan beslissen of het magazijn de order nog tegenhoudt.
- Al verzonden. De klant krijgt geen automatische bevestiging. De vraag gaat naar een collega, die met de klant de retour of een oplossing afspreekt.
- Order onbekend of van een ander. Hoort het ordernummer niet bij de afzender, of bestaat het niet, dan verandert de verwerking niets en zet ze de mail bij een collega.
Komt het verzoek 's avonds binnen, dan kan de controle in het ERP meteen, en de vraag aan een collega de volgende ochtend als eerste. Zie Mail buiten kantooruren.
Staat het wijzigingsverzoek in een mail met nog andere vragen, dan krijgt elk deel zijn eigen route. Dat leest u in Eén mail, drie vragen.
Wat er nodig is aan uw kant
Een ERP met een API. Voor het opzoeken moet de verwerking een order en zijn status kunnen opvragen. Voor het doorvoeren moet de API ook wijzigen of annuleren toestaan. Heeft uw systeem een OpenAPI-beschrijving, dan lezen we die in en zien we meteen welke van die twee mogelijk zijn.
Een status die iets zegt. De verwerking kan alleen zien dat een order gepickt is als uw ERP dat bijhoudt. Kent uw systeem alleen "open" en "verzonden", dan is dat de grens waarop de verwerking kan sturen.
Afspraken over wat er wel en niet mag. Tot wanneer mag een klant een order nog wijzigen? Wie beslist bij een gepickte order? Die regels kent uw team al. Ze worden alleen vastgelegd in plaats van per keer bedacht.
Waar het ophoudt
Bijlagen lezen we niet mee. Stuurt een klant een aangepaste bestellijst als pdf of Excel, dan ziet de verwerking die inhoud niet. Zo'n verzoek gaat naar een collega.
Het magazijn tegenhouden doet de verwerking niet. Ze ziet dat een order gepickt is en zorgt dat de juiste collega dat meteen weet. Of de doos nog open kan, beslist uw team.
Kortom
Een verzoek om een order te wijzigen is de mail met de kortste houdbaarheid in uw mailbox. Laat de verwerking hem meteen herkennen, de order opzoeken in uw ERP en een collega met één klik laten beslissen. De klant krijgt een bevestiging in hetzelfde gesprek, en het verzoek ligt niet meer te wachten tot iemand toevallig de mailbox opent.