È stato segnalato un disservizio, il sistema di ticket è in rosso, e gli utenti vogliono sapere: cosa sta succedendo, quanto durerà ancora, e quando riceveranno un nuovo aggiornamento. Questo è un lavoro che gli addetti al servicedesk e alla comunicazione svolgono quotidianamente. La domanda qui non è se l'IA sappia scrivere testi, ma se l'IA possa svolgere autonomamente questo specifico lavoro di comunicazione. La risposta: in parte, e dipende molto dal tipo di disservizio.
Il compito ottiene un punteggio alto in struttura (4): una segnalazione di disservizio segue spesso uno schema fisso — cosa non funziona, da quando, quali sistemi sono coinvolti, qual è il tempo di risoluzione previsto. Questo schema è esattamente ciò che un modello linguistico può compilare bene, purché le informazioni sottostanti siano corrette. Anche l'aspetto fisico (5) non è un ostacolo: non è richiesta alcuna azione nel mondo reale, solo un testo da inviare.
D'altra parte, il contatto con il cliente ottiene un punteggio basso (1). Si tratta per definizione di comunicazione con persone spesso già frustrate perché il loro lavoro è bloccato. Il tono, il momento e la precisione di un messaggio determinano se gli utenti si sentono ascoltati o, al contrario, ignorati. Un messaggio generato che è fattualmente corretto ma valuta male l'urgenza causa più danni di nessun messaggio.
I costi degli errori (3) sono moderati ma non trascurabili: un tempo di risoluzione errato o uno stato che non si aggiorna mina la fiducia e provoca un'ondata di domande di follow-up — esattamente il lavoro che si voleva risparmiare. La conformità normativa (4) entra in gioco non appena l'incidente rientra in accordi SLA o, in alcuni settori, in obblighi di segnalazione: in tal caso la comunicazione deve essere dimostrabilmente inviata in tempo e secondo standard fissi. Il margine di giudizio (2) e la creatività (2) sono bassi: c'è poco spazio per decidere autonomamente cosa comunicare, si tratta in gran parte di seguire un modello con dati aggiornati. Il volume (4) è alto: in caso di un grande disservizio si tratta di centinaia o migliaia di utenti che necessitano dello stesso messaggio, ed è esattamente lì che l'automazione fa risparmiare tempo.
Tre assi determinano il quadro. La struttura rende il compito tecnicamente fattibile: se lo stato dell'incidente è registrato in modo univoco nel sistema, un modello linguistico può costruirci sopra un messaggio secondo un modello fisso. Ma il basso contatto con il cliente frena questo processo — non perché l'IA non sappia scrivere una frase corretta, ma perché il rischio di una comunicazione mal tempificata o dal tono sbagliato è maggiore rispetto a un testo interno o amministrativo. E i costi degli errori fanno sì che la supervisione resti necessaria: un aggiornamento di stato inviato prima che una soluzione sia confermata, o che valuta il tempo di risoluzione in modo troppo ottimistico, genera nuovi reclami invece di ridurli.
Un esempio lo rende concreto. In caso di un disservizio in un sistema email interno, dove l'impatto è noto e il tempo di risoluzione ragionevolmente prevedibile, l'IA può redigere la prima segnalazione e l'aggiornamento di stato intermedio sulla base del ticket, con un dipendente che approva brevemente prima dell'invio del messaggio. In caso di un disservizio che colpisce la funzionalità di pagamento dei clienti, con conseguenze finanziarie e tempi di risoluzione incerti, la situazione è diversa: qui è necessaria una valutazione umana su cosa dire e cosa non dire, e quando.
In un'azienda con una pagina di stato matura e un sistema di ticket che compila automaticamente i campi corretti, la quota che l'IA può gestire è maggiore: il testo può derivare direttamente da dati strutturati. In un'azienda dove i disservizi vengono comunicati verbalmente, in messaggi Slack sparsi o tramite un IT manager che valuta di persona, manca la base strutturata e c'è poco che l'IA possa redigere autonomamente. Conta anche la natura degli utenti: i dipendenti interni accettano un aggiornamento breve e fattuale; i clienti esterni con un contratto e uno SLA si aspettano un tono e una completezza che richiedono più facilmente un controllo umano.
Questo compito non è isolato dal resto della catena degli incidenti. Se un disservizio viene comunicato efficacemente dipende da quanto bene le prestazioni del sistema vengono monitorate — senza un monitoraggio affidabile non c'è uno stato aggiornato da comunicare. Dipende anche da come l'incidente viene registrato e classificato per priorità, poiché questo determina quali dati sono disponibili per basare un messaggio. E in alcuni casi la comunicazione procede in parallelo alla vera e propria risoluzione dell'incidente IT di primo livello, dove l'aggiornamento è valido solo quanto il progresso effettivamente realizzato.
In concreto: la redazione di testi basati su modelli fissi, con lo stato attuale dell'incidente come input, è fattibile non appena queste due condizioni sono soddisfatte. La decisione su quando inviare un messaggio, con quale tono, e se il tempo di risoluzione è formulato in modo realistico, resta al dipendente. Non si tratta di una fase intermedia verso una presa in carico completa — è la struttura adatta a questo tipo di comunicazione finché i costi degli errori di un messaggio inopportuno restano superiori al tempo necessario per verificarlo.
Se questa analisi la porta a riflettere sull'impiego di addetti al servicedesk o alla comunicazione, ricordiamo che a tale riguardo si applicano specifici requisiti di legge in materia di lavoro e di partecipazione dei lavoratori; questa pagina non fornisce consulenza sul personale e non costituisce una motivazione per una decisione di licenziamento. Per un approfondimento più ampio sulla dovuta cautela nei cambiamenti di funzione, si veda attenzione nella soppressione di funzioni.
Vuole sapere quale parte della comunicazione sui disservizi nella sua azienda rientra già oggi in queste condizioni? La quickscan gratuita di FTE TO AI è composta da dodici domande, non richiede un account, e fornisce un'indicazione della quota di ore in questo profilo che l'IA può oggi rilevare. La werkscan completa, con l'analisi approfondita dei compiti per team, è ancora in fase di sviluppo — non la proponiamo ancora qui, deliberatamente.
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.