AI-use-cases afstemmen op de KPI's van je bedrijf

De meeste AI-programma's falen op dezelfde manier. Iemand ziet een demo, de organisatie koopt de tool, en zes maanden later kan niemand zeggen of het geholpen heeft. Het probleem is niet de tool. Het is dat de use case gekozen werd vanuit de aanbodzijde.

Vertrek van een cijfer dat je al rapporteert

Kies een KPI die al voorkomt in een rapport waarvoor iemand verantwoordelijk is. Geen nieuwe maatstaf die voor het project bedacht is — een bestaande, met een historiek, waarover iemand in een evaluatie bevraagd zou worden.

Die beperking doet meer werk dan ze lijkt. Ze sluit de meeste speculatieve use cases meteen uit, want die kunnen het cijfer dat ze zouden bewegen niet benoemen. En ze levert je gratis een nulmeting op.

Benoem de beslissing, niet de taak

"Supporttickets samenvatten" is een taak. "Bepalen welke klanten we deze week bellen" is een beslissing. Een taak automatiseren bespaart minuten. Een beslissing verbeteren beweegt de KPI.

Vraag: welke beslissing voedt deze informatie? Is het antwoord "geen, het is gewoon handig om te hebben", dan overleeft de use case geen budgetbespreking.

Schrijf het contrafeitelijke op vóór je begint

De meest voorkomende fout in AI-rapportering is aan de tool toeschrijven wat het cijfer sowieso deed. Noteer vóór de pilot start wat je verwacht dat de KPI doet zonder de ingreep, en hoe je het verschil zou zien. Een controlegroep is het beste. Een vooraf afgesproken seizoensbasislijn is aanvaardbaar. "We kijken er achteraf naar en beslissen dan" niet.

Een uitgewerkte vorm

Kun je de rechterkolom niet invullen, dan ben je niet klaar om te bouwen. Dat is een nuttige vaststelling, bereikt op een namiddag in plaats van na twee kwartalen.