AI-ROI meten: een herhaalbare methode

AI-ROI meten draait om één discipline: meet het werk vóór je het verandert, verander één ding, en meet daarna hetzelfde werk opnieuw. De meeste AI-projecten kunnen hun waarde niet aantonen, niet omdat de techniek tekortschiet, maar omdat niemand een baseline heeft vastgelegd. Dan is er achteraf niets eerlijks om mee te vergelijken. Deze gids geeft je een herhaalbare methode die je op elke use case kunt toepassen, zonder opgeblazen cijfers of beloftes van leveranciers.

Waarom de meeste AI-ROI-claims onbetrouwbaar zijn

De cijfers in verkooppresentaties zijn meestal een marketingproduct. Ze beschrijven een ideale klant, een zorgvuldig gekozen metric of een besparing die nooit tegen een echte baseline is afgezet. Pas je diezelfde logica toe binnen je eigen organisatie, dan stort de businesscase in, want de vergelijking was nooit gegrond in jouw data. De oplossing is weinig sexy: behandel ROI als een meetvraagstuk, niet als een voorspelvraagstuk. Je voorspelt niet de toekomst, je observeert een voor-en-na op werk dat je toch al doet.

Dat houdt je ook eerlijk over de grenzen. AI verbetert niet elke taak, en sommige processen zijn te laag in volume of te wisselend om er baat bij te hebben. Een meting-eerst-aanpak legt dat vroeg bloot, vóór je geld uitgeeft, precies wanneer leren het goedkoopst is.

Stap 1: Stel baselines vast op het werk zoals het nu is

Documenteer vóór elke tooling hoe een proces nu presteert. Leg voor een repetitieve taak met hoog volume vier dingen consistent vast over een representatieve periode:

• Doorlooptijd per taak — hoe lang een bekwame medewerker over één eenheid werk doet, gemiddeld over veel gevallen, niet het snelste geval.
• Foutpercentage — hoe vaak het resultaat herstel, correctie of escalatie nodig heeft.
• Volume — hoeveel eenheden er per dag, week of maand passeren, inclusief seizoenspieken.
• Personele inzet op repetitief werk — hoeveel tijd van welke rollen naar de taak gaat die je wilt veranderen.

De baseline hoeft niet perfect te zijn, maar wel echt en opgeschreven. Haal hem waar mogelijk uit je eigen systemen — ticketlogs, CRM-tijdstempels, verwerkingswachtrijen — en niet uit het geheugen. Een degelijke baseline vraagt vaak dat je operationele data op orde is, daarom beginnen we trajecten regelmatig met data engineering voordat er een model wordt gebouwd.

Stap 2: Kies één use case met hoog volume en veel herhaling

ROI is het makkelijkst aan te tonen waar dezelfde taak duizenden keren voorkomt met een voorspelbare structuur: inkomende e-mail triëren, velden uit documenten halen, supporttickets classificeren, routinematige antwoorden opstellen voor menselijke controle. Vermijd maatwerk met veel oordeelsvorming voor je eerste case — niet omdat AI daar niet kan helpen, maar omdat de besparing lastiger te meten en makkelijker te betwisten is.

Hoog volume telt om een tweede reden: het verdeelt de bouwkosten. Een besparing van een paar minuten per geval is verwaarloosbaar bij tien gevallen per week en betekenisvol bij tienduizend. Kies de use case waar kleine winst per eenheid optelt. Weet je niet welk proces in aanmerking komt, dan begint ons werk rond AI-implementatie meestal met precies deze triage.

Een snelle toets voor een goede eerste use case

• De taak is frequent en gestructureerd, niet zeldzaam en maatwerk.
• Er is een heldere definitie van een correct resultaat.
• De benodigde data bestaat al en is toegankelijk.
• Een mens kan tijdens de uitrol meekijken om fouten te onderscheppen.

Stap 3: Modelleer de besparing vóór je bouwt

