Nel service desk c’è un gesto che sembra piccolo, quasi automatico, ma che racconta molto del modo in cui un’organizzazione interpreta il supporto agli utenti.
È il clic su “Chiudi”.
Arriva dopo una risposta inviata, una procedura suggerita, una verifica eseguita, un intervento completato o una richiesta inoltrata al gruppo competente. La segnalazione esce dalla coda, il backlog si alleggerisce, il sistema registra un avanzamento e l’operatore può passare al ticket successivo.
In una giornata piena di urgenze, solleciti e numeri da rispettare, quella chiusura produce un sollievo immediato.
“Anche questa è andata.”
Il problema è capire se sia vero, oppure se la segnalazione sia stata solo rimandata.
Uno degli errori più frequenti nel service desk è proprio questo: chiudere una segnalazione prima di aver ricevuto un feedback da chi l’ha aperta, o comunque prima di avere un’evidenza credibile che il bisogno dell’utente sia stato davvero soddisfatto.
Nel sistema il ticket risulta chiuso. L’utente, però, potrebbe essere ancora fermo o non del tutto soddisfatto dell’intervento ricevuto. Potrebbe non aver capito la risposta, aver ricevuto un manuale non pertinente o aver ottenuto una soluzione provvisoria, ma non realmente utile. Potrebbe avere ancora lo stesso problema, con una frustrazione in più: dover riaprire, rispiegare, sollecitare e ricostruire da capo qualcosa che pensava fosse stato preso in carico.
La chiusura del ticket non dovrebbe essere il momento in cui il service desk si libera di una segnalazione.
Dovrebbe essere il momento in cui può dichiarare, con sufficiente credibilità, che il bisogno dell’utente è stato compreso, gestito, soddisfatto e verificato.
Quando questa distinzione si perde, chiudere diventa facile. Chiudere bene, invece, diventa raro. E dal punto di vista degli utenti, il service desk perde valore.
Il ticket era chiuso. La segnalazione no.
Ricordo un episodio che spiega bene il problema.
Un utente aprì una segnalazione perché una funzionalità del sistema, a suo dire, non funzionava correttamente. Non sembrava un caso particolarmente complesso. L’operatore prese in carico il ticket, cercò nella documentazione e recuperò un estratto del manuale che sembrava collegato alla richiesta.
Lo inviò come risposta.
Poi chiuse la segnalazione.
Dal punto di vista del sistema, il flusso appariva ordinato: richiesta ricevuta, risposta fornita, ticket chiuso. Nessun blocco evidente. Nessuna attesa sospesa. Nessuna lavorazione rimasta in coda.
Solo che l’utente rispose quasi subito.
Quel riferimento non riguardava il suo caso.
Il ticket venne riaperto. Seguì una nuova risposta, ancora troppo generica, poi una nuova chiusura. Alla terza riapertura, il tono cambiò completamente. L’utente non stava più chiedendo solo supporto tecnico: stava chiedendo di essere ascoltato. Pretese che la segnalazione non venisse più chiusa senza un suo riscontro e inviò anche una lamentela ufficiale.
La parte più interessante arrivò dopo, quando chiesi spiegazioni all’advisor che aveva in carico la segnalazione.
Non stava cercando deliberatamente di liquidare l’utente. Non aveva l’obiettivo di lavorare male, né di ignorare la richiesta. Aveva imparato, dal manager precedente, che il tempo era tutto. Le segnalazioni dovevano essere chiuse il prima possibile, altrimenti qualcuno avrebbe fatto domande sugli SLA, sui tempi medi, sul backlog, sulla produttività.
Quella persona non aveva inventato un comportamento sbagliato.
Lo aveva assorbito.
L’organizzazione gli aveva insegnato che chiudere rapidamente era più importante che verificare davvero. Tanto, se qualcosa non fosse andato bene, l’utente avrebbe potuto riaprire la stessa segnalazione. Di conseguenza, davanti a un ticket apparentemente semplice, aveva fatto ciò che il sistema rendeva conveniente: trovare una risposta plausibile, inviarla, chiudere.
In quel momento, però, il ticket era chiuso solo per il service desk.
Per l’utente, la richiesta era ancora aperta. Anzi, era peggiorata. Al problema iniziale si era aggiunta la sensazione di essere stato liquidato, di dover insistere per essere preso sul serio e di avere davanti un team più interessato a chiudere la pratica che a capire la difficoltà reale.
Questa è la frattura che molte organizzazioni sottovalutano.
La chiusura formale può essere corretta nel workflow, ma sbagliata nell’esperienza dell’utente. Quando succede, lo stato “Chiuso” non racconta un risultato.
Nasconde un problema.
La fretta di chiudere nasce da ciò che misuriamo.
Chiudere una segnalazione troppo presto non è sempre il risultato di superficialità individuale.
A volte lo è. Esistono operatori inesperti, risposte pigre, abitudini sbagliate e casi gestiti con poca cura. Fermarsi a questa lettura, però, è troppo comodo: sposta tutto sulla persona e lascia intatto il sistema che ha reso quel comportamento normale.
Nel service desk, la fretta di chiudere nasce spesso dalla pressione operativa.
Una coda piena pesa. Ogni ticket aperto sembra un arretrato, una pendenza, il segnale di qualcosa che non è ancora stato fatto. Quando le richieste aumentano e gli utenti sollecitano, il bisogno di fare spazio diventa fortissimo. Le segnalazioni più semplici, o quelle che sembrano tali, vengono viste come occasioni per alleggerire il carico: rispondo, chiudo, passo oltre.
In teoria è efficienza.
In pratica, se manca la verifica, può diventare lavoro spostato in avanti.
Gli SLA aggiungono un altro livello di pressione. Nascono per garantire tempi e qualità del servizio, ma quando vengono letti in modo isolato rischiano di produrre l’effetto opposto. Invece di aiutare il team a risolvere bene entro tempi ragionevoli, possono spingere a portare il ticket in uno stato che faccia apparire il lavoro concluso.
Il numero migliora.
La realtà, non sempre.
Se l’organizzazione guarda soprattutto il tempo medio di chiusura, il numero di ticket chiusi o il backlog residuo, le persone tenderanno ad adattarsi a quei segnali. Non necessariamente per malizia. Spesso per sopravvivenza. Se chi chiude tanto viene percepito come efficiente, mentre chi tiene aperto per chiedere un riscontro sembra lento, il messaggio diventa chiaro anche senza essere dichiarato.
Mi è capitato di vedere questa dinamica in modo molto concreto.
In un mio team c’era una risorsa considerata estremamente efficiente. E, in parte, lo era davvero: gestiva e risolveva una quantità di segnalazioni molto superiore a chiunque altro. La classica “macchina da guerra”. Il problema era l’effetto collaterale: rispetto a lei, le altre risorse sembravano lente, quasi pigre, perché non arrivavano nemmeno alla metà delle segnalazioni lavorate.
La reputazione positiva era costruita soprattutto sul volume.
Quando abbiamo iniziato a osservare anche altri aspetti del supporto, il quadro si è ricalibrato. Quella risorsa gestiva molte segnalazioni, ma ne lasciava parecchie in pending o in uno stallo operativo. Altre persone, pur lavorando meno ticket in valore assoluto, accompagnavano meglio l’utente verso la conferma, chiudevano in modo più pulito e lasciavano meno situazioni sospese.
La risorsa più veloce è rimasta una risorsa forte. Ma il team ha iniziato a vedere anche altre forme di valore: continuità, precisione, presidio, qualità della chiusura.
La cultura operativa si forma così: attraverso ciò che viene misurato, premiato, tollerato o ignorato.
Per questo, davanti a una chiusura prematura, la domanda non dovrebbe essere soltanto: “Perché l’advisor ha chiuso?”.
Bisognerebbe chiedersi anche: “Che cosa gli abbiamo insegnato a considerare successo?”.
Se il successo coincide con il numero di ticket chiusi, il team chiuderà. Se coincide con tempi di risposta bassi, il team tenderà a rispondere più in fretta e ad approfondire meno.
Quando invece il successo coincide con il bisogno dell’utente gestito fino a un esito credibile, il modo di lavorare cambia. Le persone fanno più domande, verificano meglio e usano il feedback non come un fastidio, ma come parte del processo. Non perché qualcuno lo ha scritto in una procedura, ma perché l’organizzazione ha chiarito cosa significa davvero dare supporto.
Rispondere non significa risolvere.
Uno degli equivoci più frequenti nasce dal confondere la risposta con la soluzione.
Inviare un link non significa che l’utente abbia trovato ciò che gli serve. Allegare una guida non rende automaticamente pertinente il passaggio indicato. Copiare una sezione del manuale non dimostra che il caso sia stato compreso. Scrivere “provi ora” non garantisce che il servizio funzioni davvero.
Nel caso della segnalazione chiusa dopo l’estratto del manuale, l’operatore aveva effettivamente svolto un’attività. Aveva cercato una risposta, individuato un contenuto, inoltrato il materiale e aggiornato il ticket.
Il punto è che aveva completato un’azione, non risolto un bisogno.
Questa distinzione è fondamentale.
L’attività completata riguarda il lavoro del team: ho risposto, inoltrato, modificato, verificato, inviato. Il bisogno soddisfatto riguarda l’utente: ha capito, riesce a lavorare, ha ottenuto ciò che gli serviva, può proseguire senza tornare subito al punto di partenza.
Le due cose possono coincidere, ma non coincidono automaticamente. E soprattutto non sempre possiamo stabilire da soli se il bisogno sia stato soddisfatto.
Un utente può scrivere: “Non riesco a generare il PDF del documento che vedo a video”. Una risposta rapida potrebbe essere: “Lo genero io e glielo invio”. In una situazione urgente può essere anche una scelta utile. Se l’utente deve consegnare quel documento entro pochi minuti, sbloccarlo subito ha valore.
Ma quella risposta chiude davvero il problema?
Dipende.
Se il bisogno era ottenere quel documento una sola volta, forse sì. Se invece la funzione continua a non generare PDF, l’utente resta dipendente dal service desk ogni volta che deve ripetere l’operazione. Il team ha risolto l’urgenza, ma non ha ripristinato la capacità dell’utente di lavorare in autonomia.
La chiusura del ticket, in quel caso, richiede chiarezza.
Si sta chiudendo il bisogno immediato? Il malfunzionamento è davvero superato? Esiste un percorso per correggere la causa? L’utente sa che cosa è stato fatto e che cosa resta eventualmente aperto?
Senza queste risposte, lo stato “Chiuso” diventa ambiguo. Il service desk pensa di aver risolto. L’utente si aspetta che il problema non torni più. Il sistema registra una chiusura. La realtà, però, rimane più fragile.
Risolvere non significa soltanto dare una risposta.
Significa produrre un esito utile per chi ha chiesto supporto.
E quell’esito, quando riguarda l’esperienza concreta dell’utente, non può essere sempre dichiarato unilateralmente dal team.
Il feedback dell’utente non è un fastidio.
In un service desk reale non è possibile attendere una conferma esplicita per ogni singola segnalazione.
Sarebbe ingenuo e, in alcuni casi, anche controproducente. Ci sono richieste standard che possono essere verificate tecnicamente. Alcuni utenti non rispondono mai, perché hanno risolto, sono passati ad altro o semplicemente non hanno il tempo di scrivere una conferma. In altri casi, aspettare giorni produrrebbe solo una coda gonfiata artificialmente.
Il punto, però, non è trasformare ogni chiusura in un’autorizzazione formale dell’utente.
Il punto è capire quando il feedback dell’utente rappresenta una parte dell’evidenza necessaria.
Succede quando il risultato dipende dal suo contesto operativo, dal suo profilo, dai suoi dati, dalla sua postazione, dal modo in cui usa una funzionalità o dalla comprensione della risposta ricevuta. In questi casi il service desk può controllare log, configurazioni e parametri, ma una parte della verità resta fuori dal suo campo visivo.
Solo l’utente può dire se quella soluzione, nel suo lavoro reale, ha funzionato.
Una collega, una volta, rispose a una richiesta con una guida operativa dettagliata. La risposta era corretta, chiara e pertinente. Avrebbe potuto chiudere subito il ticket. Scelse invece di chiedere un riscontro.
L’utente non rispose.
Dopo qualche giorno, la collega inviò un breve follow-up, senza pressione, chiedendo se la procedura avesse funzionato o se servisse ancora supporto. Il giorno dopo arrivò la conferma: l’utente si scusava per il ritardo e spiegava che tutto era andato bene.
A prima vista non sembra un episodio memorabile. Lo è proprio per la sua normalità.
Quel ticket non era rimasto aperto per inerzia. Era rimasto aperto perché mancava l’ultimo pezzo di evidenza: la conferma che l’utente fosse riuscito davvero ad applicare la soluzione. Dopo quel riscontro, la chiusura aveva un significato diverso. Non era più il modo in cui il service desk decideva di archiviare una richiesta. Era la conclusione condivisa di un piccolo percorso di supporto.
Il feedback, in questo senso, non è una gentilezza accessoria.
È un modo per proteggere la qualità della chiusura.
Cambia anche la relazione. Un utente che percepisce attenzione tende a collaborare di più, a spiegare meglio, a riconoscere il lavoro fatto e a fidarsi del canale ufficiale. Chi si sente liquidato, al contrario, impara presto a riaprire, sollecitare, aggirare il processo o parlare male del supporto.
La fiducia si costruisce spesso in questi dettagli.
Non nella promessa generica di essere disponibili, ma nel fatto concreto di non chiudere la porta prima di sapere se dall’altra parte qualcuno è riuscito davvero a passare.
Il follow-up rende sostenibile l’attesa.
Chiedere feedback non significa lasciare i ticket aperti per sempre.
Questa è una delle obiezioni più comprensibili. In un service desk ci sono volumi, SLA, code da governare, backlog da tenere sotto controllo e operatori che non possono trasformarsi in assistenti personali di ogni singola richiesta.
Proprio per questo serve una regola sostenibile.
Il feedback dell’utente deve essere gestito dentro un processo, non affidato alla memoria o alla buona volontà dell’operatore. Quando viene inviata una soluzione che richiede conferma, il ticket può entrare in uno stato chiaro: in attesa di riscontro, in verifica utente, pending customer, o qualunque formulazione sia coerente con lo strumento utilizzato e con il settore di appartenenza.
Da quel momento, il tempo non deve diventare invisibile.
Serve un follow-up.
Non un sollecito aggressivo, non una pressione sull’utente, ma un messaggio semplice: abbiamo proposto una soluzione, vogliamo sapere se ha funzionato, siamo ancora disponibili se qualcosa non torna.
Il follow-up serve a tenere aperta la relazione senza lasciare sospeso il processo.
Dopo un intervallo ragionevole, se l’utente non risponde, è possibile inviare una comunicazione di chiusura. Anche qui il modo conta molto. C’è una grande differenza tra chiudere in silenzio e scrivere che, non avendo ricevuto ulteriori segnalazioni, il ticket verrà chiuso, restando comunque riapribile se il problema dovesse persistere.
Nel primo caso l’utente può sentirsi abbandonato.
Nel secondo capisce che la chiusura non è una fuga, ma una decisione operativa presa dopo aver lasciato spazio al riscontro.
La tecnologia può aiutare molto. Promemoria automatici, regole di chiusura differita, stati dedicati, notifiche programmate e template chiari permettono di rendere il processo fluido, senza chiedere agli operatori di ricordare manualmente ogni ticket in attesa.
Il punto, infatti, non è appesantire il lavoro.
È evitare che la qualità della chiusura dipenda dal caso o dalla buona volontà dell’advisor.
Anche ITSM.tools, parlando della gestione degli utenti che non rispondono, evidenzia l’importanza di distinguere tra risoluzione e chiusura del ticket, usando stati intermedi e comunicazioni automatiche per permettere all’utente di confermare se il problema è davvero risolto.
Nei team che gestisco, per esempio, abbiamo definito due solleciti: uno a una settimana dall’ultima risposta del team e uno alla seconda settimana. Alla terza settimana, in assenza di riscontro, la segnalazione viene chiusa automaticamente con un messaggio dedicato. Questo processo è tollerato dagli utenti perché, dopo tre settimane di attesa e solleciti, difficilmente qualcuno può sentirsi liquidato.
Un processo maturo non aspetta feedback all’infinito e non chiude subito senza ascoltare. Trova un equilibrio: chiede conferma quando serve, sollecita con criterio, comunica la chiusura in modo trasparente e lascia all’utente una via semplice per tornare se il problema non è davvero risolto.
Questa è la differenza tra attesa passiva e presidio.
L’attesa passiva lascia un ticket fermo.
Il presidio accompagna la richiesta fino a una conclusione credibile.
Chiudere bene richiede una cultura diversa.
Chiudere bene non è solo una tecnica.
È una scelta culturale.
Significa smettere di considerare il ticket come un oggetto da eliminare dalla coda e iniziare a considerarlo come la traccia di un bisogno da governare. La differenza è sottile, ma cambia tutto.
Se il service desk lavora per chiudere ticket, ogni richiesta diventa una pratica da archiviare. La risposta più rapida sembra la migliore. La verifica diventa un ostacolo. Il feedback dell’utente viene percepito come un rallentamento. Il follow-up diventa un fastidio. La riapertura viene vissuta come un fallimento individuale o una seccatura.
Se invece il service desk lavora per chiudere bisogni, il ragionamento cambia. La domanda non è più soltanto “abbiamo risposto?”, ma “l’utente può proseguire?”. Non è “possiamo chiudere?”, ma “abbiamo evidenze sufficienti per dire che questa richiesta è gestita?”. Non è “quanto tempo abbiamo impiegato?”, ma “il tempo speso ha prodotto una soluzione credibile?”.
Questo non significa ignorare gli SLA o disprezzare le metriche operative.
Un service desk senza controllo dei tempi diventa rapidamente ingestibile. I numeri servono, ma devono misurare il servizio, non sostituirlo. Se il tempo di chiusura viene letto insieme alle riaperture, alla qualità delle note, al feedback degli utenti e alla soddisfazione percepita, diventa uno strumento utile. Se viene letto da solo, rischia di premiare la chiusura apparente.
L’organizzazione ha una responsabilità enorme in questo passaggio.
Deve formare le persone a leggere davvero le richieste. Deve proteggere gli operatori quando scelgono di fare una domanda in più invece di chiudere subito. Deve evitare metriche individuali che premiano solo il volume e rendere sostenibile il follow-up. Deve anche insegnare che il feedback non è un vezzo operativo, ma una parte del servizio.
Un operatore può imparare a chiudere meglio. Un team può costruire abitudini più sane.
Ma se tutto intorno continua a premiare la velocità apparente, la cultura tornerà sempre verso il clic più rapido.
Chiudere bene richiede tempo, ma non è una perdita di efficienza.
Un ticket chiuso male torna indietro. Consuma altro tempo, genera irritazione, produce spiegazioni ripetute, alimenta escalation e riduce la fiducia. Un ticket chiuso bene può richiedere qualche ora in più, ma spesso evita giorni di rumore successivo.
La vera efficienza non è chiudere prima.
È fare in modo che l’utente non debba riaprire per le stesse ragioni.
Una chiusura credibile lascia una traccia.
Alla fine, la qualità della chiusura del ticket si vede da una cosa semplice: la traccia che lascia.
Una nota finale generica, come “risolto”, dice pochissimo. Non racconta che cosa è stato capito, quale intervento è stato fatto, come è stato verificato, quale feedback è stato ricevuto o che cosa deve succedere se il problema si ripresenta.
Una chiusura credibile, invece, aiuta tutti.
Aiuta l’utente, perché gli restituisce chiarezza. Aiuta il service desk, perché rende ricostruibile il lavoro. Aiuta il team, perché riduce ambiguità e riaperture inutili. Aiuta l’organizzazione, perché trasforma ogni ticket in conoscenza, non solo in uno stato archiviato.
Non serve scrivere un rapporto tecnico per ogni segnalazione. Serve una comunicazione proporzionata, comprensibile e onesta.
Una buona chiusura può dire, in poche righe, che cosa è stato fatto, quale verifica è stata eseguita, che cosa ha confermato l’utente o quale evidenza tecnica consente di chiudere. Se qualcosa resta aperto, deve essere dichiarato. Se esiste un workaround, non va venduto come soluzione definitiva. Se il problema può ripresentarsi, l’utente deve sapere come comportarsi.
Il punto è non fingere che sia tutto finito quando non lo è.
La chiusura del ticket non deve promettere che il mondo sia perfetto. Deve dichiarare che quella specifica richiesta è stata gestita in modo serio, che il bisogno immediato è stato affrontato e che ciò che eventualmente resta non andrà perso.
Forse la domanda più utile, prima di chiudere, è questa:
“Se questo ticket tornasse domani, riusciremmo a capire perché lo abbiamo chiuso oggi?”
Se la risposta è no, manca ancora qualcosa.
Un riscontro, una verifica, una nota più chiara, un collegamento a un’attività successiva o una spiegazione all’utente.
Se la risposta è sì, la chiusura diventa più solida. Non è più una scorciatoia amministrativa. Diventa una dichiarazione credibile sul servizio.
Chiudere in fretta è facile.
Chiudere bene richiede qualcosa in più: capire, verificare, chiedere feedback quando serve e lasciare una traccia che regga anche dopo il clic finale.
Perché un ticket chiuso senza riscontro non è sempre risolto.
A volte è solo un problema che sta preparando il suo ritorno, spesso in modo molto più impattante di prima.
