AI in transport en logistiek: incident-afhandeling die meedenkt

Een pallet wordt om 06:30 gemeld als vertraagd. De chauffeur geeft via de boordcomputer een melding door. Tegelijkertijd mailt de klant om 07:15 waar zijn zending blijft. Uw binnendienst start de dag met drie openstaande vragen, één telefoontje en twee systemen die nog niet met elkaar gepraat hebben. Dit is geen uitzonderlijke ochtend. Dit is dinsdag.

De moeite zit niet in het beantwoorden van één vraag. De moeite zit in het tegelijk bijhouden van alle vragen, alle ritten, alle klanten die wachten op een update. Een agent lost dat niet in zijn eentje op. Maar hij kan een flink deel van het opzoekwerk en het klaarzetten van de communicatie uit uw binnendienst halen.

Incident-afhandeling is een informatieprobleem, geen communicatieprobleem

De meeste vertragingen kosten niet zoveel tijd om op te lossen. Ze kosten tijd omdat de informatie verspreid staat. De ritplanning staat in het TMS, de klantafspraken staan in het CRM, de contactpersoon staat soms nog in een Outlook-map. Uw medewerker rijdt alle drie af voordat ze een zinnige update kan sturen.

Een agent kan die opzoekvraag overnemen. Zodra een ritvertraging binnenkomt via de boordcomputer of via een handmatige melding, haalt de agent de relevante klantinformatie op, bekijkt de afgesproken levertijd, en zet een conceptbericht klaar. Uw medewerker leest het, past het aan waar nodig, en verstuurt. De agent schrijft niet zelf naar de klant.

Welk werk kost uw binnendienst elke dag de meeste tijd terwijl de informatie al in uw systemen staat? Dat is vrijwel altijd de plek waar een agent het meeste kan bijdragen.

Escalatieregels vooraf vastleggen voorkomt discussie op het moment zelf

In transport is timing kritiek. Een vertraging van twee uur bij een supermarkt heeft andere gevolgen dan dezelfde vertraging bij een bouwbedrijf. Niet elke klant belt. Sommige klanten willen alleen een mail. Anderen staan erop gebeld te worden zodra de verwachte aankomsttijd meer dan een kwartier afwijkt.

Die regels bestaan al bij de meeste transportbedrijven. Ze zitten alleen in het hoofd van de medewerker die de klant kent, niet in een systeem. Een agent maakt die kennis expliciet. U legt per klant of klantcategorie vast: melden bij afwijking van X minuten, via mail of telefoon, met of zonder alternatief aanbod. Zie ook hoe guardrails werken als beleidsinstrument om dit soort kennis beheersbaar te maken.

Dat heeft een bijkomend voordeel: bij nieuwe medewerkers of bij ziekte van een collega gaat de kennis niet verloren. De regels staan. De agent volgt ze. En als u een klantafspraak aanpast, past u één instelling aan.

Niet elke melding vraagt hetzelfde antwoord

Een kapotte koelunit op een vrachtwagen vol verse producten vraagt een andere reactie dan een aanhanger met bouwmaterialen die een uur later aankomt. Een agent kan het onderscheid niet altijd zelfstandig maken. Maar hij kan wel de juiste informatie ophalen zodat uw medewerker sneller beslist.

Denk aan: wat is de inhoud van de lading, wat zijn de contractuele afspraken, heeft deze klant een SLA, zijn er al eerdere incidenten met deze rit of dit voertuig? Die vragen neemt de agent voor zijn rekening. De beslissing, het bellen naar de klant, het inschakelen van een alternatief vervoerder: dat blijft bij uw medewerker.

Wilt u ook dat de agent bij ernstige incidenten een conceptmail klaarzet met een alternatief aanbod, dan is dat mogelijk mits de regels voor dat aanbod van tevoren zijn vastgelegd. Wat mag de agent aanbieden? Tot welk bedrag? Alleen voor vaste klanten of ook voor incidentele? Hoe meer dit op papier staat, hoe bruikbaarder de output van de agent.

Koppeling aan uw TMS of ritplanning is de technische sleutel

Een agent die werkt zonder toegang tot uw ritplanning is weinig waard in de context van incident-afhandeling. De koppeling is de investering die het mogelijk maakt. Veel transport management systemen hebben een API. Sommige werken via webhooks. Andere, oudere systemen kunnen via CSV-exports of e-mailmeldingen worden uitgelezen.

De drempel is lager dan u denkt. Wij zijn één echt niet-koppelbaar systeem tegengekomen in jaren. Bij integraties met bestaande systemen is de vraag bijna nooit of het kan, maar hoe netjes het kan. Een minder elegante koppeling via e-mail levert dezelfde tijdwinst op als een directe API-verbinding.

Wat u vooraf moet aanleveren: naam en versie van uw TMS of planningssoftware, een testomgeving of account met beperkte rechten, en één concreet voorbeeld van een incident-type dat u wilt automatiseren. Meer is voor de eerste fase zelden nodig.

Klantenservice en incident-afhandeling overlappen meer dan ze lijken

Klanten die bellen over een vertraging zijn in eerste instantie op zoek naar informatie: waar is mijn lading, hoe laat komt het, wat moet ik regelen. De helft van die vragen is te beantwoorden met wat al in uw systemen staat. Een agent kan het opzoekwerk doen voor uw medewerker die de telefoon opneemt.

Bij klantenservice automatiseren gaat het precies hierover: het opzoekwerk voor een antwoord, en de vervolgactie erna. De agent zet het klaar, uw medewerker verstuurt of beantwoordt. In transport is dat patroon direct toepasbaar op statusvragen, leveringsbevestigingen en wijzigingen in de planning.

Hoeveel vragen van dit type ontvangt uw binnendienst per dag? Is dat er vijf of zijn het er vijftig? Bij vijftig begint de tijdwinst al snel merkbaar te worden. Bij vijf is een agent misschien minder urgent, maar kan hij al wel nuttig zijn als de informatie verspreid staat over meerdere systemen.

Begin met het incident-type dat het vaakst voorkomt, niet het meest complexe

De neiging is om te beginnen bij het moeilijkste geval: de multimodale zending waarbij drie partijen betrokken zijn en de verantwoordelijkheid niet eenduidig is. Mijn advies is altijd het omgekeerde. Begin bij het incident dat het vaakst voorkomt, de regels het meest eenduidig zijn, en de output het meest voorspelbaar is.

In transport is dat vaak: ritvertraging door file of werkzaamheden, klant informeren, nieuwe aankomsttijd doorgeven. Geen discussie over aansprakelijkheid, geen alternatief vervoer nodig, gewoon een update. Dat proces staat snel. Uw binnendienst merkt meteen wat de agent oplevert. Daarna kunt u verder uitbouwen.

Zie ook welk proces geschikt is voor een agent als u twijfelt over waar te beginnen. De drie filters die daar beschreven worden, ritme, beschrijfbaarheid en een duidelijk einde, zijn direct van toepassing op incident-typen in transport.

Wat u maandag kunt doen

Zet uw binnendienst een uur bij elkaar en vraag welk type incident de meeste herhalende vragen oplevert. Schrijf de regels op die uw medewerkers nu impliciet kennen: wanneer bellen, wanneer mailen, wat aanbieden bij welk type vertraging, voor welke klantcategorie. U hoeft nog niets te bouwen. Maar dit overzicht is het startpunt voor een eerste gesprek over wat een agent voor u kan doen.