Je eigen automatiseringsplafond bepalen voor de servicedesk

De eerste vraag in bijna elk AI-servicedesk-gesprek is een variant op "hoeveel procent van de tickets kun jij automatiseren?" De vraag is begrijpelijk, maar de insteek klopt niet. Elk getal dat je leent uit een vendor-whitepaper of analistenrapport beschrijft de ticketmix, de ITSM-configuratie, het team en de risicobereidheid van iemand anders. Het vertelt je vrijwel niets over wat in jouw omgeving mogelijk is.

De betere vraag is: wat is jouw automatiseringsplafond, en hoe vind je dat zonder te gokken?

Dit artikel beschrijft een praktische methode: je eigen ticketdata analyseren, de categorieën identificeren waar autonome actie realistisch is, een harde grens trekken rond wat altijd menselijk blijft, een nulmeting doen, en daarna shadow mode gebruiken om alles te valideren voordat je ooit een live ticket aanraakt.

Waarom geleende cijfers misleiden

Als een leverancier zegt dat je X procent van je tickets kunt automatiseren, komt dat getal uit een gemiddelde van hun klantenbestand. De klanten met de hoogste percentages zijn doorgaans de organisaties met een smal, repetitief ticketcatalogus, een volwassen kennisbank en jaren consistente categorisering. Dat is het beste geval, niet de mediane klant.

Jouw omgeving heeft misschien tien keer zoveel variatie, inconsistente categorisering uit de beginfase van je ITSM-adoptie, of een ondersteuningsscope met maatwerkapplicaties waar geen standaard-AI iets van weet. Je businesscase ophangen aan een externe benchmark legt een kloof tussen verwachting en werkelijkheid die moeilijk terug te draaien is zodra stakeholders het in hun hoofd hebben.

En nog belangrijker: de vraag hoeveel je kunt automatiseren is minder nuttig dan de vraag wat je als eerste zou moeten automatiseren. Beginnen bij het plafond sla je de analyse over die je vertelt waar je de automatisering op moet richten.

Stap 1: lees je ticketmix voordat je iets aanraakt

Haal de ticketdata van de afgelopen zes tot twaalf maanden op uit je ITSM-platform. Je hebt minimaal nodig: categorie, subcategorie, afhandelingscode en de ruwe omschrijving of titel. Als je platform ze bijhoudt zijn kanaal en first-contact-resolutievlag ook nuttig.

Sorteer op volume. De tien tot vijftien hoogvolumecategorieën bevatten doorgaans het grootste deel van het totale aanbod. Daar zit de meeste grondstof voor automatisering. Maar volume alleen is niet het criterium, het is alleen de startplek.

Stel voor elke hoogvolumecategorie drie vragen:

1. Is het afhandelingspatroon consistent? Wachtwoordresets, VPN-aanvragen, printerinstallaties en software-installaties hebben doorgaans een tot drie afhandelingsroutes. Incidenten rondom een specifieke maatwerkapplicatie hebben er misschien vijftig.

1. Is de actie omkeerbaar? Tijdelijke bestandstoegang geven is omkeerbaar. Een account uitschakelen, een postvak verwijderen of een aankoop goedkeuren niet. Onomkeerbare acties horen in een mens-alleen-categorie, ongeacht het volume.

1. Heeft het ticket informatie nodig die er bij binnenkomst nog niet in zit? Als een ticket standaard drie verduidelijkingsvragen vereist voordat er iets kan gebeuren, helpt automatisering pas nadat die verduidelijking is ingebouwd. Dat is een apart probleem.

Stap 2: onderscheid terugkerende patronen van eenmalige vragen

Niet elke hoogvolumecategorie is echt repetitief. Een categorie als "Overig" of "Algemeen IT" kan duizenden tickets bevatten zonder enig gedeeld patroon. Volume in die categorieën telt voor niets in een automatiseringsanalyse.

Zoek naar tickets waarbij de afhandeling voorspelbaar is gegeven de input. Het duidelijkste signaal: een korte, consistente afhandelingscode gecombineerd met vergelijkbare taal in de omschrijving. Een cluster tickets die allemaal zoiets zeggen als "ik kan niet inloggen" en allemaal worden afgehandeld met "wachtwoord gereset" is een kandidaat voor automatisering. Een cluster waar de afhandelingscodes over twintig opties verspreid zijn niet.

