Quando il Service Desk AI chiede troppo: misurare la fatica dei dipendenti

Il segnale che mancava nel cruscotto

Un dipendente scrive al supporto: il portatile non si collega alla VPN. L’agente AI chiede il sistema operativo, poi uno screenshot, poi se il problema si presenta anche da casa. Il ticket forse si chiuderà senza intervento umano, ma quella persona ha dovuto tornare tre volte sulla stessa richiesta. Dal punto di vista del reporting è un successo di automazione; dal suo, una mattinata interrotta.

Le note di ServiceNow del 10 settembre 2026 descrivono un nuovo indicatore dei follow-up dello specialista AI L1: misura quanto spesso l’agente torna a chiedere informazioni al richiedente, per individuare i punti in cui le richieste si fermano o le istruzioni sono poco chiare. Nello stesso aggiornamento compaiono lettura degli allegati e protezioni per dati HR sensibili. Non sono prove che ogni organizzazione abbia già queste funzioni attive; sono un segnale di prodotto sul fatto che la qualità del dialogo va osservata, oltre al risultato finale.

Il messaggio per chi dirige IT e People è semplice: se automatizziamo il lavoro del Service Desk trasferendo la fatica di chiarire il problema al dipendente, non abbiamo necessariamente migliorato il servizio. Abbiamo soltanto cambiato chi paga il costo dell’interazione.

Il costo nascosto di una domanda in più

Un follow-up può essere utile. Chiedere conferma prima di ripristinare un account o modificare un accesso è una protezione, non un difetto. Ma una domanda già risolta nei dati disponibili, oppure ripetuta dopo che il dipendente ha allegato la risposta, segnala un problema di contesto, progettazione o integrazione. Occorre distinguere l’attrito necessario dall’attrito evitabile.

Nel supporto umano il collega esperto ascolta i dettagli e sa quando è meglio chiamare, leggere un log o coinvolgere un altro team. Un agente tende invece a seguire il perimetro dei dati e degli strumenti configurati. Se questo perimetro è stretto, può produrre una conversazione formalmente corretta ma faticosa. Il dipendente intanto cambia finestra, interrompe il proprio lavoro, perde il filo e rischia di rinunciare.

Perciò al volume dei ticket e al tempo medio di chiusura aggiungerei tre misure: follow-up per richiesta risolta, quota di richieste che ripetono informazioni già fornite e tempo attivo richiesto alla persona. Quest’ultimo non coincide con il tempo di attesa del sistema. Una pratica che impiega dieci minuti di calendario ma quattro interventi del dipendente può essere peggiore di una telefonata di sei minuti che chiude il problema.

Dal contenimento alla qualità del passaggio

Quando l’AI non dispone di elementi sufficienti, il trasferimento umano deve essere un atto di servizio, non un reset della conversazione. Il collega dovrebbe ricevere intento, cronologia essenziale, fonti consultate, passaggi già tentati, autorizzazioni verificate e motivo preciso dell’escalation. Il dipendente non dovrebbe essere costretto a raccontare tutto da capo.

Questo richiede regole di passaggio diverse per rischio e contesto. Una password dimenticata può seguire un percorso guidato. Una possibile perdita di dati, un problema di accessibilità o una situazione personale delicata richiede una soglia più bassa per coinvolgere una persona. Nell’HR il contenuto del passaggio deve inoltre rispettare permessi e minimizzazione: avere un riassunto completo non autorizza chiunque a leggerlo.

Il NIST AI Risk Management Framework invita a definire chiaramente ruoli e responsabilità delle persone nella configurazione uomo-AI e nel monitoraggio del sistema. Applicato al Service Desk, significa stabilire chi può fermare un flusso, chi assume la responsabilità del caso e come si documenta un errore. Il passaggio umano non è una sconfitta dell’agente: è una capacità progettata del servizio.

Knowledge base: usare i follow-up come sensori

Molte domande ripetute nascono da istruzioni che non riflettono più il lavoro reale. Una procedura usa il nome vecchio di un’applicazione; un articolo omette il caso del dispositivo personale; una guida chiede uno screenshot che l’utente non sa dove trovare. L’analisi dei follow-up permette di scoprire queste lacune senza aspettare una protesta formale.

La metodologia KCS del Consortium for Service Innovation propone di integrare la creazione e il miglioramento della conoscenza nel flusso di risoluzione. Il principio è particolarmente utile con gli agenti AI: ogni conversazione problematica può produrre una proposta di correzione, ma non deve pubblicare automaticamente una risposta non verificata. Un knowledge owner controlla la soluzione, aggiorna l’articolo e ne verifica il riuso.

Un piccolo ciclo settimanale basta a iniziare: campionare le richieste con due o più follow-up, classificare il motivo — informazione mancante, ricerca inefficace, autorizzazione, domanda superflua — e assegnare un proprietario. Poi misurare se, dopo la correzione, la stessa intenzione richiede meno interruzioni senza aumentare riaperture o errori. È miglioramento continuo misurabile, non una campagna di pulizia documentale una tantum.

Un patto tra IT, HR e responsabili di servizio

Per un dipendente la distinzione tra problema IT, procedura HR e servizio di workplace spesso non esiste. Deve poter chiedere aiuto senza conoscere l’organigramma. Il lavoro dei responsabili è invece definire le frontiere dietro la conversazione: chi possiede la risposta, chi custodisce il dato, chi riceve l’escalation e chi verifica che l’esito sia stato utile.

Il service owner può partire da cinque intenti ad alto volume. Per ciascuno, documenta quali dati sono già disponibili, quali domande sono davvero necessarie, quando serve consenso o approvazione e quale prova chiude il caso. Coinvolge un rappresentante HR per i casi sensibili, Security per i permessi e il team del supporto per i punti in cui le persone si incagliano. Così la progettazione non diventa solo un esercizio di prompt.

Anche il fornitore va misurato sull’esperienza e non solo sull’automazione. Un contratto che premia esclusivamente il containment incentiva conversazioni lunghe pur di evitare il trasferimento. Meglio affiancare al tasso di risoluzione il numero di follow-up evitabili, le riaperture, il trasferimento con contesto e una domanda breve al dipendente: hai dovuto ripetere qualcosa che avevi già detto?

La decisione manageriale dei prossimi trenta giorni

Non serve aspettare una piattaforma perfetta. Prenderei cento richieste recenti gestite dall’AI, separando quelle risolte, trasferite e abbandonate. Per ciascuna conterei i follow-up, il tempo umano richiesto e i dati già presenti all’avvio. Un campione qualitativo con operatori e dipendenti aiuterebbe a capire se le domande erano necessarie. I numeri da soli non spiegano il motivo.

Da questa baseline sceglierei due correzioni: una nel contesto disponibile all’agente e una nella qualità del passaggio umano. Definirei in anticipo una soglia di sicurezza: nessuna riduzione dei follow-up deve aumentare azioni sbagliate o diminuire le verifiche nei casi sensibili. Dopo quattro settimane confronterei non solo la quota automatizzata, ma l’esperienza effettiva di chi chiede aiuto.

Il punto non è impedire all’agente di fare domande. È fare in modo che ogni domanda abbia un motivo, un proprietario e un valore per la persona. Il servizio migliore non è quello in cui l’AI parla di più: è quello in cui il dipendente torna prima al proprio lavoro.

Nota editoriale: questa è un’analisi indipendente. Le funzioni citate dipendono da versione, licenza e configurazione della piattaforma; le pratiche proposte vanno adattate ai processi, ai permessi e ai rischi dell’organizzazione e non garantiscono risultati automatici.