Ci sono conversazioni che iniziano già in salita.
L’utente apre la chiamata con un tono duro, invia una e-mail piena di frustrazione o scrive nel ticket una frase che lascia poco spazio all’interpretazione: “È inaccettabile”, “Non funziona mai niente”, “Sono bloccato da giorni”, “Nessuno mi risponde”.
In quei momenti, per chi lavora nel service desk, la parte tecnica del problema non è più l’unica cosa da gestire.
C’è il malfunzionamento, la richiesta da capire, il ticket da classificare, il gruppo da coinvolgere, la risposta da dare. Ma sopra tutto questo c’è una tensione che può cambiare rapidamente la qualità dell’interazione.
Gestire utenti arrabbiati significa proprio questo: mantenere controllo, lucidità e direzione quando la conversazione rischia di trasformarsi in uno scontro.
Un utente arrabbiato mette pressione. Può alzare il tono, semplificare troppo, accusare, generalizzare, pretendere risposte immediate. E l’advisor, dall’altra parte, può sentirsi attaccato anche quando non ha causato il problema.
È qui che si gioca una parte importante della qualità del supporto.
Perché gestire utenti arrabbiati nel service desk non significa “calmare il cliente” con qualche frase gentile. Significa riportare ordine dove l’utente percepisce caos, senza perdere la relazione, il presidio e la capacità di capire cosa stia davvero succedendo.
L’obiettivo non è vincere la discussione.
È il governo della conversazione.
Quando l’utente arriva già oltre il limite.
Un utente raramente arriva arrabbiato per caso.
Può succedere, certo. Esistono persone difficili, stili comunicativi aggressivi, abitudini sbagliate e comportamenti poco rispettosi. Ma nella maggior parte dei casi la rabbia non nasce nel momento in cui l’utente contatta il service desk. Nasce prima.
Arriva dopo un servizio che non funziona, una risposta che tarda, una comunicazione poco chiara, una promessa non mantenuta, un’attività urgente rimasta sospesa, un problema che si ripete o semplicemente una sensazione di non essere stati presi sul serio.
Quando l’utente entra in contatto con il service desk, spesso non porta solo il problema tecnico. Porta anche tutto ciò che è successo prima.
Per questo la prima reazione dell’advisor è decisiva.
Se risponde in modo difensivo, la conversazione rischia di irrigidirsi. Se minimizza, l’utente si sente ancora più ignorato. Se prova subito a spiegare, senza prima ascoltare, può dare l’impressione di voler chiudere la questione troppo in fretta.
Chi lavora nel supporto ha bisogno di informazioni precise: cosa non funziona, da quando, con quale errore, su quale utenza, in quale ambiente. Senza questi elementi, il ticket resta confuso. Ma quando l’utente è già oltre il limite, partire solo dalle domande tecniche può non bastare.
Prima va abbassata la temperatura della conversazione. Non con formule vuote, ma riconoscendo che per quella persona la situazione ha generato un disagio reale.
Dire “capisco che la situazione sia frustrante” non risolve il problema.
Però cambia il terreno della conversazione.
Comunica all’utente che non sta parlando con un muro, che qualcuno ha percepito il suo stato e che non dovrà combattere per essere ascoltato. Da quel momento diventa più semplice ricostruire i fatti, chiedere dettagli e riportare la conversazione dentro un percorso gestibile.
Ricordo una situazione che mi ha insegnato molto su questo punto.
Un giorno ricevetti una telefonata molto accesa da parte di un responsabile IT di una sede cliente. Era furioso. Il sistema di gestione documentale, da cui dipendeva un processo critico, era offline da oltre un’ora. Nessuno lo aveva informato, i tecnici locali non riuscivano a capire cosa stesse succedendo e lui, con una conferenza in partenza, si ritrovava esposto davanti alla propria dirigenza.
Il tono era aggressivo. I contenuti, duri.
In quel momento avrei potuto irrigidirmi. Avrei potuto difendere il team, spiegare che non avevo ancora tutti gli elementi, precisare che non ero stato io a causare il problema o provare a rimettere ordine con autorità.
Sarebbe stato il modo più rapido per perdere definitivamente la conversazione.
Scelsi di fare il contrario. Lo lasciai parlare, senza interromperlo. Gli diedi il tempo di scaricare la prima parte della tensione. Quando si fermò, risposi con calma. Mi scusai per il disagio, gli dissi che capivo il suo nervosismo e che da quel momento avrebbe avuto tutta la mia attenzione.
Gli spiegai che avrei aperto subito un’escalation interna e che lo avrei aggiornato entro dieci minuti, anche solo per dirgli come stavamo affrontando il problema.
Dopo circa mezz’ora riuscimmo a ripristinare la piena operatività del servizio.
Poco dopo ricevetti una sua e-mail. Era breve, molto diversa dal tono iniziale. Mi ringraziava per la tempestività. Al termine della conferenza, mi scrisse una seconda volta: “Grazie per la gestione. Mi scuso per il tono iniziale.”
Nessuno glielo aveva chiesto.
Lo fece perché, durante quella gestione, aveva percepito di parlare con qualcuno che non si era fatto trascinare dalla tensione. Qualcuno che aveva ascoltato, agito, dato un presidio e mantenuto un impegno.
Nei momenti difficili, la fiducia non nasce dall’autorità.
Nasce dalla lucidità.
La rabbia dell’utente non è sempre contro di te.
Proprio perché il tono può essere duro, uno degli errori più comuni, quando si devono gestire utenti arrabbiati, è prendere la conversazione sul personale.
È umano.
Un advisor riceve una frase ingiusta, una critica generica sul servizio o sull’azienda, e sente crescere dentro di sé una reazione difensiva. Vorrebbe spiegare che non è colpa sua, che il ticket è appena arrivato, che il gruppo tecnico non ha ancora risposto, che lui sta solo provando ad aiutare.
Tutto vero.
Ma non sempre utile.
Nel service desk bisogna imparare a distinguere la responsabilità personale dalla responsabilità di ruolo. L’advisor può non aver causato il problema, ma in quel momento rappresenta il punto di contatto tra l’utente e l’organizzazione. Per l’utente, spesso, quella distinzione non è immediata.
Chi chiama non vede i gruppi tecnici, i vincoli interni, le code di lavoro, le dipendenze applicative, le priorità concorrenti o le escalation già aperte. Vede un servizio che non sta funzionando come si aspettava e una persona che, in quel momento, rappresenta il fornitore che dovrebbe aiutarlo.
Questo non significa accettare qualunque comportamento.
C’è una differenza netta tra comprendere la frustrazione e subire aggressività. Un utente può essere arrabbiato, diretto, deluso, anche duro. Ma non dovrebbe insultare, minacciare o umiliare chi sta cercando di aiutarlo.
La professionalità dell’advisor sta nel tenere insieme due aspetti: non reagire in modo personale alla frustrazione dell’utente, ma nemmeno rinunciare a proteggere il perimetro della conversazione.
Una frase come “capisco il disagio e voglio aiutarla a risolvere, però ho bisogno che restiamo sui dettagli del problema” può essere molto più efficace di una risposta difensiva. Riconosce la tensione, ma rimette la conversazione su binari utilizzabili.
La rabbia, letta nel modo giusto, è un segnale.
Dice che qualcosa ha prodotto attrito. Forse il servizio ha avuto un malfunzionamento reale o la comunicazione precedente è stata debole. Forse l’utente ha aspettative non allineate, il processo è troppo lento, o semplicemente non è chiaro cosa stia succedendo.
Se l’advisor riesce a non trasformare quel segnale in un attacco personale, può iniziare a fare il proprio lavoro: capire cosa c’è sotto.
Ascoltare non significa subire.
L’ascolto attivo è una delle competenze più citate nella gestione degli utenti difficili.
Il problema è che spesso viene raccontato male.
Ascoltare non significa lasciare che l’utente parli all’infinito, assorbire ogni sfogo o rimanere immobili davanti a una conversazione che si deteriora. Non significa nemmeno limitarsi a dire “capisco” ogni trenta secondi, sperando che la tensione si abbassi da sola.
Nel service desk, ascoltare significa raccogliere informazioni, riconoscere il disagio e guidare gradualmente la conversazione verso un punto utile.
All’inizio può essere necessario lasciare spazio all’utente. Una persona molto frustrata spesso ha bisogno di raccontare tutto: cosa è successo, da quanto tempo, chi ha già contattato, quali effetti sta subendo, perché ritiene la situazione grave.
Interromperla troppo presto può peggiorare la percezione di non essere ascoltata.
Dopo questa prima fase, però, l’advisor deve riprendere il governo della conversazione. Non con rigidità, ma con metodo.
Può riformulare ciò che ha capito: “Quindi, se ho ricostruito correttamente, il problema si presenta da ieri, riguarda l’accesso alla funzione e le impedisce di completare l’attività entro oggi. È corretto?”.
Questa semplice riformulazione ha tre effetti: fa sentire l’utente ascoltato, verifica che le informazioni siano corrette e trasforma uno sfogo in una descrizione operativa.
Da lì si possono fare domande precise.
Non domande casuali, non un interrogatorio, ma richieste utili a circoscrivere il problema: quando si verifica, su quale schermata, con quale messaggio, su quale profilo, se succede anche ad altri utenti dello stesso ufficio, se esiste un’urgenza specifica da gestire subito.
Ascoltare, quindi, non è passività.
È conduzione.
L’advisor deve far uscire dalla rabbia gli elementi che servono per intervenire. Deve separare il fatto dall’interpretazione, l’impatto reale dalla generalizzazione, l’urgenza immediata dal problema strutturale.
Quando questo passaggio riesce, l’utente smette progressivamente di combattere contro il service desk e inizia a collaborare con chi può aiutarlo.
Non sempre accade subito.
Ma è lì che si costruisce la possibilità di risolvere.
Restare calmi è una competenza operativa.
Mantenere la calma non è una qualità caratteriale riservata alle persone particolarmente pazienti.
Nel service desk è una competenza operativa.
Un advisor che perde lucidità davanti a un utente arrabbiato rischia di peggiorare il ticket, la relazione e la qualità delle informazioni raccolte. Può rispondere troppo in fretta, usare un tono rigido, promettere cose non verificabili, scaricare responsabilità su altri gruppi o chiudersi in una posizione difensiva.
A quel punto il problema tecnico resta, ma sopra si aggiunge un problema relazionale.
Restare calmi, però, non significa essere freddi.
L’utente non ha bisogno di parlare con una voce piatta, distante, impersonale. Ha bisogno di percepire una presenza solida. Qualcuno che non si faccia trascinare dalla tensione, ma nemmeno sembri indifferente.
Il tono conta molto.
Una voce più lenta, frasi più brevi, parole semplici e una struttura chiara aiutano a ridurre il disordine della conversazione. Anche nella comunicazione scritta vale lo stesso principio: quando l’utente è agitato, rispondere con testi lunghi, burocratici, in modo molto tecnico o pieni di giustificazioni può aumentare la frustrazione.
Meglio una risposta ordinata: cosa abbiamo capito, cosa facciamo ora, quali tempi possiamo indicare, quando daremo il prossimo aggiornamento.
La calma dell’advisor diventa una forma di contenimento. Non elimina il problema, ma impedisce alla conversazione di deteriorarsi e spesso evita escalation.
Naturalmente ci sono situazioni in cui la calma individuale non basta. Se l’utente diventa offensivo, se la conversazione si ripete senza avanzare, se il caso ha forte esposizione o se esiste un rischio reputazionale, non ha senso lasciare l’advisor da solo a reggere la pressione.
In quei momenti serve un team leader o un manager.
Coinvolgerlo non è una sconfitta. È un modo per proteggere l’utente, l’advisor e il servizio. Un buon team leader può dare autorevolezza alla gestione, ridefinire le aspettative, ricostruire il percorso, chiarire i limiti e decidere se serva un’escalation più ampia.
Gestire utenti arrabbiati richiede anche questo: capire quando la conversazione non è più solo tecnica. E quando diventa relazionale, organizzativa o reputazionale, il presidio deve cambiare livello.
Chiedere scusa non significa scaricare colpe.
Una delle frasi più difficili da usare bene nel service desk è “mi dispiace”.
Molti advisor la evitano, perché temono di ammettere una colpa non loro. Altri la usano in modo automatico, quasi come un riflesso, svuotandola di significato. In entrambi i casi, si perde un’occasione.
Chiedere scusa non significa necessariamente dichiararsi responsabili del problema tecnico.
Significa riconoscere il disagio dell’utente.
C’è una differenza importante tra dire “è colpa nostra” e dire “mi dispiace per il disagio che questa situazione le sta causando”. La prima frase attribuisce una responsabilità. La seconda riconosce un impatto.
Ho capito quanto questa distinzione sia delicata vivendo una situazione come cliente.
Una mia amica aveva accettato un’offerta di una nota azienda IT: due servizi al prezzo di uno. Sembrava un’occasione conveniente, fino a quando arrivò la prima fattura con un importo molto più alto del previsto.
Mi chiese di darle una mano. Chiamai il servizio clienti, anche con una certa curiosità professionale: volevo capire come un’altra realtà avrebbe gestito quel reclamo.
Dopo aver spiegato la situazione, l’operatore fece le verifiche e confermò rapidamente che i servizi attivati non erano compatibili con la promozione. Fin qui, nulla di sorprendente.
Il problema arrivò subito dopo.
Quando manifestai la mia delusione per l’approccio commerciale dell’azienda, l’operatore, forse nel tentativo di creare complicità, disse una frase molto pericolosa: “Ha ragione, ma spesso dall’area commerciale promettono cose che poi non sono vere, solo per acquisire clienti.”
In quel momento mi si gelò il sangue.
Non stavo più ascoltando solo come cliente deluso. Stavo ascoltando come professionista che si immaginava nei panni del manager di quell’operatore. Una frase pensata forse per mostrarsi empatico aveva appena colpito la credibilità dell’intera azienda.
Il punto non era nemmeno stabilire se quella frase fosse vera o falsa. Il punto era che non avrebbe dovuto essere detta in quel modo, a un cliente, dentro una conversazione di supporto.
Scaricare la responsabilità su un altro reparto può sembrare una scorciatoia efficace. Fa sentire l’utente compreso, crea un’alleanza immediata, abbassa momentaneamente la pressione. Ma il prezzo è altissimo: l’azienda appare disallineata, il servizio perde autorevolezza e l’utente smette di vedere un’organizzazione che risponde in modo unitario.
Chiedere scusa per un disagio è professionale.
Cercare empatia demolendo un altro pezzo dell’organizzazione è pericoloso.
Nel service desk questa distinzione è fondamentale. Un advisor può non sapere ancora se il problema dipende da un bug, da una configurazione, da un errore utente, da un fornitore, da un disservizio esterno o da una procedura non chiara. Promettere spiegazioni e soluzioni prima delle verifiche sarebbe rischioso.
Allo stesso tempo, ignorare il disagio dell’utente solo perché la causa non è ancora nota rende la comunicazione più fredda e meno efficace.
Per questo delle scuse sincere e professionali dovrebbero tenere insieme empatia, direzione e senso di responsabilità organizzativa.
“Mi dispiace per il disagio. Ora ricostruiamo insieme cosa sta succedendo e le indico i prossimi passi.”
In questa frase c’è riconoscimento, ma anche governo. Non ci si ferma alla parte emotiva. La si attraversa per riportare la conversazione verso il lavoro da fare.
Lo stesso vale quando il service desk non può fornire una soluzione immediata. In quei casi, l’onestà è più utile della rassicurazione generica. Dire “stiamo verificando” non basta, se l’utente non capisce cosa accadrà dopo. Meglio spiegare quale gruppo è stato coinvolto, quale informazione manca, entro quando è previsto un aggiornamento e, se possibile aggirare il problema, cosa può fare l’utente nel frattempo.
Le scuse aprono una porta, ma da sole non bastano. Chiarezza e trasparenza la tengono aperta.
Le critiche vanno trasformate in segnali.
Una critica fa rumore.
Soprattutto quando arriva in modo duro, magari dopo giorni di tensione o su un canale visibile. Il primo impulso può essere difendersi, giustificare il processo, spiegare che l’utente non ha considerato tutti i vincoli o ricordare che il service desk ha rispettato quanto previsto.
A volte è vero.
Ma una critica, anche quando è espressa male, può contenere un’informazione preziosa.
Il punto non è prendere ogni lamentela come verità assoluta. Sarebbe ingenuo. Gli utenti possono essere imprecisi, emotivi, parziali, condizionati dall’urgenza del momento. Però possono vedere cose che internamente non vediamo più.
Possono dirci che una comunicazione è incomprensibile, che un processo è troppo lento, che un passaggio è poco chiaro, che gli aggiornamenti non arrivano, che il ticket sembra fermo, che ogni volta devono rispiegare tutto da capo.
Questi segnali non vanno liquidati come semplice rumore.
Vanno letti.
Trasformare una critica in feedback significa fare un passaggio di maturità. Non fermarsi alla forma, ma cercare il contenuto utile. Se un utente dice “non rispondete mai”, probabilmente non sta producendo una statistica accurata. Sta dicendo che, dal suo punto di vista, il tempo di attesa o la qualità degli aggiornamenti non sono sostenibili.
La domanda da porsi non è solo: “Ha ragione?”
È anche: “Che cosa ci sta mostrando?”
Da qui può nascere un miglioramento vero. Magari serve una regola di aggiornamento più chiara, una knowledge base migliore, una comunicazione meno tecnica, una gestione diversa delle escalation o una classificazione più precisa delle urgenze.
La critica diventa utile quando smette di essere trattata come un fastidio e inizia a essere collegata a un comportamento, a un processo o a un punto cieco del servizio.
Non tutte le critiche porteranno a un cambiamento.
Ma ignorarle tutte significa rinunciare a una fonte importante di apprendimento.
Un service desk maturo non spegne solo incendi.
Gestire utenti arrabbiati non significa diventare bravi a sopportare tensione.
Significa costruire un modo più maturo di governare il supporto.
Un service desk maturo non tratta la rabbia dell’utente come un disturbo da silenziare, né la critica come un attacco da respingere. La legge come un segnale, la porta dentro un processo e prova a capire quale parte del servizio sta generando attrito.
A volte il problema è tecnico. Una funzione non va, un accesso è bloccato, un sistema risponde male.
Altre volte il problema è comunicativo. L’utente non sa cosa sta succedendo, non riceve aggiornamenti, non capisce i tempi, non distingue tra workaround e soluzione definitiva.
In altri casi il problema è organizzativo. Il ticket rimbalza tra gruppi, nessuno presidia davvero la richiesta, le priorità non sono chiare o il processo costringe l’utente a ripetere più volte le stesse informazioni.
La rabbia arriva in superficie, ma sotto, spesso, c’è molto altro.
Per questo l’advisor non deve vincere la discussione. Deve recuperare controllo. Deve ascoltare senza subire, restare calmo senza diventare freddo, chiedere scusa senza attribuirsi colpe improprie, coinvolgere il team leader quando serve e trasformare le critiche in informazioni utili.
Deve anche chiudere bene la gestione.
Nei casi difficili, infatti, la risoluzione tecnica non sempre basta. Se la relazione è stata danneggiata, resta qualcosa di sospeso. Un follow-up semplice, concreto e non autocelebrativo può ricostruire fiducia: confermare cosa è stato fatto, verificare se il problema è davvero superato e lasciare un canale chiaro nel caso in cui la situazione si ripresenti.
Non serve trasformare ogni ticket in una relazione lunga e complessa. Un service desk deve restare sostenibile. Ma quando la conversazione nasce con rabbia o frustrazione, il follow-up può fare la differenza tra un utente che resta irritato e uno che, pur avendo vissuto un problema, riconosce la serietà della gestione.
È un equilibrio difficile.
Ma è anche uno dei punti in cui il service desk mostra il proprio valore reale.
Perché il supporto non si misura solo quando tutto procede bene, l’utente è collaborativo e il problema è semplice. Si misura soprattutto quando la situazione è confusa, il tono sale e qualcuno deve riportare ordine.
Gestire utenti arrabbiati significa proteggere tre cose insieme: la relazione con l’utente, la lucidità dell’advisor e la qualità del servizio.
Non è gentilezza di facciata.
È governo operativo della conversazione.
E in molti casi è proprio lì, nel momento in cui la tensione potrebbe prendere il controllo, che il service desk può dimostrare di essere molto più di un canale di smistamento.
