De inbox is niet het probleem
Bij transportbedrijven komen orders, vrachtbevestigingen en instructies voor een groot deel nog per e-mail binnen. Planners lezen ze, typen de gegevens over in het TMS of planningssysteem, en gaan verder. Dat kost tijd, en het introduceert fouten. De belofte van AI e-mailverwerking is helder: laat de machine de e-mail lezen en de juiste velden invullen. Dat werkt ook, technisch gezien. Wat we keer op keer zien: de inbox zelf is het makkelijkste onderdeel van het vraagstuk.
Wat werkt er dan niet bij AI e-mailverwerking voor transportbedrijven?
De echte blokkade zit in wat er achter de e-mail schuilgaat. Een AI-worker leest een e-mail van een verlader: laadlocatie, loslocatie, gewicht, referentienummer. Prima. Maar dan moet die informatie ergens heen. En dan begint het: welk klantrecord hoort bij deze afzender? Klopt het adres in het systeem met het adres in de e-mail, of heeft de klant drie varianten in de stamdata? Is het referentienummer van de klant hetzelfde veld als jullie eigen ordernummer, of moeten ze naast elkaar leven? De AI haalt de data uit de e-mail, maar als de bestemming een rommelig systeem is, stopt de automatisering precies daar waar het pijn doet. Je hebt dan een slimme lezer gebouwd, maar geen werkende verwerking.
Het leermoment: begin bij de uitgang, niet bij de ingang
Wat wij inmiddels als werkwijze hanteren: begin bij de bestemming. Waar moet de verwerkte order terechtkomen, en in welke toestand? Als die vraag helder is, kun je terugwerken naar wat de AI uit de e-mail moet halen en hoe ze beide op elkaar aansluiten. Klinkt logisch, maar in de praktijk beginnen projecten vaak bij de e-mail zelf, omdat dat zichtbaar en tastbaar is. Het systeem erachter wordt aangenomen als bekend terrein. Dat is bijna altijd te optimistisch. Stamdata met inconsistente klantrecords, vrijvelden die per planner anders gebruikt worden, systemen waar je alleen via een verouderde API bij kunt: dat zijn de dingen die een half uur voorwerk worden, of drie weken. Het onderscheid tussen die twee maak je door er vroeg naar te kijken.
Wanneer is AI e-mailverwerking dan wél direct inzetbaar?
Er zijn situaties waarin het snel gaat. Als je een beperkte set vaste verladers hebt met een consistent e-mailformat, is de extractie voorspelbaar en de matching eenvoudig. Als je TMS een goede API heeft en de stamdata op orde is, kun je van e-mail naar ingevulde order in productie brengen zonder grote bouwsessies. Als de organisatie de uitzonderingen bij een mens wil laten, en de AI alleen de rechte gevallen laat verwerken, werkt het principe van human in the loop goed: de AI doet het tikwerk voor de tachtig procent die helder is, de planner beslist over de rest. Maar als je verwacht dat de AI ook de uitzonderingen, de slechte data en de ambigu geformuleerde e-mails zonder tussenkomst afhandelt, dan stuur je op teleurstelling.
Wat je als transportbedrijf concreet kunt doen
Maak voor jezelf een eerlijke inventarisatie: hoeveel van je inkomende e-mails komt van een vaste set afzenders met een herkenbaar format? Hoe schoon is je klantenstamdata? Heb je een systeem met een toegankelijke API of exportmogelijkheid? Die drie vragen bepalen voor negentig procent hoe snel en glad een AI e-mailverwerking voor transportbedrijven in productie gaat. Zijn het antwoorden op alle drie goed, dan kun je snel beginnen. Is een van de drie een probleem, dan is dat het eerste project, en pas daarna de AI-verwerking. Dat klinkt als vertraging, maar het is het omgekeerde: het voorkomt dat je een automatisering bouwt die na twee maanden vastloopt op exacte dezelfde handmatige uitzonderingen als voorheen, alleen met een AI-laag eromheen die de planners niet vertrouwen.
