Een storing is gemeld, het ticketsysteem staat op rood, en gebruikers willen weten: wat is er aan de hand, hoe lang duurt het nog, en wanneer krijg ik weer bericht. Dat is werk dat servicedesk- en communicatiemedewerkers dagelijks doen. De vraag hier is niet of AI tekst kan schrijven, maar of AI dit specifieke communicatiewerk zelfstandig kan overnemen. Het antwoord: deels, en het hangt sterk af van wat voor storing het is.
De taak scoort hoog op gestructureerdheid (4): een storingsmelding volgt vaak een vast patroon — wat is er mis, sinds wanneer, welke systemen zijn geraakt, wat is de verwachte oplostijd. Dat patroon is precies wat een taalmodel goed kan invullen, zolang de onderliggende informatie klopt. Ook fysiek (5) is geen belemmering: er is geen handeling in de echte wereld nodig, alleen tekst die de deur uit moet.
Daar staat tegenover dat klantcontact laag scoort (1). Dit is per definitie communicatie met mensen die vaak al gefrustreerd zijn omdat hun werk stilligt. De toon, het moment en de precisie van een bericht bepalen of gebruikers zich gehoord voelen of juist genegeerd. Een gegenereerd bericht dat feitelijk correct is maar de urgentie verkeerd inschat, doet meer schade dan geen bericht.
Foutkosten (3) zijn gematigd maar niet te verwaarlozen: een verkeerde oplostijd of een status die niet update, ondermijnt vertrouwen en leidt tot een stroom aan vervolgvragen — precies het werk dat je wilde besparen. Compliance (4) speelt mee zodra het incident valt onder SLA-afspraken of, in sommige sectoren, meldplicht: dan moet de communicatie aantoonbaar op tijd en volgens vaste normen zijn verstuurd. Oordeelsruimte (2) en creativiteit (2) zijn laag: er is weinig ruimte om zelf te bepalen wat je meldt, het is grotendeels het volgen van een sjabloon met actuele gegevens. Volume (4) is hoog: bij een grote storing gaat het om honderden of duizenden gebruikers die hetzelfde bericht nodig hebben, en dat is precies waar automatisering tijd vrijspeelt.
Drie assen bepalen het beeld. De gestructureerdheid maakt het technisch haalbaar: als de incidentstatus eenduidig vastligt in het systeem, kan een taalmodel daar een bericht uit opbouwen volgens een vast sjabloon. Maar het lage klantcontact zet daar een rem op — niet omdat AI geen correcte zin kan schrijven, maar omdat het risico van een verkeerd getimede of verkeerd toonzette melding hoger is dan bij interne of administratieve tekst. En de foutkosten maken dat toezicht nodig blijft: een status-update die uitgaat voordat een fix bevestigd is, of die de oplostijd te optimistisch inschat, leidt tot nieuwe klachten in plaats van minder.
Een voorbeeld maakt het concreet. Bij een storing in een intern e-mailsysteem, waar de impact bekend is en de oplostijd redelijk voorspelbaar, kan AI de eerste melding en de tussentijdse status-update opstellen op basis van het ticket, met een medewerker die kort goedkeurt voordat het bericht verstuurt. Bij een storing die de betaalfunctionaliteit van klanten raakt, met financiële gevolgen en onzekere oplostijd, ligt dat anders: daar is menselijke afweging nodig over wat je wel en niet zegt, en wanneer.
Bij een bedrijf met een volwassen statuspagina en een ticketsysteem dat automatisch de juiste velden vult, is het aandeel dat AI aankan groter: de tekst kan direct uit gestructureerde data komen. Bij een bedrijf waar storingen mondeling worden doorgegeven, in losse Slack-berichten of via een IT-manager die het zelf inschat, ontbreekt de gestructureerde basis en is er weinig dat AI zelfstandig kan opstellen. Ook de aard van de gebruikers telt: interne medewerkers accepteren een korte, feitelijke update; externe klanten met een contract en SLA verwachten een toon en volledigheid die eerder menselijke controle vraagt.
Deze taak staat niet los van de rest van de incidentketen. Of een storing effectief gecommuniceerd wordt, hangt af van hoe goed systeemprestaties gemonitord worden — zonder betrouwbare monitoring is er geen actuele status om te communiceren. Het hangt ook samen met hoe het incident geregistreerd en geprioriteerd wordt, want dat bepaalt welke gegevens er zijn om een bericht op te baseren. En in sommige gevallen loopt communicatie parallel aan het daadwerkelijke oplossen van het eerstelijns IT-incident, waarbij de update alleen zo goed is als de voortgang die daadwerkelijk gemaakt wordt.
Concreet: het opstellen van tekst op basis van vaste sjablonen, met de actuele incidentstatus als input, is haalbaar zodra die twee randvoorwaarden er zijn. Het besluit wanneer een bericht uitgaat, in welke toon, en of de oplostijd realistisch geformuleerd is, blijft bij de medewerker. Dat is geen tussenfase op weg naar volledige overname — het is de structuur die bij dit type communicatie past zolang de foutkosten van een misplaatst bericht hoger blijven dan de tijd die het kost om het te checken.
Als deze analyse ertoe leidt dat u nadenkt over de inzet van servicedesk- of communicatiemedewerkers, geldt dat daarvoor eigen wettelijke vereisten gelden rond werk en medezeggenschap; deze pagina geeft geen personeelsadvies en is geen onderbouwing voor een ontslagbesluit. Voor de bredere zorgvuldigheid rond functieveranderingen, zie zorgvuldigheid bij het schrappen van functies.
Wilt u weten hoeveel van de storingscommunicatie in uw eigen bedrijf vandaag al binnen deze randvoorwaarden valt? De gratis quickscan van FTE TO AI bestaat uit twaalf vragen, vraagt geen account, en geeft een indicatie van welk deel van de uren in dit profiel vandaag door AI over te nemen is. De volledige werkscan, met de uitgebreide taakanalyse per team, is nog in aanbouw — die bieden we hier bewust nog niet aan.
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.