Zo bouw je de interne businesscase voor een AI-servicedesk

Een businesscase voor een AI-servicedesk is niet de ROI-som. De som is het makkelijke deel, en de rekenmethode staat in hoe je de ROI van AI op je servicedesk berekent. Het lastige deel is alles eromheen: welke kosten je mag meetellen, welke baten een kritische lezer overleven, hoe je iets bewijst voordat je echt geld uitgeeft, en welke mensen in het gebouw ja moeten zeggen. Deze post gaat over dat werk, de interne case die je bouwt zodat de cijfers landen in een kamer vol mensen die eerder optimistische voorstellen hebben gezien.

Krijg je dit deel goed, dan verkoopt de ROI-slide zichzelf. Krijg je het verkeerd, dan blijft een sterk ROI-getal alsnog hangen, omdat iemand in de kamer de aannames eronder niet vertrouwt.

Begin met een nulmeting, anders heb je niets om mee te vergelijken

De meest voorkomende fout is de nulmeting overslaan. Iemand stelt automatisering voor, iedereen vindt de wachtrij te lang, en de case rust op het gevoel "we doen veel tickets." Gevoelens overleven geen begrotingsvergadering.

Voordat je enige verbetering claimt, schrijf op waar je vandaag staat. Ticketvolume per maand. Ruwe verdeling tussen repetitieve verzoeken en echte problemen. Gemiddelde tijd tot eerste reactie. Hoeveel tickets worden doorgeschoven voordat ze bij de juiste persoon liggen. Hoe het team de repetitieve last ervaart. Je hebt geen perfect getal nodig. Je hebt een eerlijk getal nodig dat iedereen herkent, zodat je later naar een verandering kunt wijzen en zeggen "dit bewoog, en dit was het daarvoor."

Zonder nulmeting kun je niet bewijzen dat de AI iets deed. Dan pleit je verbetering tegen een herinnering, en herinnering is geen bewijs. Als je één ding uit deze post haalt, haal dit: meet eerst, stel daarna voor.

Welke kosten echt in de case horen

Een geloofwaardige kostenkant is breder dan het licentiebedrag. Als je alleen het abonnement noemt, vindt een scherpe CFO de kosten die je wegliet en vertrouwt de rest van je cijfers minder. Zet ze er zelf in.

Tel eerst de voor de hand liggende: de tool. Tel dan het koppelwerk, dat bij een laag-erbovenop-aanpak klein maar niet nul is, iemand moet de webhook opzetten en de statussen mappen. Tel de tijd om een pilot te draaien, want het team dat de AI in shadow mode bekijkt besteedt daar echte uren aan. Tel het interne eigenaarschap na go-live, want automatisering is niet klaar-en-vergeten, iemand stelt de confidence-drempels bij en bekijkt wat de agents deden. En als je kiest tussen dit zelf bouwen en het kopen, tel de werkelijke kosten van bouwen, die vrijwel altijd onderschat worden. Die afweging lopen we door in zelf bouwen versus kopen voor een AI-servicedesk.

Het punt van kosten eerlijk opsommen is geen bescheidenheid. Het is geloofwaardigheid. Een case die zijn eigen kosten benoemt, wordt op zijn baten geloofd.

Harde baten en zachte baten, en waarom je allebei nodig hebt

Splits je baten in twee emmers en label ze duidelijk.

Harde baten zijn de baten die je kunt verdedigen met een getal dat aan je nulmeting hangt. Tijd bespaard op triage doordat tickets gecategoriseerd en gerouteerd worden zonder dat een mens elk ticket eerst leest. Minder doorschuiven doordat de eerste routering vaker klopt. Snellere eerste reactie op de repetitieve tickets die een agent uit de kennisbank kan beantwoorden. Die vertalen naar euro's via je eigen kosten-per-ticket, en omdat ze teruggaan naar de nulmeting houden ze stand onder kritische vragen.

Zachte baten zijn echt maar moeilijker te beprijzen. Agents besteden minder van de dag aan repetitief werk en meer aan de interessante problemen, wat doorgaans helpt bij behoud van mensen. De kennisbank groeit als bijproduct van opgeloste tickets in plaats van als een gestrand kwartaalproject. Gebruikers krijgen sneller antwoord op de saaie dingen. Die tellen, en je moet ze opsommen, maar noem ze zacht. Zodra je een stellig eurobedrag hangt aan "betere sfeer," heeft een scepticus een reden om je hele case te wantrouwen. Benoem de zachte baten, houd ze zacht, en laat de harde baten het financiële argument dragen.

Een rekenvoorbeeld hier mag, zolang je het als fictief markeert. Puur ter illustratie, met ronde verzonnen aannames: als een desk 1.000 tickets per maand doet, en 300 repetitief zijn, en elk vijf minuten afhandeling bespaart, dan is dat 25 uur per maand terug. Dat zijn bedachte getallen om de vorm van de berekening te tonen, geen benchmark. Je echte getallen komen uit je nulmeting en je pilot, en dat is precies waarom je er een draait.

Gebruik shadow mode als bewijs, niet als belofte

Hier kan een AI-servicedesk-case sterker zijn dan de meeste automatiseringsvoorstellen: je kunt de claim bewijzen voordat je je eraan committeert, en voordat de AI ook maar één gebruiker raakt.