Deze clusterstap vereist geen datascience-project. Een simpele draaitabel of een paar exports uit je ITSM-rapportagemodule is genoeg. Het punt is dat je een feitenbasis bouwt over jouw ticketpatronen, niet dat je aannames importeert van elders. Meer over hoe herhalende patronen eruitzien en wat je ermee kunt lees je in terugkerende tickets en hoe automatisering past. Hoe ITSM Autopilot aansluit op je bestaande platform om shadow mode en live automatisering te draaien staat in de documentatie.

Stap 3: stel een expliciete mens-alleen-lijst op

Elke organisatie heeft acties die altijd door een persoon goedgekeurd of uitgevoerd moeten worden. Wat er precies op die lijst staat hangt af van je compliancevereisten, je sector en je eigen risicotolerantie. Veel voorkomende punten:

• Elke actie die een formele wijzigingsregistratie triggert in je changemanagementproces.
• Account uitschakelen, postvak verwijderen of elke actie met een wezenlijke beveiligingsimpact.
• Acties met persoonsgegevens over gezondheid, financiën of HR.
• Elk ticket waarbij de gebruiker zich heeft uitgedrukt als gestrest of de zaak heeft geëscaleerd.
• Alles wat productiesystemen raakt tijdens een major incident.

Deze lijst hoort op papier. Het is geen implementatiedetail om later uit te zoeken; het is de grens die alles daarbuiten veilig maakt om stap voor stap te automatiseren. Zonder die lijst wordt elk gesprek over automatiseringsscope opnieuw een onderhandeling.

Het human-in-the-loop-principe is precies dit als systeemontwerp: een confidence-drempel per actietype, en een harde regel voor alles op de mens-alleen-lijst. Zie ook wanneer AI moet overdragen aan een mens voor hoe die drempel in de praktijk wordt ingesteld.

Stap 4: doe je nulmeting

Voordat je ook maar iets automatiseert, meet je de beginstand van de categorieën die je wilt automatiseren. De cijfers die je nodig hebt:

• Gemiddelde tijd tot eerste reactie per categorie.
• Gemiddelde afhandeltijd per categorie.
• First-contact-resolutiepercentage per categorie.
• Volume per categorie, per maand gesegmenteerd zodat je seizoenspatronen ziet.

Dit zijn je referentiepunten. Zonder die meting kun je later niet zeggen of automatisering iets heeft verbeterd. Je kunt claims maken, maar je kunt ze niet onderbouwen. En wanneer er iets misgaat, of wanneer een stakeholder de aanpak ter discussie stelt, heb je de voor-nametaling nodig om ergens op te kunnen staan.

De nulmeting dwingt je ook om de data nauwkeurig te bekijken, wat regelmatig problemen met je categorisatieschema blootlegt. Tickets die eigenlijk "wachtwoordreset" zijn, worden ingediend als "inlogprobleem" en "toegangsaanvraag" afhankelijk van wie ze indiende. Dat opschonen vóór je automatiseert voorkomt dat je automatisering bouwt op een kapotte taxonomie.

Stap 5: draai shadow mode voordat je handelt

Shadow mode is de praktijk waarbij de automatiseringsmotor echte tickets analyseert en de acties produceert die hij zou nemen, zonder ze daadwerkelijk te nemen. Elke output verschijnt als privé-interne notitie die alleen het team ziet. De voorgestelde actie van de agent, de toegekende confidence-score en de redenering zijn allemaal zichtbaar. De mens handelt het ticket normaal af.

Dit is geen pilot in de traditionele zin. Er is geen gedeeltelijke uitrol, geen geselecteerde gebruikersgroep, geen A/B-split. Shadow mode draait op dezelfde tickets als de normale workflow, onzichtbaar en parallel. De waarde is dat je echte confidence-scores opbouwt op je echte ticketmix voordat je ooit de schakelaar naar live actie omzet.

Waar je op let: kloppen de voorgestelde acties? Is de confidence-score gekalibreerd, dat wil zeggen: correleert een hoge score ook echt met correcte acties? Zijn er categorieën waar de agent het ticket consistent verkeerd leest omdat de omschrijvingen te vaag zijn of de categorisering inconsistent?

