Tickets routeren of zelf antwoorden: welke AI-use case eerst?
Het functioneel beheerteam van een verzekeraar (14 fte) verwerkt jaarlijks 5.800 tickets: 34% inhoudelijke vragen over de werking van applicaties, 22% incidenten, de rest verzoeken en wijzigingen. Het ticketsysteem bevat vier jaar vrije-tekstbeschrijvingen. Het veld 'categorie' is echter maar in 61% van de tickets gevuld en kent 140 verschillende waarden, terwijl de officiële taxonomie 22 categorieën heeft. De manager wil AI inzetten om tickets automatisch te routeren én om eindgebruikers direct te antwoorden in het selfserviceportaal, zonder tussenkomst van een medewerker. Een SaaS-leverancier biedt beide aan voor 40.000 euro per jaar. FB heeft geen data scientist; het centrale data-team kan twee dagen per maand ondersteunen. De manager wil 'zo snel mogelijk live' met het zelfstandig beantwoorden, omdat daar de grootste besparing zit.
1. Beoordeel de geschiktheid van beide use cases. Welke heeft de beste kans van slagen en welke moet nu niet gebeuren? Onderbouw met concrete faalcriteria.
Read the worked answer
Beide use cases zijn technisch mogelijk, maar ze verschillen sterk in de gevolgen van een fout.
Routeren en suggesties aan de medewerker: geschikt als eerste stap. Volume is hoog, het werk is repetitief, en een fout heeft een lage prijs: het ticket belandt bij de verkeerde persoon of de medewerker negeert de suggestie. Er is een mens in de lus. Het faalcriterium is meetbaar (te veel misroutes, te veel overrides) en de terugvalsituatie is de huidige werkwijze.
Zelfstandig antwoorden aan eindgebruikers: nu niet. Hier is de fout duur: een onjuist antwoord over een polis of een uitkering schept verwachtingen en kan leiden tot een verkeerd besluit bij de klant. Er is geen mens in de lus, de kennisbasis is niet aantoonbaar actueel, en het team heeft niet de capaciteit om de antwoorden continu te toetsen. Bovendien is er geen enkele meting die nu al laat zien dat de antwoorden kloppen.
De volgorde is dus niet een kwestie van ambitie maar van faalkosten: begin met routeren, en pas als de kwaliteit aantoonbaar is, mag een smalle lijst van veelgestelde vragen worden geautomatiseerd. Andersom werken betekent leren op het duurste kanaal.
2. Aan welke datavoorwaarden moet eerst worden voldaan, en wat is daarbij de rol van FB?
Read the worked answer
De datavoorwaarden zijn hier de echte bottleneck, niet het model.
- Taxonomie opschonen. 140 waarden terug naar 22, met een migratie van bestaande tickets voor zover dat betrouwbaar kan. Zonder eenduidige labels leert een model de chaos over.
- Het labelveld verplicht maken bij het sluiten van een ticket, met een keuzelijst in plaats van vrije tekst. Dit is de belangrijkste structurele maatregel: elke maand zonder verplicht veld is een maand dataverlies.
- Een gelabelde testset van ongeveer 500 recente tickets, met de hand beoordeeld, zodat er een meetlat is voordat er iets live gaat.
- Privacy en leveringsvoorwaarden. Ticketteksten kunnen persoonsgegevens bevatten. Vóór livegang moet helder zijn waar de data wordt verwerkt, of de leverancier klantdata voor modeltraining gebruikt, en hoe lang teksten worden bewaard.
FB's rol: FB is eigenaar van de taxonomie en van de acceptatiecriteria, want FB kent het proces en de gebruikers. FB is niet de partij die het model bouwt of valideert; dat vraagt de twee dagen per maand van het data-team en een duidelijke opdracht. Belangrijk is dat FB de taxonomie niet samen met de leverancier vaststelt: de leverancier heeft belang bij een model dat snel 'werkt'.
3. Welke KPI's en stopcriteria spreek je af met de manager voordat de pilot begint?
Read the worked answer
Zonder vooraf vastgelegde stopcriteria wordt een pilot zelden gestopt; dan is de enige uitkomst 'doorgaan met verbeteren'.
KPI's voor routering: top-1-nauwkeurigheid op de testset (bijvoorbeeld minimaal 85%), aandeel misroutes dat door de medewerker wordt gecorrigeerd, en de override-rate. Die laatste is de eerlijkste maat: als medewerkers de suggestie structureel negeren, werkt het model niet voor hen, ongeacht de accuracy.
KPI's voor de effecten: gemiddelde doorlooptijd per ticket en het aandeel tickets dat bij de eerste toewijzing goed ligt. Besparing in uren is pas geloofwaardig als deze twee bewegen.
Stopcriteria, vooraf: override-rate boven 30% na acht weken betekent stoppen of herontwerpen; top-1 onder 70% op de testset betekent niet live gaan; en bij de eerste melding van een aantoonbaar onjuist automatisch antwoord aan een eindgebruiker gaat het zelfantwoord-kanaal direct uit.
Daarnaast een financiële afspraak: 40.000 euro per jaar vraagt om een onderbouwing in bespaarde uren. Bij 5.800 tickets is dat ongeveer 7 euro per ticket; dat is alleen haalbaar als de routering de doorlooptijd echt verkort en niet alleen een label toevoegt.