Ci sono momenti in cui guidare un team significa fare un passo indietro.
Lasciare spazio alle persone. Fidarsi delle loro competenze. Permettere che gestiscano, decidano, sbaglino e crescano. Non intervenire sempre, non sostituirsi a loro, non trasformare ogni difficoltà in una supervisione continua.
Poi ci sono altri momenti.
Momenti in cui il responsabile deve fare l’opposto: uscire dalla distanza, esporsi in prima persona e metterci la faccia.
Non per protagonismo.
Non per dimostrare autorità.
Non per salvare l’immagine.
Ma perché una relazione si è incrinata, il cliente ha perso fiducia, il processo non ha funzionato e qualcuno deve assumersi la responsabilità di ricostruire un ponte.
Quello che racconto in questo articolo nasce proprio da una situazione di questo tipo. Un episodio in cui mi sono esposto personalmente con un cliente, dopo una gestione non ottimale da parte del servizio di assistenza, e in cui ho capito ancora una volta quanto la componente relazionale sia decisiva nella percezione del valore di un servizio.
Perché a volte il problema tecnico è solo una parte della storia.
La parte più delicata è tutto ciò che succede intorno: l’attesa, il silenzio, la preoccupazione, la sensazione di non essere ascoltati, il timore che nessuno stia davvero prendendo in carico la situazione.
Ed è lì che il ruolo di chi guida un servizio cambia natura.
Non basta più coordinare.
Non basta più controllare.
Non basta più chiedere aggiornamenti.
Bisogna esserci.
Quando il processo non basta più.
La storia iniziò con una segnalazione apparentemente ordinaria.
Un cliente, da un momento all’altro, non riusciva più a utilizzare una parte del servizio e aprì una richiesta al service desk per chiedere supporto.
All’inizio, la segnalazione non attirò particolare attenzione. Fu interpretata come un possibile errore dell’utente e, in un contesto in cui arrivavano molte altre richieste considerate più urgenti o più bloccanti, finì in coda.
Questo è già un primo punto delicato.
In un service desk reale, ogni giorno arrivano segnalazioni diverse per gravità, impatto, urgenza e complessità. Alcune sono chiaramente bloccanti. Altre sembrano meno rilevanti. Altre ancora appaiono, a una prima lettura, come richieste generate da un uso non corretto del servizio.
Il problema è che una valutazione iniziale sbagliata può condizionare tutto il percorso successivo.
In questo caso, dopo quasi un mese, arrivò finalmente il turno della segnalazione. E a quel punto emerse che il cliente aveva ragione: il servizio aveva effettivamente un problema.
L’advisor intervenne, identificò l’anomalia, applicò una procedura standard per risolverla e chiese al cliente un feedback, come previsto dal processo.
Sembrava la chiusura della vicenda.
Invece era solo l’inizio del problema vero.
Il cliente, invece di confermare la risoluzione, segnalò qualcosa di molto più grave: non vedeva più oltre un mese di lavoro.
A quel punto la segnalazione venne nuovamente sottovalutata. Tornò in coda, superata da altre richieste considerate più urgenti o più bloccanti. Dopo un paio di settimane, il cliente iniziò a inviare solleciti. Poi arrivò una lamentela ufficiale tramite PEC.
Fu quella PEC ad attirare definitivamente la mia attenzione.
Non era solo una comunicazione formale. Era il segnale che il cliente era arrivato a un punto di rottura. Quando una lamentela assume quella forma, significa che la relazione è già uscita dal perimetro ordinario della gestione del ticket. Non stai più affrontando solo una segnalazione aperta. Stai affrontando una perdita di fiducia.
E la situazione era chiara.
Avevamo fatto un errore di valutazione? Sì.
Avevamo sforato ogni tempistica ragionevole di intervento? Sì.
Il cliente aveva realmente perso la visibilità sull’ultimo mese e mezzo di lavoro? Purtroppo sì.
A quel punto il problema non era più soltanto tecnico.
Il problema era diventato relazionale.
Quando la pressione rischia di schiacciare il team.
La PEC fu il segnale esterno.
Ma la scelta di metterci la faccia non nacque solo da quella comunicazione. Nacque anche dalla tensione che si stava creando all’interno dell’organizzazione, soprattutto verso il team del service desk.
Stavamo attraversando un periodo estremamente difficile. Il carico di lavoro era alto, le urgenze erano molte e contemporanee, e il sottodimensionamento del team rendeva tutto più fragile. Ogni ritardo, ogni mancata risposta, ogni ticket rimasto fermo troppo a lungo veniva letto non come il sintomo di una struttura sotto pressione, ma come la prova che il service desk non stesse funzionando.
Internamente stavamo diventando, agli occhi di alcuni, il team che creava problemi invece di risolverli.
Il team che trasformava situazioni gestibili in escalation, che non rispondeva abbastanza in fretta, che lasciava crescere la tensione.
Il team che diventava il punto debole del servizio.
E questa percezione era pericolosa.
Perché quando un team è sotto pressione, le critiche distruttive non aiutano a migliorare. Al contrario, consumano energia, aumentano la difensiva e rischiano di trasformare ogni problema in una caccia al responsabile.
Metterci la faccia significava anche questo: impedire che tutta la tensione si scaricasse sulle persone operative.
Non per negare gli errori.
Gli errori c’erano stati.
Ma perché c’è una grande differenza tra riconoscere un problema e trasformare il team nel capro espiatorio di un sistema che non stava reggendo abbastanza.
Quando guidi un servizio, devi proteggere le persone senza proteggerle dalla responsabilità.
Devi saper dire: abbiamo sbagliato.
Ma devi anche saper dire: non useremo questo errore per distruggere chi stava lavorando in condizioni difficili.
È una linea sottile.
E spesso è proprio lì che si misura la maturità di chi guida.
Prima di reagire, bisogna capire.
Quando una situazione arriva al livello manageriale, la tentazione può essere quella di reagire subito.
Chiamare il cliente. Chiedere spiegazioni al team. Cercare un colpevole. Pretendere una soluzione immediata. Scrivere una risposta formale. Proteggere l’immagine del servizio.
Ma in quel momento la prima cosa da fare non era parlare.
Era capire.
Prima di espormi con il cliente, dovevo ricostruire con precisione cosa fosse accaduto. Mi confrontai quindi con l’advisor che aveva gestito la segnalazione e cercai di capire quale intervento avesse effettuato, perché lo avesse fatto e su quali elementi si fosse basato.
Questo passaggio era fondamentale.
Non volevo arrivare dal cliente con una risposta vaga. Ma non volevo nemmeno scaricare automaticamente la responsabilità su chi aveva gestito operativamente la richiesta.
C’è una grande differenza tra analizzare un errore e cercare un colpevole.
Nel primo caso vuoi capire come il sistema ha fallito.
Nel secondo vuoi solo trovare qualcuno su cui spostare la pressione.
Parlando con l’advisor, emerse che aveva seguito una procedura standard per la gestione di un errore abbastanza semplice. Questo mi permise di escludere, almeno in prima battuta, che avesse creato danni irreparabili con un intervento improvvisato o fuori controllo.
Il problema, quindi, non poteva essere ridotto alla singola persona.
C’era stato un errore più ampio: di valutazione, di priorità, di gestione della relazione, di presidio della comunicazione.
Ed era lì che dovevo intervenire.
A quel punto avevo davanti due strade.
La prima era gestire la situazione sul piano strettamente operativo: verificare il problema, far intervenire il team tecnico, produrre una risposta, aggiornare la segnalazione e chiudere il caso.
La seconda era gestire prima di tutto la frattura relazionale che si era creata.
Scelsi la seconda.
Non perché la parte tecnica fosse meno importante. Anzi, senza una soluzione concreta qualsiasi parola sarebbe stata inutile. Ma perché in quel momento il cliente non aveva bisogno solo di una correzione. Aveva bisogno di percepire che qualcuno aveva capito la gravità della situazione e se ne stava assumendo la responsabilità.
Assumersi la responsabilità non significa giustificarsi.
Il cliente non era tra i più rilevanti per dimensione o peso economico.
Eppure, per me, questo non cambiava la natura del problema.
So bene che in molte organizzazioni esistono priorità diverse in base al peso del cliente, al valore contrattuale, alla visibilità del progetto o al rischio commerciale. Sarebbe ingenuo fingere il contrario. In alcuni contesti questa distinzione è persino inevitabile.
Ma nel service desk esiste un punto che, secondo me, non dovrebbe cambiare: il modo in cui scegliamo di presentarci come servizio.
Non può essere solo il cliente a definire il nostro comportamento. Dobbiamo essere noi a decidere chi vogliamo essere, che tipo di affidabilità vogliamo trasmettere e quale standard relazionale vogliamo mantenere.
Perché la percezione del valore non nasce soltanto dalla dimensione economica del rapporto. Nasce anche da come fai sentire le persone quando qualcosa non funziona.
In quel caso il processo aveva fallito. La presa in carico era stata lenta. La priorità era stata valutata male. La comunicazione non era stata sufficiente. Il cliente si era sentito abbandonato.
E quando il processo che governi non funziona, non puoi nasconderti dietro il processo.
Puoi spiegare.
Puoi ricostruire.
Puoi correggere.
Puoi migliorare.
Ma prima di tutto devi assumerti la responsabilità del fatto che, per quella persona, il servizio non ha funzionato.
Questo non significa colpevolizzare il team.
Anzi, è l’opposto.
Metterci la faccia, per un responsabile, significa anche proteggere le persone da una lettura superficiale dell’errore. Significa evitare che tutta la tensione si scarichi sull’advisor che ha gestito il ticket. Significa dire: se un processo di assistenza arriva a produrre una situazione del genere, allora la responsabilità non è solo di chi ha preso in mano una singola richiesta. È anche di chi quel processo lo guida, lo misura, lo organizza e lo fa evolvere.
Essere responsabili non significa solo distribuire attività.
Significa anche essere il punto in cui, quando serve, la pressione si ferma.
Quando chiamai il cliente, ero pronto a ricevere una sfuriata.
E in effetti la telefonata iniziò così.
Mi venne detto che i tempi di gestione erano stati inaccettabili, che la situazione aveva creato forte preoccupazione e che in quasi trent’anni di collaborazione non era mai successa una cosa del genere. Il cliente arrivò anche a dire che avrebbero valutato altri fornitori.
Era una frase pesante.
Ma, in quel momento, comprensibile.
Dal loro punto di vista, non stavano semplicemente aspettando la risoluzione di un’anomalia. Stavano temendo di aver perso oltre un mese di lavoro e avevano la sensazione che nessuno stesse gestendo la situazione con la dovuta attenzione.
La conversazione avrebbe potuto irrigidirsi subito.
Avrei potuto difendere il team. Avrei potuto spiegare i volumi di richieste, le priorità, la complessità tecnica, la sequenza degli eventi. Avrei potuto riportare tutto su un piano operativo.
Invece, la prima cosa che feci fu chiedere scusa.
Non una scusa generica.
Una scusa personale, legata alla responsabilità del servizio.
Dissi, in sostanza:
“Le chiedo personalmente scusa per la gestione non ottimale della segnalazione. Come responsabile del servizio di assistenza, se il processo di gestione non ha funzionato, è una mia responsabilità. Mi dispiace che un cliente come lei sia arrivato, dopo tanti anni di collaborazione, a essere deluso dal service desk, perché significa che in qualche modo abbiamo fallito e tradito la sua fiducia.”
In molte culture aziendali si preferisce usare formule più neutre, più protette, più distanti. Ci si scusa “per il disagio”, si ringrazia “per la segnalazione”, si comunica che “sono in corso verifiche”.
Tutte frasi utili, in alcuni casi.
Ma non in quel momento.
In quel momento serviva far percepire che dietro al servizio c’era qualcuno disposto a esporsi, non una struttura pronta a nascondersi dietro il linguaggio formale.
Quella scelta cambiò il tono della conversazione.
Il cliente, invece di aumentare la pressione, si distese. Mi ringraziò per averci messo la faccia. Da quel momento il dialogo tornò possibile.
Non perché il problema fosse risolto.
Ma perché la relazione aveva ripreso aria e perché mi ero rapportato come essere umano e non come azienda.
Le scuse valgono solo se sono seguite dai fatti.
Da questa esperienza ho imparato che le scuse, in un contesto professionale, possono essere molto potenti. Ma solo a due condizioni: devono essere sincere e devono essere seguite da azioni concrete.
Se diventano una formula ripetitiva, perdono valore. Se ogni problema viene accompagnato da scuse ma nulla cambia, il cliente smette di percepirle come un gesto di attenzione e inizia a leggerle come un automatismo.
Perché chiedere scusa e poi ripetere lo stesso errore significa rompere la fiducia due volte.
Dopo aver riaperto il dialogo, emerse il vero centro della preoccupazione.
Il cliente non era solo arrabbiato per i tempi di gestione. Era spaventato dall’idea di aver perso un mese e mezzo di lavoro.
Questa distinzione è fondamentale.
A volte leggiamo la rabbia del cliente come un problema di tono, di pressione o di pretesa. Ma spesso, sotto la rabbia, c’è paura. Paura di non essere tutelati. Paura di aver perso dati. Paura di dover rispondere internamente di qualcosa che non si sa spiegare. Paura che il fornitore non abbia davvero il controllo della situazione.
In quel momento, quindi, non bastava dire “risolveremo”.
Bisognava rassicurare con serietà.
Dissi al cliente che avevamo già fatto una prima analisi del problema, seppur ancora superficiale, e che l’ipotesi più probabile era una mancata visualizzazione dei dati, non una perdita effettiva degli stessi. Aggiunsi che avremmo trovato un modo per risolvere la situazione, perché quello era il nostro mestiere.
Poi chiesi una cosa precisa: una giornata di tempo per recuperare i backup, completare l’analisi e individuare la soluzione migliore.
Mi presi anche un impegno chiaro: lo avrei aggiornato la mattina successiva con l’esito dell’analisi e con la soluzione che intendevamo applicare.
Questa parte è decisiva.
Metterci la faccia non significa solo parlare bene in un momento difficile. Significa assumersi un impegno che poi devi rispettare.
Perché una promessa relazionale non sostenuta dai fatti è peggio del silenzio.
Se dici al cliente “me ne occupo io” e poi sparisci, hai peggiorato la situazione. Se chiedi fiducia e poi non dai seguito, quella fiducia si rompe ancora di più. Se ti esponi personalmente e poi non governi davvero il problema, la tua presenza diventa una messa in scena.
La relazione funziona solo quando la parola è seguita dall’azione.
Anche nelle pratiche di incident communication, infatti, la comunicazione efficace non si limita a riconoscere il problema: deve dare contesto, rassicurare e mantenere aggiornato il cliente fino alla risoluzione.
Da lamentela a fiducia recuperata.
Non è necessario entrare nel dettaglio tecnico di ciò che venne fatto.
La cosa importante è che il giorno successivo richiamai il cliente per comunicargli la soluzione. Spiegai che avremmo tracciato nella segnalazione ogni passaggio effettuato, così da rendere visibile il lavoro svolto e lasciare una ricostruzione chiara della gestione.
A quel punto mancava solo il feedback finale dell’utente per poter chiudere definitivamente la vicenda.
Dopo qualche giorno arrivò la conferma positiva da parte di chi aveva aperto la richiesta di supporto.
E poco dopo ricevetti anche una email personale.
La riporto perché, al di là delle parole, rappresenta bene il valore della componente relazionale nel servizio.
Gentilissimo, buongiorno.
La presente per esprimerle la nostra gratitudine per la professionalità, competenza e gentilezza dimostrate nella risoluzione delle nostre problematiche.
Apprezziamo sinceramente la Sua serietà e la qualità del Suo operato.
Grazie per averci aiutato.
Quella email, per me, fu molto significativa.
Non perché cancellasse l’errore. L’errore c’era stato.
Non perché rendesse accettabile una gestione iniziale non adeguata. Non lo era.
Ma perché mostrava una cosa importante: anche una situazione compromessa può essere recuperata se viene gestita con responsabilità, professionalità, presenza e serietà.
Il cliente non aveva dimenticato il problema.
Aveva però percepito che, a un certo punto, qualcuno si era assunto la responsabilità di prenderlo davvero in carico.
E questo, nella relazione tra cliente e servizio, pesa moltissimo.
Non posso sapere con certezza cosa sarebbe successo se non fossi intervenuto personalmente. Posso però dire che la gestione della segnalazione avrebbe avuto un valore percepito nettamente inferiore.
Probabilmente il cliente avrebbe ricevuto un messaggio più asettico. Avrebbe aspettato la soluzione. Forse il problema sarebbe stato risolto comunque. Ma sarebbe rimasta intatta l’idea di un service desk lontano, umanamente inaccessibile, incapace di fare anche solo una telefonata quando la relazione lo richiede.
Per me, invece, il service desk dovrebbe essere proprio il team che rompe questa distanza.
Il punto dell’organizzazione che avvicina l’utente, non quello che gli fa percepire isolamento.
Cosa insegna questa esperienza sulla leadership.
Questa esperienza mi ha confermato una convinzione che difendo spesso: nel service desk la componente relazionale non è un elemento accessorio.
È parte del servizio.
Un ticket non è solo una richiesta tecnica. È anche una relazione temporaneamente aperta tra una persona che ha bisogno di aiuto e un’organizzazione che deve dimostrare di essere affidabile.
Quando tutto funziona, questa relazione resta sullo sfondo. Nessuno ci pensa troppo. Il cliente segnala, il team risponde, il problema si risolve.
Ma quando qualcosa va storto, la relazione diventa centrale.
Lì si vede davvero la qualità della leadership.
Non quando il processo scorre senza attriti.
Non quando gli SLA sono rispettati.
Non quando tutto è sotto controllo.
Si vede quando il processo non basta più.
Quando il cliente è deluso.
Quando il team ha gestito male una priorità.
Quando una richiesta è rimasta troppo a lungo senza attenzione.
Quando la fiducia si è incrinata.
Quando qualcuno deve decidere se nascondersi dietro una spiegazione formale o assumersi la responsabilità di riaprire il dialogo.
Metterci la faccia non significa fare l’eroe.
Significa riconoscere che, in certi momenti, il ruolo manageriale non può restare dietro le quinte. Deve diventare visibile. Deve farsi carico della relazione. Deve proteggere il team senza negare l’errore. Deve rassicurare il cliente senza promettere cose che non può mantenere. Deve trasformare una criticità in un’occasione per ricostruire fiducia.
Da un problema gestito male, in quel caso, siamo riusciti a ricostruire fiducia e a trasformare una criticità in valore.
E forse è proprio qui che si misura una parte importante della leadership: non quando tutto funziona, ma quando qualcosa si rompe e qualcuno deve scegliere se restare nascosto dietro il processo o metterci la faccia.
