Ci sono problemi che un utente può accettare.
Un dato inserito male. Una verifica che non va a buon fine. Una procedura automatica che si blocca. Una carta che non viene validata. Una prenotazione che richiede un controllo aggiuntivo.
Di solito non è l’imprevisto, da solo, a distruggere la fiducia.
La fiducia si rompe dopo, nel modo in cui quell’imprevisto viene gestito. Si rompe quando manca una spiegazione chiara, quando non esiste un punto di contatto o quando nessuno sembra prendere davvero in carico la situazione.
In altre parole, si rompe quando l’utente resta solo proprio nel momento in cui avrebbe bisogno di essere accompagnato.
Questa esperienza nasce da una situazione apparentemente semplice: una vacanza prenotata online, una notifica su un problema con la carta e una prenotazione cancellata a una settimana dalla partenza.
Vista da fuori, potrebbe sembrare una normale disavventura da cliente.
Con gli occhi di chi lavora nei servizi, invece, diventa un caso molto interessante. Perché mostra con chiarezza una cosa che nel service desk si dimentica spesso: l’utente non valuta solo l’esito finale, ma tutto il percorso che attraversa per arrivarci.
Se quel percorso è fatto di messaggi automatici, silenzi, rimbalzi, telefonate anonime e promesse non mantenute, il problema non resta operativo.
Diventa un problema di fiducia.
Una prenotazione confermata, poi il primo dubbio
Quell’anno avevo deciso di dividere le vacanze in due viaggi distinti.
Il primo doveva essere il viaggio del relax assoluto. Niente programmi complicati, niente spostamenti continui, niente itinerari da ottimizzare. Solo mare, cibo, sole e riposo.
Dopo aver confrontato diverse strutture sui servizi di prenotazione online, avevo trovato un hotel che sembrava avere tutto quello che cercavo. La posizione era giusta, i servizi erano quelli desiderati e la formula scelta era perfetta per il tipo di vacanza che avevo in mente.
Ho completato la prenotazione online.
Il pagamento sarebbe avvenuto direttamente in struttura. La carta inserita serviva solo come garanzia, come accade spesso in questo tipo di prenotazioni.
A quel punto, nella mia testa, il viaggio era fatto.
C’erano la conferma, le date, la struttura e l’aspettativa. Mancava solo partire.
Questo aspetto è importante quando si parla di customer experience. Per l’organizzazione, una prenotazione può essere una riga dentro un sistema. Per l’utente, invece, quella prenotazione è già parte dell’esperienza.
Non rappresenta solo un servizio acquistato.
Rappresenta un’attesa, un desiderio, un bisogno, un momento che la persona ha iniziato a costruire mentalmente.
A una settimana dalla partenza ho ricevuto una notifica dal servizio di prenotazione online.
Il messaggio segnalava un problema con la carta di debito utilizzata come garanzia.
La cosa mi ha sorpreso.
Era la stessa carta che avevo già usato in passato su quel servizio. Non doveva esserci un pagamento anticipato. La prenotazione risultava confermata. Non avevo motivo di pensare che ci fosse un rischio reale.
In quel momento, però, si è aperto il primo dubbio.
Che problema c’era sulla carta? La prenotazione era ancora valida? Dovevo fare qualcosa? Quanto tempo avevo per intervenire? Chi dovevo contattare?
La notifica, di per sé, non era sbagliata. Anzi, da un certo punto di vista poteva essere interpretata come un comportamento proattivo. Se c’è un problema sul metodo di garanzia, è meglio intercettarlo prima della partenza piuttosto che scoprirlo al momento del check-in.
Il punto debole non era la notifica.
Era la mancanza di spiegazione.
Un messaggio che comunica un problema, senza chiarire cosa significhi davvero, crea ansia, non sicurezza. Soprattutto quando riguarda qualcosa che l’utente considera già confermato.
Per questo ho contattato subito la struttura attraverso il sistema di messaggistica del portale di prenotazione.
Non ero agitato. Volevo semplicemente capire.
Avevo una prenotazione confermata. Il pagamento era previsto in loco. La carta era già stata utilizzata altre volte. Mi aspettavo una risposta semplice, magari una richiesta di verifica o un’indicazione su come correggere il dato.
Quella risposta, però, non è arrivata.
Ed è qui che il problema ha iniziato a cambiare natura.
Fino a quel momento c’era un’anomalia da chiarire. Dopo la mia richiesta rimasta senza riscontro, ha iniziato a emergere una sensazione diversa: non essere seguito.
Nel service desk questa differenza è enorme.
Un utente può tollerare un errore, un bug o una verifica fallita. Sopporta molto meno il silenzio dopo aver chiesto aiuto.
Perché il silenzio non comunica neutralità.
Comunica assenza.
Il problema non è l’errore, ma il silenzio.
Il giorno successivo è arrivato un secondo messaggio automatico.
La struttura aveva cancellato la prenotazione.
Nessuna telefonata. Nessuna spiegazione dettagliata. Nessuna proposta alternativa. Nessuna presa in carico umana.
A quel punto, la percezione è cambiata completamente.
Fino al giorno prima c’era una vacanza confermata. Ora c’era un problema da risolvere urgentemente, a pochi giorni dalla partenza.
Per l’organizzazione, probabilmente, era stata applicata una procedura: se la carta non viene validata, la prenotazione viene cancellata. Dal punto di vista interno, il flusso poteva anche sembrare logico. Esisteva una regola, il sistema l’aveva applicata, il caso era stato chiuso.
Dal punto di vista dell’utente, però, la percezione era completamente diversa.
Quel messaggio non diceva solo “la prenotazione è stata cancellata”.
Diceva qualcosa di molto più pesante: hai un problema e nessuno ha ritenuto necessario aiutarti prima di arrivare a questo punto.
Non è detto che la struttura volesse essere scorretta. Non è detto che qualcuno abbia agito con superficialità intenzionale. Non è nemmeno detto che la procedura, in astratto, fosse sbagliata.
Resta però un fatto: un processo può essere formalmente corretto e generare comunque una pessima esperienza utente.
Ed è proprio qui che nasce la sensazione di essere un utente lasciato solo: non quando qualcosa va storto, ma quando nessuno accompagna l’utente nel momento in cui il servizio si interrompe.
Quando una procedura automatica produce un impatto rilevante sul cliente, non può essere lasciata senza una gestione relazionale.
Una cancellazione a una settimana dalla partenza non è un semplice evento di sistema. È un evento critico per l’utente. Significa rimettere in discussione un’organizzazione già fatta, un’aspettativa già costruita, forse anche ferie già prese, spostamenti già pianificati, accordi personali già definiti.
In questi casi, la comunicazione automatica non basta.
Serve un contatto. Serve una spiegazione. Serve una possibilità di recupero. Serve un canale chiaro attraverso cui intervenire prima che il danno diventi definitivo.
In quella situazione, invece, il percorso era già scivolato fuori controllo.
Quando l’utente deve inseguire il servizio.
Dopo la cancellazione, ho deciso di cercare direttamente il numero di telefono dell’hotel.
Il canale previsto dal portale non aveva prodotto risposta. Avevo bisogno di parlare con una persona.
Ho chiamato il centralino della struttura e ho spiegato il problema. Da lì sono stato indirizzato a un secondo contatto, perché le prenotazioni online erano gestite da un’altra persona.
Anche questo passaggio è significativo.
Dal punto di vista dell’organizzazione può sembrare normale: il centralino risponde, poi passa il cliente alla persona competente. In una situazione già critica, però, questa dinamica produce un effetto preciso: sentirsi rimbalzato.
Un utente con un problema non vuole conoscere la complessità interna dell’organizzazione.
Non vuole sapere chi gestisce il portale, chi risponde al telefono, chi si occupa delle prenotazioni, chi controlla le carte o chi può autorizzare una soluzione.
Vuole un punto di contatto.
Qualcuno che raccolga il problema e lo tenga in mano fino alla fine.
Nel service desk questo concetto è fondamentale. Lo SPOC, il Single Point of Contact, non è solo una definizione organizzativa. È una promessa fatta all’utente: non ti lascio navigare da solo dentro la mia complessità interna.
La complessità può esistere. È normale.
Ogni organizzazione ha ruoli, strumenti, reparti, responsabilità, limiti e procedure. L’utente, però, non dovrebbe pagarne il prezzo in termini di disorientamento.
In quel momento non sei più semplicemente un cliente con un problema: sei un utente lasciato solo dentro un processo che dovrebbe aiutarti, ma che invece ti costringe a rincorrere risposte.
Nel mio caso, alla fine sono riuscito a parlare con una persona che si occupava delle prenotazioni online. Ho raccontato nuovamente la situazione. La soluzione proposta è stata semplice: effettuare una nuova prenotazione.
La causa indicata era un parametro non compilato correttamente al momento della registrazione della carta. Questo avrebbe impedito la verifica e, secondo la procedura della struttura, avrebbe portato alla cancellazione automatica.
Non ho discusso subito sulla procedura.
In quel momento avevo un solo obiettivo: recuperare la vacanza.
Ho verificato i dati della carta, anche se non trovavo errori evidenti. Avevo già usato quella carta in precedenza. Non capivo perché, in quel caso, fosse diventata improvvisamente un problema.
Ho provato comunque a rifare la prenotazione.
Ed è lì che la situazione è peggiorata.
La camera con il servizio desiderato, in formula all inclusive, non era più disponibile.
La soluzione proposta, quindi, non era più disponibile.
Un problema che fino a quel momento era stato fastidioso è diventato realmente critico.
La procedura non basta se peggiora l’esperienza.
A quel punto ho richiamato la persona che gestiva le prenotazioni online.
Questa volta il tono della conversazione era diverso.
La tranquillità iniziale aveva lasciato spazio a nervosismo e preoccupazione. A una settimana dalla partenza, una prenotazione confermata era stata cancellata senza una spiegazione preventiva, senza risposta alla mia richiesta di chiarimenti e senza una soluzione realmente praticabile.
Ho espresso il mio disagio in modo diretto.
Dall’altra parte, però, la risposta non è stata orientata alla presa in carico del problema. È stata difensiva.
La responsabilità veniva ricondotta a me: secondo l’operatore, non avevo compilato correttamente tutti i campi richiesti per la carta e la procedura era quella.
Questa dinamica si incontra spesso nelle interazioni di supporto.
L’operatore conosce la procedura. Vede il dato mancante. Sa cosa prevede il sistema. Quindi tende a riportare tutto su una logica di responsabilità tecnica: il campo non era compilato, la verifica non è andata a buon fine, la procedura ha cancellato la prenotazione.
Formalmente, può anche avere senso.
Relazionalmente, però, è un errore.
Quando un utente è già in difficoltà, sentirsi dire implicitamente “è colpa tua” non aiuta a risolvere. Anzi, aumenta la tensione.
Questo non significa che l’operatore debba sempre dare ragione al cliente. Non significa negare i fatti, ignorare le procedure o assumersi colpe inesistenti.
Significa però capire il momento.
Prima si riconosce il disagio. Poi si ricostruisce il problema. Poi si spiegano i vincoli. Solo dopo si lavora sulla soluzione.
Se si parte subito dalla difesa della procedura, la conversazione diventa uno scontro tra due prospettive.
Da una parte l’organizzazione dice: “Abbiamo seguito il processo”.
Dall’altra l’utente pensa: “Mi avete lasciato senza vacanza”.
E in quel momento non basta avere ragione sul piano tecnico.
Bisogna recuperare la relazione.
In un service desk efficace, il tono non è un dettaglio. È parte del servizio.
La stessa informazione può rassicurare o irritare, a seconda di come viene comunicata. Una spiegazione può aiutare oppure sembrare un’accusa. Una procedura può essere percepita come garanzia o come muro.
Quando un utente chiama arrabbiato, spesso non sta portando solo un problema tecnico. Sta portando frustrazione, ansia, urgenza, aspettative tradite.
L’operatore non deve subire passivamente qualsiasi aggressività, ma deve saper distinguere tra lo sfogo emotivo e le informazioni utili alla risoluzione.
Interrompere, accusare o irrigidirsi significa spesso gettare benzina sul fuoco.
Ascoltare, riconoscere il problema e riportare la conversazione su un piano operativo può invece cambiare completamente l’esito della relazione.
Durante la telefonata mi è stato detto che sarei stato richiamato entro un’ora con una possibile soluzione.
Quella chiamata non è mai arrivata.
Questo, più della cancellazione, ha chiuso definitivamente la relazione.
Una promessa di ricontatto crea un’aspettativa precisa. Soprattutto quando l’utente si trova in una situazione urgente e non ha ancora una soluzione.
Nel momento in cui dici “la richiamo entro un’ora”, stai chiedendo al cliente di fermarsi. Di non cercare alternative. Di fidarsi ancora per un tempo definito.
Se poi non richiami, non stai semplicemente dimenticando una telefonata.
Stai rompendo l’ultima porzione di fiducia rimasta.
A quel punto ho scelto un’altra struttura.
Non perché fosse necessariamente migliore. Non perché il problema iniziale fosse imperdonabile. Ma perché non avevo più la sensazione di essere seguito.
Il cliente non se ne va sempre perché il competitor offre qualcosa di straordinario. A volte se ne va perché, nel momento del bisogno, qualcuno non ha mantenuto una promessa minima.
Una chiamata. Una spiegazione. Un aggiornamento. Un contatto umano. Un “ci sto lavorando”.
Nel service desk, le promesse non mantenute sono particolarmente dannose perché trasformano un problema aperto in una delusione personale.
Se non puoi richiamare entro un’ora, non prometterlo.
Meglio comunicare un tempo più realistico che creare un’aspettativa destinata a essere tradita. Se non hai ancora una soluzione, puoi dirlo. Se devi verificare, puoi spiegare quando sarai in grado di dare un aggiornamento. Se ti accorgi che non riuscirai a rispettare il tempo promesso, un messaggio intermedio è comunque meglio del silenzio.
L’utente non pretende sempre la soluzione immediata.
Pretende di non essere lasciato nel vuoto.
Cosa avrebbe dovuto fare un service desk.
Questa esperienza, riletta con gli occhi di chi lavora nella gestione dei servizi, mostra alcuni punti critici molto chiari.
Il primo riguarda la comunicazione.
Una notifica automatica può segnalare un problema, ma non può sostituire una spiegazione. Se l’utente deve chiedere cosa stia succedendo, e nessuno risponde, la comunicazione ha già fallito.
Il secondo riguarda la presa in carico.
Quando un utente segnala un problema, qualcuno deve diventare responsabile di quella richiesta. Non necessariamente della soluzione immediata, ma almeno del percorso di gestione. La richiesta non può restare sospesa tra un portale, un centralino, un referente interno e una promessa verbale.
Il terzo riguarda il punto di contatto.
Anche nelle piccole organizzazioni, dove le risorse sono poche e le persone fanno più attività, l’utente non dovrebbe percepire confusione. Può esserci una gestione interna complessa, ma verso l’esterno deve esistere un riferimento chiaro.
Il quarto riguarda il tracciamento.
Un sistema di ticketing non è solo uno strumento tecnico. È un modo per impedire che le richieste si disperdano. Permette di registrare cosa è accaduto, chi ha preso in carico il problema, quali azioni sono state fatte, quali tempi sono stati promessi e quali priorità sono state assegnate.
Nel caso raccontato, una presa in carico più strutturata avrebbe potuto cambiare molto.
La richiesta inviata tramite portale avrebbe potuto generare un ticket. Quel ticket avrebbe potuto avere una priorità legata alla data di partenza. Un operatore avrebbe potuto vedere che la cancellazione avrebbe prodotto un impatto elevato. Il cliente avrebbe potuto ricevere una spiegazione prima della chiusura automatica. La promessa di ricontatto sarebbe stata tracciata. Un responsabile avrebbe potuto verificare che l’aggiornamento fosse stato dato.
Questo non significa che ogni problema sarebbe stato evitato.
Ma il servizio avrebbe avuto più possibilità di intercettare l’escalation prima che diventasse rottura.
Anche i canali di contatto sono importanti, ma solo se dietro esiste una regia unica. Email, telefono, portale web, chat e social possono avere senso, ma moltiplicare i punti di ingresso senza governarli rischia solo di aumentare la confusione.
Un buon service desk non è quello che apre più canali possibili.
È quello che riesce a governarli.
Il problema tecnico si può perdonare, l’abbandono no.
Ripensando a quell’esperienza, il problema iniziale era probabilmente risolvibile.
Una carta non verificata, un campo mancante, una procedura automatica, una prenotazione da confermare nuovamente: tutte situazioni gestibili, se accompagnate nel modo giusto.
Il punto è proprio questo: non sono state accompagnate.
Da utente, non ho percepito soltanto un errore. Ho percepito disinteresse.
Nel servizio, il danno non nasce sempre dal problema in sé. Molto spesso nasce da ciò che accade subito dopo: il tempo che passa prima della risposta, la chiarezza della comunicazione, la facilità nel trovare un referente, il tono della conversazione, la capacità dell’organizzazione di mantenere le promesse fatte.
Un utente può accettare un imprevisto. Può comprendere un vincolo tecnico. Può tollerare una procedura. Può persino riconoscere un proprio errore, se viene accompagnato con chiarezza.
Quello che difficilmente accetta è sentirsi solo proprio nel momento in cui ha bisogno del servizio.
Questo vale per una struttura alberghiera, per un e-commerce, per un software, per un servizio pubblico o per un service desk IT.
Quando l’utente chiede aiuto, non sta chiedendo solo una soluzione tecnica.
Sta chiedendo una presa in carico.
E la presa in carico, spesso, è ciò che separa un problema risolto da un cliente perso.
Perché un servizio non fallisce solo quando qualcosa va storto. Fallisce quando l’utente resta solo mentre prova a rimetterlo a posto.
