Il Service Desk chiude il cerchio: dal ticket alla remediation verificata

Il segnale: il supporto entra nel ciclo di esecuzione

Per anni l’automazione del Service Desk ha lavorato soprattutto attorno al ticket: apertura guidata, classificazione, routing, suggerimenti all’operatore e ricerca nella knowledge base. Le release note di Now Assist for ITSM pubblicate da ServiceNow per luglio 2026 indicano un passaggio ulteriore. Tra le nuove funzioni compaiono la deflection direttamente nel form di apertura — con classificazione dell’intento, arricchimento del contesto, recupero della conoscenza e proposta di risoluzione prima dell’invio — e l’avvio di remediation sui dispositivi Intune e Jamf da workflow Incident, Task e Change.

Questo è un fatto di prodotto, non la prova che ogni organizzazione debba adottare quella piattaforma o che il risultato sia automaticamente migliore. Il segnale di mercato, però, è rilevante: conversazione, ITSM e gestione degli endpoint stanno convergendo in un unico circuito. Il Service Desk non si limita più a registrare e coordinare il lavoro; può diventare il punto da cui un problema viene compreso, trattato e verificato senza continui cambi di console.

Closed loop significa verificare, non soltanto eseguire

Una vera closed-loop remediation contiene almeno cinque passaggi: riconoscere l’intento, raccogliere evidenze, selezionare un’azione autorizzata, eseguirla e controllare che l’outcome sia stato raggiunto. Se manca l’ultimo passaggio, abbiamo soltanto automazione. Il sistema può aver lanciato uno script con successo tecnico, mentre il servizio dell’utente continua a non funzionare.

La documentazione Microsoft aggiornata il 16 aprile 2026 descrive le Remediations di Intune come pacchetti composti da uno script di rilevazione, uno di correzione e metadati, con report sulla loro efficacia. La pagina dedicata all’azione Run remediation chiarisce inoltre che il controllo può rilevare condizioni come configuration drift, impostazioni mancanti o gap di conformità e applicare una correzione senza interazione dell’utente. Sono capacità tecniche; trasformarle in un servizio richiede di collegare l’esito del rilevamento al ticket, all’asset, alla configurazione interessata e alla comunicazione con la persona.

La mia interpretazione manageriale è questa: la nuova unità di misura non dovrebbe essere l’azione lanciata, ma l’outcome confermato. Un riavvio inviato, una policy riallineata o una cache pulita non equivalgono ancora a una risoluzione. Servono evidenze successive, assenza di ricorrenza in una finestra coerente e, per alcuni casi, conferma dell’utente.

Il modello operativo cambia più della tecnologia

Quando il Service Desk può attivare azioni tecniche, cambiano ruoli e responsabilità. Il team di supporto diventa consumatore di automazioni prodotte e mantenute insieme a endpoint management, security, engineering e service owner. Occorre un catalogo di remediation con proprietario, versione, prerequisiti, ambito, livello di rischio, criterio di successo e rollback. Le azioni non dovrebbero vivere come script anonimi tramandati tra operatori.

Il processo di approvazione deve essere proporzionato. Una raccolta di log o una nuova sincronizzazione possono essere eseguite automaticamente; la rimozione di software, la modifica di controlli di sicurezza o un’azione con impatto sui dati richiedono soglie più alte, consenso o approvazione. Anche il contesto conta: la stessa remediation accettabile su un notebook standard può essere inadeguata su una postazione privilegiata, un dispositivo executive o un endpoint coinvolto in un incidente di sicurezza.

Si modifica anche il sourcing. Nei contratti non basta acquistare “AI resolution” come etichetta. Vanno chiariti responsabilità sugli errori, gestione delle versioni, segregazione dei compiti, accesso ai log, dipendenze da modelli e connettori, portabilità delle procedure e modalità di sospensione. L’efficienza promessa deve essere confrontata con il costo di integrazione, osservabilità e controllo.

Governance dell’autonomia: identità, limiti e reversibilità

Un agente che suggerisce un articolo e un agente che esegue una remediation non hanno lo stesso profilo di rischio. Il secondo utilizza identità, privilegi e integrazioni capaci di cambiare lo stato di un sistema. Il NIST AI Risk Management Framework propone le funzioni Govern, Map, Measure e Manage come struttura volontaria per integrare l’affidabilità nel ciclo di vita dell’AI; il profilo per la Generative AI, pubblicato il 26 luglio 2024, estende l’attenzione ai rischi specifici dei sistemi generativi.

Applicato al Service Desk, questo significa mappare casi d’uso e impatti prima di aumentare l’autonomia, usare identità dedicate con privilegi minimi, registrare decisioni e strumenti invocati, definire soglie di confidenza e mantenere un arresto operativo. La reversibilità non è un dettaglio tecnico: è la possibilità organizzativa di riportare il servizio a una modalità sicura quando cambiano modello, integrazione o contesto.

È utile distinguere quattro classi: informazione; diagnosi senza modifica; remediation reversibile e a basso rischio; azione sensibile o difficilmente reversibile. L’autonomia può crescere per classe, non per entusiasmo. Ogni passaggio dovrebbe essere sostenuto da evidenze su accuratezza, failure mode e capacità di recupero.

Metriche e costi: evitare l’efficienza apparente

La metrica più immediata sarà la percentuale di ticket evitati o risolti automaticamente, ma da sola può premiare comportamenti sbagliati. Un form che scoraggia l’apertura riduce il volume senza ridurre il problema; una remediation che funziona solo temporaneamente sposta il costo nel futuro. Il cruscotto dovrebbe quindi collegare automazione e qualità.

Servono almeno: tasso di outcome verificato; ricorrenza sullo stesso sintomo; errori e rollback; escalation dopo automazione; tempo effettivamente restituito all’utente; copertura dei dispositivi; costo per remediation riuscita; percentuale di azioni bloccate dai guardrail. Sul fronte dell’esperienza va misurato se la persona comprende cosa è stato fatto, mantiene un percorso umano accessibile e non deve ripetere il contesto.

Anche il lavoro degli operatori cambia. Eliminare i casi semplici concentra sul team situazioni più ambigue e ad alto impatto. Il tempo medio può aumentare mentre il valore prodotto migliora. Workforce planning, formazione e KPI individuali devono riconoscere complessità, capacità diagnostica e contributo al miglioramento delle automazioni, non soltanto velocità di chiusura.

• Separare successo tecnico dell’azione e outcome percepito dall’utente.
• Misurare ricorrenze e rollback insieme alla deflection.
• Attribuire costi a integrazione, controllo e manutenzione, non solo alle licenze.
• Ricalibrare produttività e staffing sulla complessità residua.

Una roadmap prudente per chiudere davvero il cerchio

Il punto di partenza non è l’agente più autonomo, ma un problema frequente, diagnosticabile e reversibile. Si costruisce una baseline, si rende affidabile la detection, si definiscono criteri di successo, timeout e rollback, poi si prova inizialmente con approvazione umana. Solo quando le evidenze sono stabili si riduce la supervisione.

La closed-loop remediation non elimina il Service Desk. Ne sposta il baricentro: meno trascrizione e passaggi manuali, più disegno del servizio, controllo, conoscenza e prevenzione. La tecnologia di luglio 2026 rende questo modello più concreto; la differenza competitiva dipenderà dalla disciplina con cui le organizzazioni sapranno governarlo. Chiudere un ticket è un atto amministrativo. Chiudere il cerchio significa dimostrare che il lavoro può ripartire, in sicurezza.