De shadow-mode-fase laat ook het plafond zien waar je aan het begin naar zocht. Als de agent bij zestig procent van de tickets in een categorie een hoge confidence-score haalt en bij de overige veertig procent consequent onder de drempel blijft, heb je een datagestaafd beeld van wat in die categorie automatiseerbaar is in jouw omgeving. Dat is een getal dat je zelf hebt gemeten, niet geleend. Een uitgebreide beschrijving van shadow mode als uitrolmethode staat in shadow mode als AI-uitrolfase.

Wat je rapporteert in plaats van een enkel percentage

Aan het einde van dit traject heb je geen enkel automatiseringspercentage. Je hebt een tabel: categorie voor categorie het geschatte automatiseerbare aandeel, de mens-alleen-uitzonderingen, de basismetrics en de shadow-mode-confidence-verdeling. Die tabel is een veel sterker fundament voor een businesscase dan een enkel getal, en hij is verdedigbaar onder druk.

Voor managementrapportage zijn de nuttigste metrics niet "procent geautomatiseerd" maar: de daling in tijd tot eerste reactie voor de categorieën in scope, het volume tickets dat is afgehandeld zonder menselijke actie in die categorieën, en de foutrate in de geautomatiseerde acties, dat wil zeggen gevallen waar de agent handelde en de uitkomst niet klopte of handmatig gecorrigeerd moest worden.

Tijd tot eerste reactie is vaak het getal met de meeste organisatorische impact, want het is wat gebruikers merken. Een ticket dat in twee minuten een accurate, nuttige eerste reactie krijgt in plaats van na twee uur is een zichtbare verbetering, ongeacht of de uiteindelijke afhandeling geautomatiseerd of menselijk was. Meer hierover in autonome ticketafhandeling en wat het echt betekent.

De juiste lens voor servicedesk-automatisering is geen plafond dat je leent van een benchmark. Het is een vloer die je opbouwt vanuit je eigen data, categorie voor categorie, met een shadow-fase die de aannames valideert voordat er iets live gaat.

Veelgestelde vragen

Waarom kan ik geen branchecijfers als startpunt gebruiken?

Benchmarks beschrijven het gemiddelde van een populatie waar jij geen deel van uitmaakt. Jouw ticketmix, de scope van je team, je ITSM-configuratie en de volwassenheid van je kennisbank zijn allemaal anders. Een benchmark kan stakeholder-verwachtingen verankeren aan een getal dat geen basis heeft in jouw werkelijkheid. Begin met je eigen data.

Wat produceert shadow mode precies?

Shadow mode produceert privé-interne notities op elk ticket met de actie die de agent zou hebben genomen, de confidence-score en de redenering. Er wordt geen actie ondernomen op het live ticket. Je bouwt echte data op over je echte ticketmix zonder enig risico voor de servicekwaliteit.

Welke ticketcategorieën zijn nooit goede automatiseringskandidaten?

Elke categorie waar de actie onomkeerbaar is zonder een formeel goedkeuringsproces, elke categorie met gevoelige persoonsgegevens, en elke categorie waar de afhandeling afhankelijk is van informatie die niet met het ticket meekomt. Die horen op een expliciete mens-alleen-lijst.

Hoe lang moet ik shadow mode draaien voordat ik live ga?

Lang genoeg om een statistisch betekenisvolle steekproef per categorie te verzamelen, doorgaans enkele weken minimaal voor een drukke servicedesk. De belangrijkere trigger is confidence-kalibratie: wanneer je kunt aantonen dat outputs met een hoge score consistent correct zijn over meerdere reviewers, heb je het signaal dat je nodig hebt.

Kan ik een categorie gedeeltelijk automatiseren?

Ja, en dat is vaak het juiste antwoord. Automatiseer de erkenning en triage-stappen, houd de afhandeling menselijk totdat vertrouwen is opgebouwd, en breid uit naarmate confidence-data zich opstapelt. Volledige end-to-end-automatisering van een categorie is een bestemming, niet een startpunt.

Echte service door echte mensen. Herhalend administratief werk door machines, dat is de enige versie van automatisering die de moeite waard is om naar toe te bouwen.