In shadow mode leest de AI echte tickets en produceert zijn analyse, zijn categorie, zijn prioriteit, zijn conceptreactie, als interne notities die alleen het team ziet. Er gaat niets naar gebruikers. Er wordt niets afgesloten. De AI laat gewoon zijn werk zien op live tickets, naast wat de mensen daadwerkelijk deden. Na een paar weken kun je vergelijken: hoe vaak koos de AI dezelfde categorie als een mens, hoe vaak was zijn conceptreactie bruikbaar, waar raakte hij in de war. Nu is je businesscase niet "we verwachten een automatiseringsgraad van 40 procent," maar "over drie weken op onze eigen tickets, dit had hij goed en hier had hij een mens nodig." Dat is een ander gesprek. Hoe je dit netjes opzet beschrijven we in een AI-uitrol draaien in shadow mode.

Shadow mode beantwoordt ook de angst "gaat het iets kapotmaken" direct, want tijdens de pilot kan dat niet, per ontwerp. De AI schrijft notities, mensen beslissen. Dat ene feit ontkracht meer bezwaren dan welke slide dan ook.

Weet welke stakeholder welke vraag stelt

Een businesscase wordt gelezen door verschillende mensen die elk om één ding geven. Als je ieders vraag beantwoordt voordat die gesteld wordt, gaat de case sneller. Loop hierop vooruit.

De CFO wil de terugverdientijd weten en de aannames eronder. Antwoord met de nulmeting, de eerlijke kostenkant en de harde baten, en wees expliciet over welke baten je niet hebt geprobeerd te beprijzen. Verstop de zachte niet, label ze gewoon.

Security wil weten wat er met data gebeurt voordat een model die ziet, en of je kunt laten zien wat de AI deed. Antwoord met de concrete mechanismen: persoonsgegevens gemaskeerd voordat ze het model bereiken, een overzicht van wat elke agent deed en waarom, en human-in-the-loop op alles wat onomkeerbaar is. Wijs ze op de echte details in plaats van geruststelling. Onze post over PII-maskering voor de servicedesk en de securitypagina zeggen meer dan een alinea beloftes.

De ondernemingsraad of personeelsvertegenwoordiging wil weten wat dit voor de banen van mensen betekent. Antwoord eerlijk: de AI neemt de repetitieve administratieve last, het team doet het werk dat een mens nodig heeft. Kader het als minder tickets die onaangeroerd blijven liggen, niet minder mensen. Als het plan echt inkrimping is, zeg dat gewoon, want een OR komt erachter en een case gebouwd op een vaag antwoord stort in zodra dat gebeurt.

De servicedesk-lead wil weten dat het niet meer werk maakt dan het wegneemt. Antwoord met de pilot: shadow mode betekent dat het team precies ziet wat het krijgt voordat er iets verandert voor gebruikers.

De valkuilen die anders-goede cases laten zinken

Twee valkuilen doden meer van deze voorstellen dan welk zwak getal dan ook.

De eerste is scope. Een case die belooft de hele servicedesk te automatiseren, wordt afgerekend op de hele servicedesk, en verliest, want geen eerlijke pilot levert alles in één keer. Verklein de scope. Kies de repetitieve, goed begrepen tickets. Bewijs het daar. Een bescheiden claim die je met pilotdata kunt onderbouwen wint van een stoutmoedige claim die je niet kunt onderbouwen.

De tweede is de ontbrekende nulmeting, die we al behandelden maar die herhaling verdient omdat hij blijft gebeuren. Als je niet in cijfers kunt zeggen hoe "voor" eruitzag, is elke "na"-claim aanvechtbaar, en een goede CFO vecht die aan.

Er is een derde, stillere valkuil: een groot project beloven. Wie budget goedkeurt is huiverig voor grote transformatieprogramma's, want die hebben ze zien uitlopen. Een case gekaderd als "een afgebakende pilot met een duidelijke uitgang" is makkelijker goed te keuren dan een case gekaderd als "een strategisch automatiseringsinitiatief." De pilotkadering is ook eerlijker, want een pilot is precies wat je eerst moet draaien. Dit sluit aan op de bredere planningsvraag in de AI-strategie van een IT-manager.

Veelgestelde vragen

Is de businesscase niet gewoon de ROI-berekening?

Nee. De ROI-berekening is het rekenwerk. De businesscase is alles wat het rekenwerk geloofwaardig en goedkeurbaar maakt: de nulmeting waarop het rust, de eerlijke kostenkant, de splitsing tussen harde en zachte baten, de pilot die de cijfers bewijst, en de antwoorden op de echte vraag van elke stakeholder.

Hoe lang moet de shadow-mode-pilot draaien voordat ik de case bouw?

Lang genoeg om een representatieve doorsnede van je ticketmix te zien, wat meestal een paar weken is in plaats van een paar dagen. Je wilt genoeg echte tickets dat de vergelijking tussen de analyse van de AI en wat mensen daadwerkelijk deden niet afhangt van een handvol gelukkige of ongelukkige voorbeelden.

Wat als ik geen schone nulmeting heb?

Meet dan nu, voordat je iets voorstelt. Zelfs een ruwe momentopname van twee weken van volume, repetitief aandeel en eerste-reactietijd wint van een voorstel gebouwd op een gevoel. Een case zonder nulmeting heeft niets om zijn geclaimde verbetering mee te vergelijken.

Hoe beantwoord ik de ondernemingsraad of personeelsvertegenwoordiging?

Eerlijk. Leg uit dat de AI de repetitieve administratieve last afhandelt zodat mensen het werk kunnen doen dat een mens nodig heeft, en wees rechtuit over of het plan personele veranderingen inhoudt. Een case gebouwd op een vaag antwoord hier valt uit elkaar zodra hij wordt onderzocht, en hij wordt onderzocht.

Echte service door echte mensen, het administratieve geploeter door machines. Bouw de case zo dat beide helften zichtbaar zijn, en de cijfers ergens stevig op staan.