Een melding komt binnen: een gebruiker kan niet inloggen, een printer doet het niet, een server geeft foutmeldingen. Iemand op de servicedesk zet dat om in een ticket, kiest een categorie en bepaalt de urgentie. Kan AI dat overnemen? Grotendeels wel, met een belangrijke uitzondering die per bedrijf verschilt.
Drie assen geven de doorslag: volume, oordeelsruimte en klantcontact.
Het volume is hoog. Een servicedesk verwerkt dagelijks tientallen tot honderden meldingen, en veel daarvan zijn variaties op een klein aantal bekende problemen: wachtwoord vergeten, geen toegang tot een share, laptop start niet op. Bij hoge volumes en herhaling is een taak per definitie geschikt om te automatiseren, omdat een model leert van patronen die zich vaak herhalen.
De oordeelsruimte is beperkt. Urgentie en categorie volgen meestal uit een beslisboom: hoeveel gebruikers zijn getroffen, is er een workaround, welk systeem is het. Dat is precies het soort werk waar tekstmodellen goed in zijn: een melding lezen, de kenmerken eruit halen en tegen een categorisatiemodel aanhouden. Wat AI hier vandaag aankan is tekst — de meldingen zelf, vaak in vrije bewoordingen getypt door de gebruiker, en het terugvertalen daarvan naar een gestructureerd ticket.
Het klantcontact is functioneel, niet relationeel. Een gebruiker die een storing meldt, wil vooral dat het wordt opgepakt, niet dat er een gesprek ontstaat. Dat ligt anders zodra het misgaat of gevoelig wordt — zie daarvoor ook hoe een storing richting gebruikers wordt gecommuniceerd, want dat is een andere taak met een ander profiel.
De fysieke component speelt geen rol: dit is administratief werk aan een scherm, geen handeling aan apparatuur. De foutkosten zijn gemiddeld. Een verkeerd geprioriteerde melding leidt zelden tot directe schade, maar bij systemen die onder compliance vallen — een financieel systeem, een patiëntendossier — ligt dat anders, en de as compliance scoort hier dan ook hoger dan gemiddeld. Een storing in een omgeving met wettelijke meldplicht vraagt om een vastgelegde reden voor de indeling, niet alleen een label.
De zwakke plek is creativiteit, en dat is precies waarom dit geen volledige overname is. Een melding die niet in het bekende patroon past — een nieuwe combinatie van symptomen, een systeem dat voor het eerst uitvalt, een gebruiker die het probleem onduidelijk beschrijft — vraagt om iemand die nadenkt in plaats van indeelt. Daar hoort toezicht bij: AI stelt een categorie en urgentie voor, een mens keurt goed of stuurt bij, met reden. Dat is een andere inrichting dan volledige overname, en het is ook de meest voorkomende praktijk bij bedrijven die hiermee al werken.
Bij een bedrijf met een klein, overzichtelijk applicatielandschap en een paar honderd gebruikers is negentig procent van de meldingen een herhaling van iets dat al honderd keer is voorgekomen. Daar kan een model met een goed categorisatiemodel het grootste deel van de intake zelfstandig afhandelen, met een mens die alleen de uitzonderingen ziet.
Bij een bedrijf met veel legacy-systemen, maatwerksoftware en een historie van fusies is het patroon minder voorspelbaar. Meldingen zijn diverser, de categorieën zijn minder scherp afgebakend, en de kans dat een melding buiten het bekende patroon valt is groter. Daar blijft een groter deel van het werk bij een mens liggen, niet omdat AI het niet zou willen doen, maar omdat de invoer te ongestructureerd is om er automatisch iets betrouwbaars van te maken.
De randvoorwaarde is dus niet de techniek maar de intake: gestructureerde intakeformulieren en een uitgewerkt categorisatiemodel voor incidenten bepalen grotendeels hoeveel van dit werk vandaag al overdraagbaar is. Zonder die twee blijft het grootste deel handwerk, met AI als hulpmiddel in plaats van uitvoerder.
Dit is geen personeelsadvies en geen onderbouwing voor het inkrimpen van een servicedeskteam. Of en hoe een organisatie personele consequenties trekt uit veranderend werk, is aan de werkgever, en daarvoor gelden eigen wettelijke vereisten; zie voor de zorgvuldigheid die daarbij hoort de aandachtspunten bij het schrappen van functies. Deze pagina beschrijft alleen wat er met de taak zelf gebeurt.
Het is ook nuttig om deze taak niet los te zien van de rest van de IT-operatie. Incidentregistratie hangt samen met werk zoals het monitoren van systeemprestaties, dat vaak de vroege signalen geeft voordat een melding er is, en met beheertaken zoals het uitvoeren en controleren van back-ups of het actueel houden van stamdata, die dezelfde combinatie van hoog volume en beperkte oordeelsruimte kennen. Wie voor de hele IT-afdeling wil weten waar de verschuiving al zit, kijkt het beste naar alle taken samen, niet naar één ticketproces.
De uitkomst voor uw eigen servicedesk hangt af van hoeveel van uw meldingen in herkenbare patronen vallen en hoe goed uw intake al gestructureerd is. Dat verschilt per bedrijf en is niet met een vaste vuistregel te zeggen.
De gratis quickscan van FTE TO AI geeft daar een eerste indicatie voor: twaalf vragen, zonder account, met een indicatie welk deel van de uren in uw profiel vandaag door AI over te nemen is. De volledige werkscan, die het werk van een heel bedrijf taak voor taak doorrekent naar fte-capaciteit, is nog in aanbouw.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Antwoorden komen uit de kennisbank van deze site. Geen advies op maat, en geen scan van uw bedrijf.