En driftstörning har rapporterats, ärendesystemet står på rött, och användare vill veta: vad är det som är fel, hur länge dröjer det, och när får jag besked igen. Det är arbete som servicedesk- och kommunikationsmedarbetare gör dagligen. Frågan här är inte om AI kan skriva text, utan om AI kan ta över detta specifika kommunikationsarbete på egen hand. Svaret: delvis, och det beror starkt på vilken typ av driftstörning det gäller.
Uppgiften får högt betyg på strukturerbarhet (4): en incidentrapport följer ofta ett fast mönster — vad är fel, sedan när, vilka system är påverkade, vad är den förväntade lösningstiden. Det mönstret är precis vad en språkmodell kan fylla i bra, så länge den underliggande informationen stämmer. Även fysisk (5) utgör inget hinder: det krävs ingen handling i den verkliga världen, bara text som ska skickas ut.
Däremot får kundkontakt lågt betyg (1). Det handlar per definition om kommunikation med människor som ofta redan är frustrerade eftersom deras arbete ligger stilla. Tonen, tidpunkten och precisionen i ett meddelande avgör om användarna känner sig hörda eller tvärtom ignorerade. Ett genererat meddelande som är sakligt korrekt men feltolkar brådskan gör mer skada än inget meddelande alls.
Felkostnader (3) är måttliga men inte försumbara: en felaktig lösningstid eller en status som inte uppdateras undergräver förtroendet och leder till en ström av följdfrågor — precis det arbete man ville spara in på. Regelefterlevnad (4) blir relevant så snart incidenten omfattas av SLA-avtal eller, i vissa branscher, anmälningsplikt: då måste kommunikationen bevisligen ha skickats i tid och enligt fasta normer. Bedömningsutrymme (2) och kreativitet (2) är låga: det finns litet utrymme att själv avgöra vad man rapporterar, det handlar till stor del om att följa en mall med aktuella uppgifter. Volym (4) är hög: vid en stor driftstörning handlar det om hundratals eller tusentals användare som behöver samma meddelande, och det är precis där automatisering frigör tid.
Tre axlar avgör bilden. Strukturerbarheten gör det tekniskt genomförbart: om incidentstatusen är entydigt fastställd i systemet kan en språkmodell bygga upp ett meddelande utifrån en fast mall. Men den låga kundkontaktspoängen sätter en broms på det — inte för att AI inte kan skriva en korrekt mening, utan för att risken med ett felaktigt tajmat eller feltonat meddelande är högre än vid intern eller administrativ text. Och felkostnaderna gör att tillsyn förblir nödvändig: en statusuppdatering som skickas ut innan en lösning bekräftats, eller som är för optimistisk om lösningstiden, leder till nya klagomål istället för färre.
Ett exempel gör det konkret. Vid en driftstörning i ett internt e-postsystem, där påverkan är känd och lösningstiden rimligt förutsägbar, kan AI utarbeta den första rapporten och den löpande statusuppdateringen utifrån ärendet, med en medarbetare som kort godkänner innan meddelandet skickas. Vid en driftstörning som påverkar kunders betalfunktion, med ekonomiska konsekvenser och osäker lösningstid, ser det annorlunda ut: där behövs mänsklig avvägning om vad man säger och inte säger, och när.
Hos ett företag med en mogen statussida och ett ärendesystem som automatiskt fyller i rätt fält är den andel AI kan hantera större: texten kan komma direkt från strukturerad data. Hos ett företag där driftstörningar rapporteras muntligt, i lösa Slack-meddelanden eller via en IT-chef som gör en egen bedömning, saknas den strukturerade grunden och det finns litet som AI kan utforma på egen hand. Även användarnas karaktär spelar in: interna medarbetare accepterar en kort, saklig uppdatering; externa kunder med kontrakt och SLA förväntar sig en ton och fullständighet som snarare kräver mänsklig kontroll.
Denna uppgift står inte fristående från resten av incidentkedjan. Om en driftstörning kommuniceras effektivt beror på hur väl systemprestanda övervakas — utan tillförlitlig övervakning finns ingen aktuell status att kommunicera. Det hänger också samman med hur incidenten registreras och prioriteras, eftersom det avgör vilka uppgifter som finns att basera ett meddelande på. Och i vissa fall löper kommunikationen parallellt med det faktiska lösandet av förstalinjens IT-incident, där uppdateringen bara är så bra som de framsteg som faktiskt görs.
Konkret: att utarbeta text utifrån fasta mallar, med den aktuella incidentstatusen som indata, är genomförbart så snart dessa två förutsättningar finns på plats. Beslutet om när ett meddelande ska skickas, i vilken ton, och om lösningstiden är realistiskt formulerad, ligger kvar hos medarbetaren. Det är inte en mellanfas på väg mot fullständigt övertagande — det är den struktur som passar denna typ av kommunikation så länge felkostnaderna för ett missriktat meddelande förblir högre än tiden det tar att kontrollera det.
Om denna analys får er att fundera på användningen av servicedesk- eller kommunikationsmedarbetare gäller egna lagstadgade krav kring arbete och medbestämmande; denna sida ger inte personalrådgivning och utgör inte underlag för ett uppsägningsbeslut. För den bredare omsorgen kring förändringar av tjänster, se omsorg vid indragning av tjänster.
Vill ni veta hur stor del av kommunikationen vid driftstörningar i ert eget företag redan idag ryms inom dessa förutsättningar? Den kostnadsfria snabbanalysen från FTE TO AI består av tolv frågor, kräver inget konto, och ger en indikation på hur stor andel av timmarna i denna profil som idag går att låta AI ta över. Den fullständiga arbetsanalysen, med den fördjupade uppgiftsanalysen per team, är fortfarande under uppbyggnad — den erbjuder vi medvetet inte här ännu.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.