Met een baseline en een gekozen use case kun je de waarschijnlijke besparing eerlijk modelleren. De rekensom is simpel: schat welk deel van de taaktijd het systeem aannemelijk kan wegnemen of versnellen, pas dat toe op je echte volume, en trek de kosten van het draaien van het systeem ervan af — inclusief modelgebruik, hosting en de menselijke controle die overblijft. Houd de schatting conservatief en benoem je aannames hardop, zodat iedereen ze kan uitdagen.

Twee kosten worden standaard vergeten. De eerste is de doorlopende kost van inferentie en monitoring, die echt en terugkerend is; daar gaan we op in bij onze notitie over de productie-AI-stack. De tweede is de resterende menselijke inzet: goed ingerichte systemen laten mensen de output blijven controleren, zeker in het begin, dus de besparing is een vermindering van inspanning per geval, niet het verdwijnen ervan. Modelleer de realistische situatie, niet de fantasie van volledige automatisering.

Stap 4: Meet opnieuw na livegang

Dit is de stap die een prognose omzet in ROI. Zodra het systeem live is, meet je dezelfde vier baseline-metrics op hetzelfde soort werk, over een vergelijkbare periode. Nu heb je een echt voor-en-na, gegrond in je eigen data in plaats van een slide van een leverancier.

Meet lang genoeg om voorbij de nieuwheidsperiode te komen. Vroeg enthousiasme en vroege voorzichtigheid vertekenen de cijfers allebei, dus een stabiele meting vraagt meestal weken gestaag draaien, niet een paar dagen. Let ook op tweede-orde-effecten: een systeem dat gevallen sneller verwerkt maar het foutpercentage verhoogt, heeft geen geld bespaard maar de kost stroomafwaarts verplaatst. Accuratesse en kosten in productie blijven volgen is een vak apart, en hoort bij wat wij bedoelen met AI in productie draaien.

Een eerlijk uitgewerkt voorbeeld

Neem een backofficeteam dat inkomende documenten classificeert en routeert. De baseline laat een gestaag dagvolume zien, een consistente gemiddelde behandeltijd per document, en een meetbaar herstelpercentage als documenten verkeerd worden gerouteerd. Je bouwt een systeem dat elk document classificeert en de routering opstelt zodat een mens die bevestigt.

Na livegang daalt de behandeltijd per document, omdat de mens nu bevestigt in plaats van alles vanaf nul te lezen, en het percentage verkeerde routering daalt omdat de classificatie consistent is. De besparing per document is bescheiden. Maar vermenigvuldigd met het echte dagvolume en opgeteld over maanden loopt het op — terwijl de bouw- en draaikosten grotendeels vast zijn. In dit soort gevallen wordt de terugverdientijd doorgaans uitgedrukt in maanden, niet weken, en het eerlijke antwoord op "hoeveel maanden" hangt volledig af van je volume en je bouwkost, juist daarom telt de baseline. Wie je een universele terugverdientijd voorschotelt, heeft de meting overgeslagen.

Veelgemaakte fouten die een schone ROI-meting verpesten

• Geen baseline. Zonder een voor is er geen na, alleen een mening.
• Bruto besparing tellen. Trek draaikosten en resterende menselijke inzet af, anders is het cijfer fictie.
• Kwaliteit negeren. Sneller maar fouter is niet goedkoper.
• Te vroeg meten. Wacht de nieuwheidsperiode af voor een stabiele meting.
• Een use case met laag volume kiezen. De rekensom klopt zelden bij een zeldzame taak.

Waar te beginnen

Wil je waarde aantonen vóór je je vastlegt, dan is een gerichte audit het instappunt met het laagste risico: hij stelt baselines vast en identificeert een eerste use case die de moeite waard is. Daarna laat een proof of concept je echte voor-en-na-cijfers meten op je eigen data. Bekijk onze transparante prijzen — een audit start vanaf circa €2.500, een proof of concept vanaf circa €20.000 en volledig productiewerk vanaf €50.000 — of plan een vrijblijvend gesprek om je specifieke proces door te nemen. Meet eerst; het ROI-gesprek wordt een stuk eenvoudiger zodra je echte cijfers hebt.

Veelgestelde vragen