Il ticket arriva troppo tardi: progettare un Service Desk preventivo

Il nuovo punto d’ingresso è prima del ticket

Per anni il Service Desk ha iniziato a lavorare quando l’utente apriva un ticket. Quel momento resta necessario, ma non è più l’unico punto d’ingresso. Il 7 agosto 2026 ServiceNow ha documentato una funzione che propone all’utente, prima dell’invio, un suggerimento generato dall’AI utilizzando descrizione della richiesta, articoli di knowledge, catalogo e contesto come hardware, sede e reparto. Microsoft descrive invece le Remediations di Intune come strumenti per rilevare e correggere problemi comuni prima che l’utente li noti.

Sono fatti di prodotto dichiarati dai rispettivi fornitori, non risultati indipendenti sull’efficacia. Il segnale operativo è comunque chiaro: il supporto si sta spostando a monte. Una parte della domanda può essere intercettata durante la formulazione; un’altra può essere evitata agendo sul dispositivo; un’altra ancora può diventare una richiesta già arricchita di contesto. La nuova frontiera non è chiudere più velocemente il ticket, ma decidere quando è corretto non farlo nascere.

Prevenzione, self-service e automazione non sono la stessa cosa

Mettere tutto sotto l’etichetta deflection crea metriche ambigue. Un suggerimento che aiuta l’utente a completare un’azione è self-service assistito. Una correzione applicata a una configurazione anomala è remediation. Un avviso che evita un errore ricorrente è prevenzione. Un modulo che rinuncia a registrare la domanda, invece, può semplicemente rendere invisibile un bisogno. I quattro casi producono volumi simili nel sistema ITSM, ma valore e rischio molto diversi.

Il modello operativo dovrebbe quindi conservare una traccia minima anche quando non nasce un incident. Servono causa rilevata, intervento proposto o eseguito, consenso quando necessario, risultato tecnico e possibilità di riaprire il percorso. Questa telemetria non deve trasformarsi in sorveglianza del dipendente: va limitata a ciò che è necessario per erogare e migliorare il servizio, con retention e accessi definiti. Senza una traccia, il ticket evitato scompare dalle statistiche insieme alla conoscenza utile.

La knowledge diventa una decisione operativa

Nel supporto preventivo la knowledge non è più soltanto una pagina da cercare. Diventa uno degli input che determinano suggerimento, diagnosi o azione. Questo aumenta il valore di ownership, versionamento, scadenza e feedback. Una procedura obsoleta mostrata a un tecnico crea rilavorazione; la stessa procedura proposta automaticamente a migliaia di utenti può amplificare l’errore.

Prima di abilitare un percorso è utile classificare gli articoli per affidabilità e capacità d’azione. Le istruzioni informative possono avere una soglia più leggera. Le procedure che modificano configurazioni, credenziali o privilegi richiedono fonte approvata, prerequisiti verificabili e confini espliciti. La risposta AI dovrebbe poter indicare la base utilizzata e offrire sempre un’uscita semplice verso una persona. L’obiettivo non è costringere al self-service, ma rendere la soluzione più vicina senza sottrarre scelta.

Governance: tre porte prima dell’azione

Propongo tre porte di controllo. La prima è il contesto: il sistema dispone di segnali sufficienti e pertinenti, oppure sta deducendo troppo? La seconda è l’evidenza: knowledge, regola di rilevazione e diagnosi sono attuali e testate? La terza è l’autorità: l’azione è reversibile, autorizzata e proporzionata all’impatto? Solo quando tutte e tre sono soddisfatte ha senso procedere automaticamente; negli altri casi il percorso deve chiedere conferma o scalare.

Il NIST AI Risk Management Framework organizza la gestione del rischio nelle funzioni Govern, Map, Measure e Manage. Il relativo Playbook invita anche a documentare il grado di supervisione umana. Applicato al Service Desk significa definire ownership, casi d’uso e popolazioni interessate; testare falsi positivi e differenze tra gruppi; misurare l’esito; mantenere arresto, rollback e ricorso. Non è burocrazia aggiunta all’automazione: è ciò che rende sostenibile aumentarne l’autonomia.

Le metriche devono dimostrare valore, non assenza di ticket

Il numero di ticket evitati è una stima, non un outcome. Può crescere perché il servizio funziona meglio, ma anche perché il canale è diventato difficile da raggiungere. Una scorecard credibile combina segnali operativi ed esperienza: problemi rilevati prima dell’impatto, remediation riuscite e verificate, ricorrenze entro una finestra definita, falsi positivi, rollback, escalation richieste dall’utente e tempo restituito alle persone.

Sul piano economico bisogna includere licenze, engineering delle regole, manutenzione della knowledge, osservabilità e gestione delle eccezioni. Il confronto corretto non è costo dell’automazione contro costo medio del ticket: è costo totale per un outcome stabile rispetto al percorso precedente. Se una remediation riduce contatti ma genera incidenti secondari o trasferisce lavoro all’utente, il risparmio è soltanto contabile. Un campione periodico di casi e feedback qualitativo aiuta a vedere ciò che il dashboard non racconta.

Anche gli SLA richiedono una lettura diversa. Un evento risolto prima dell’apertura non ha un tempo di risposta tradizionale, ma possiede un tempo tra rilevazione, decisione e verifica. Conviene affiancare agli SLA una metrica di copertura: su quale quota della popolazione e dei casi il controllo è realmente attivo? Senza il denominatore, un alto tasso di successo può riferirsi soltanto ai dispositivi più semplici. Segmentare per servizio, sede, tecnologia e popolazione consente di individuare zone d’ombra e impatti distributivi prima di estendere il modello.

Partire da un problema ricorrente e reversibile

Il primo candidato non dovrebbe essere il processo più costoso, ma quello più osservabile: frequente, con diagnosi affidabile, azione reversibile e outcome verificabile. Configurazioni note, certificati scaduti o policy non aggiornate possono offrire un terreno più controllabile di una diagnosi applicativa aperta. Microsoft pubblica esempi di script di detection e remediation, ma ogni organizzazione deve validarli nel proprio ambiente, licenze e popolazione prima del rilascio.

La mia interpretazione è che il Service Desk preventivo non riduca il ruolo umano: lo sposta dalla lavorazione ripetitiva alla progettazione del servizio e alla gestione delle eccezioni. Il team deve leggere i segnali, curare la knowledge, decidere le soglie, verificare gli outcome e correggere il sistema. Il successo non è un portale senza ticket. È un servizio in cui meno persone incontrano lo stesso problema e, quando l’automazione non è sicura, trovano rapidamente un operatore con tutto il contesto necessario.