Come scrivere messaggi di attesa e trasferimento dell’assistenza clienti che definiscono aspettative chiare
I messaggi di attesa, coda e trasferimento sono impegni operativi, non testi riempitivi. Scopri come definire gli stati del servizio, indicare tempistiche credibili e mantenere un percorso chiaro verso l’assistenza umana.
Perché il silenzio aumenta lo sforzo del cliente
Un cliente che ha inviato un messaggio ma non può capire se sia stato ricevuto, messo in coda o trasferito deve dedurre da sé il passaggio successivo. I clienti possono inviare di nuovo lo stesso messaggio, provare un altro canale, chiedere un aggiornamento o abbandonare la conversazione. Queste azioni possono aumentare la domanda e al tempo stesso rendere più difficile gestire il problema originario.
Un cortese messaggio di conferma non basta se non riflette il reale modello operativo. I messaggi di stato dovrebbero comunicare ai clienti ciò che è noto ora, cosa accadrà dopo e cosa possono fare se il percorso non è adatto. Considerali parte della gestione dei reclami e della progettazione del servizio, quindi riesaminali man mano che le operazioni cambiano.
- Non usare un messaggio di attesa per nascondere una coda, un passaggio di consegne o un’interruzione del servizio.
- Non lasciare intendere che un operatore stia lavorando attivamente su un caso se non ne è stato realmente assegnato uno.
- Non definire un problema risolto soltanto perché l’impatto è stato ridotto: una mitigazione e una correzione permanente sono stati diversi.
- Usa lo stesso vocabolario operativo nell’automazione, tra gli operatori, nei contenuti di assistenza e nelle procedure di escalation.
Mappa prima gli stati del servizio visibili al cliente
Scrivi i messaggi solo dopo aver concordato gli stati che i clienti possono effettivamente incontrare. L’instradamento interno può essere complesso, ma gli stati rivolti al cliente dovrebbero essere pochi, distinti e orientati all’azione. Ogni stato deve avere una chiara condizione di ingresso, un responsabile, una condizione di uscita e una regola di messaggistica.
Evita di esporre etichette interne, come codici di team o stati dei ticket, senza spiegarle. Per esempio, uno stato interno di attesa potrebbe significare che il team necessita di informazioni dal cliente; uno stato di sospensione potrebbe indicare che necessita di un contributo da un altro team. Ai clienti serve il significato pratico, non l’etichetta di back office.
- Ricevuto: il messaggio è arrivato. Indica se è prevista una risposta e cosa succederà dopo.
- In coda: la richiesta è in attesa di un addetto idoneo. Indica la coda o il servizio quando utile, senza inventare un tempo di risposta.
- Assegnato: una persona o un team nominato è responsabile della risposta successiva. Usalo solo quando l’assegnazione è reale.
- Trasferito: un altro team o specialista è ora responsabile dell’azione successiva.
- In attesa del cliente: spiega esattamente quali informazioni o azioni sono necessarie e perché.
- Ritardato: spiega l’impatto noto, il prossimo momento di aggiornamento o l’evento che lo attiverà, oltre a qualsiasi soluzione alternativa sicura.
- Chiuso: conferma l’esito o il motivo della chiusura e spiega come riaprire il caso o richiedere ulteriore assistenza, quando tale percorso esiste.
Usa una struttura in cinque parti per i messaggi di stato
I messaggi efficaci di attesa e trasferimento dell’assistenza clienti rispondono alle domande che altrimenti il cliente porrebbe: Cos’è successo? Chi è responsabile dell’azione successiva? Cosa accadrà dopo? Quando dovrei aspettarmi un altro aggiornamento, se noto? Cosa posso fare ora? Mantieni un linguaggio semplice e specifico per la situazione.
L’elemento temporale è condizionale. Se non puoi sostenere una stima affidabile dei tempi di risposta, indica invece quando aggiornerai il cliente oppure descrivi l’evento che attiverà il messaggio successivo. L’assenza onesta di una stima di arrivo è più utile di una previsione dall’aspetto preciso che i team non riescono a rispettare.
- Stato attuale: “Il tuo messaggio è stato ricevuto ed è in attesa del team di fatturazione.”
- Azione successiva: “Uno specialista della fatturazione esaminerà i dati dell’account che hai condiviso.”
- Responsabilità: “Il team di fatturazione è ora responsabile della prossima risposta.”
- Tempistica: indica una stima o una finestra temporale solo quando si basa sui dati correnti del servizio e sull’orario applicabile.
- Percorso alternativo: quando opportuno, proponi un passaggio di self-service pertinente, un altro metodo di contatto o un percorso di escalation.
Scegli deliberatamente una stima, una finestra temporale o nessuna previsione
Una stima di arrivo è un impegno, non una formula di cortesia. Usala solo quando la domanda storica, i dati sui tempi di gestione e l’orario del canale la supportano, e quando il team può monitorare gli impegni non rispettati. Una finestra temporale è spesso più sicura quando il lavoro dipende dal triage, da uno specialista o da una dipendenza esterna.
Non fornire una stima di risposta quando la durata è realmente sconosciuta, la coda è instabile o un incidente è ancora in fase di valutazione. Sostituiscila con un impegno credibile di aggiornamento, come un momento di riesame dichiarato, o una promessa basata su un evento, come “Aggiorneremo questa conversazione quando avremo confermato l’ambito.” Non promettere tempi di risoluzione quando puoi promettere soltanto un’altra comunicazione.
- Usa una stima specifica quando la capacità e il relativo orario lavorativo la rendono affidabile.
- Usa una finestra temporale quando sono previste variazioni: “Prevediamo di risponderti entro il prossimo giorno lavorativo.”
- Usa un momento di aggiornamento quando la durata è sconosciuta: “Pubblicheremo qui un aggiornamento entro le 16:00 ora locale, anche se l’indagine è ancora in corso.”
- Usa un aggiornamento basato su un evento quando un orario preciso non è credibile: “Ti aggiorneremo quando la verifica dello specialista sarà completata.”
- Non dire mai “a breve”, “il prima possibile” o “un operatore sarà presto disponibile” a meno che la tua pratica operativa non attribuisca a queste espressioni un significato definito e monitorato.
Scrivi messaggi di coda senza garantire una risposta
Un messaggio di coda dovrebbe confermare la ricezione e descrivere il passaggio successivo della gestione senza sovrastimare la disponibilità. “Un operatore sarà presto disponibile” può essere interpretato come una garanzia, in particolare fuori dall’orario di servizio o durante i picchi. Diventa inoltre fuorviante se la conversazione viene successivamente instradata altrove.
Indica chiaramente la condizione del servizio. Se il team non è operativo, dichiaralo. Se la conversazione è in coda, dichiaralo. Se una risposta è disponibile solo per determinati tipi di richiesta, non presentare la conferma di ricezione come una copertura universale dell’assistenza.
- Schema più sicuro: “Abbiamo ricevuto il tuo messaggio. Il nostro team di assistenza esamina i nuovi messaggi durante [orari pubblicati]. Risponderemo qui quando la tua richiesta raggiungerà un operatore disponibile.”
- Schema per picchi di domanda: “Abbiamo ricevuto la tua richiesta. Oggi le risposte richiedono più tempo del solito. Non inviare di nuovo gli stessi dettagli: sono allegati a questa conversazione.”
- Schema fuori orario: “Il nostro team di assistenza in tempo reale non è attualmente disponibile. Il tuo messaggio è registrato per essere esaminato all’inizio del prossimo periodo di copertura programmato.”
- Modalità di errore: una conferma generica viene mostrata anche quando l’instradamento non è riuscito. Aggiungi una procedura di monitoraggio e di ripiego affinché questo messaggio non venga scambiato per una creazione del caso riuscita.
Fai in modo che i messaggi di trasferimento preservino contesto e responsabilità
Un messaggio di trasferimento dovrebbe evitare che il cliente si chieda se venga rimbalzato da un reparto all’altro o se debba ricominciare da capo. Spiega perché il passaggio avviene in termini comprensibili al cliente, identifica il nuovo responsabile a un livello appropriato e conferma quali informazioni accompagnano la conversazione.
Non chiedere al cliente di ripetere dettagli già presenti nella conversazione. Un nuovo team potrebbe aver bisogno di chiarimenti, ma dovrebbe prima esaminare la cronologia e porre una domanda mirata. Se il trasferimento non è completato, non dire ancora che un altro team è responsabile del caso.
- Modello di trasferimento: “Sto trasferendo questa conversazione al nostro [team] perché gestisce [argomento]. Può vedere i dettagli che hai già condiviso. La sua prossima risposta apparirà in questa conversazione.”
- Modello di revisione specialistica: “La tua richiesta necessita di una revisione da parte di uno specialista. Abbiamo inviato la conversazione e le informazioni che hai fornito al [team]. Ti aggiorneremo qui quando la revisione sarà completata.”
- Modello di chiarimento: “Il [team] ha esaminato la conversazione e ha bisogno di un dettaglio per proseguire: [domanda specifica].”
- Modalità di errore: viene annunciato un trasferimento ma nessuna destinazione lo accetta. Definisci un responsabile e un percorso di avviso per i trasferimenti non accettati o troppo datati.
Distingui l’automazione dalla risposta di una persona identificata
I clienti dovrebbero poter distinguere una conferma automatica da un messaggio scritto da un operatore. Questo protegge la fiducia e li aiuta a capire se rispondere subito sarà utile. L’automazione può confermare la ricezione, raccogliere informazioni convalidate, fornire un passaggio successivo noto, instradare un flusso e trasferire alle persone; non dovrebbe fingere di essere una persona.
Quando interviene un operatore, rendi chiara la transizione. Un operatore identificato può confermare di aver esaminato i messaggi precedenti e indicare l’azione successiva. Se un flusso automatizzato raccoglie informazioni, spiega perché serve ogni elemento richiesto ed evita di raccogliere dati non necessari per la richiesta.
- Conferma automatizzata: “Messaggio automatico: abbiamo ricevuto la tua richiesta e stiamo verificando il percorso corretto.”
- Messaggio di ingresso dell’operatore: “Ciao, sono Sam dell’Assistenza. Ho esaminato i dettagli che hai condiviso. Ora verificherò [azione successiva specifica].”
- Non usare un nome umano, un indicatore di digitazione o una formulazione in prima persona nell’automazione se ciò potrebbe ragionevolmente far intendere che una persona abbia letto la conversazione.
- Offri un modo per interrompere o aggirare un flusso quando il cliente necessita di assistenza che il flusso non può fornire in sicurezza.
Pianifica gli orari non coperti, i ritardi imprevisti e gli incidenti
Orari, festività e regole di instradamento devono essere coerenti con il linguaggio visualizzato dai clienti. Esamina ogni canale, reparto e periodo di copertura. Un messaggio che promette una risposta nei giorni feriali è inaccurato se si applica una festività locale o un orario diverso per il team assegnato.
In caso di incidente, comunica l’impatto noto, lo stato di avanzamento della mitigazione, qualsiasi soluzione alternativa sicura e la tempistica della prossima comunicazione. Un avviso iniziale può essere breve quando è importante notificare rapidamente; aggiornalo via via che i fatti vengono confermati. Dichiara che il servizio è ripristinato solo quando hai prove che l’impatto sia terminato, anziché quando una soluzione temporanea lo riduce semplicemente.
- Fuori orario: identifica che la copertura in tempo reale non è disponibile e indica il prossimo periodo di copertura solo se è accurato per quel servizio.
- Ritardo imprevisto: spiega il ritardo senza incolpare il cliente né usare gergo tecnico vago; fornisci un momento di aggiornamento o un percorso alternativo.
- Interruzione del servizio: indica la funzione interessata, l’impatto noto sui clienti, una soluzione alternativa se disponibile e l’impegno per il prossimo aggiornamento.
- Effettua un’escalation interna quando un messaggio operativo non corrisponde più alla realtà, ad esempio in caso di aggiornamento mancato, regola di instradamento non riuscita o coda prolungata.
Domande frequenti
Quanto dovrebbe essere lungo un messaggio di attesa per il cliente?
In genere da una a tre frasi brevi. Includi lo stato attuale, l’azione successiva e solo una dichiarazione sui tempi che il servizio può realmente supportare. Aggiungi un percorso alternativo quando il cliente potrebbe avere bisogno di assistenza urgente o diversa.
Ogni messaggio di coda dovrebbe includere una stima dei tempi?
No. Usa una stima solo quando è credibile per il canale, il team e l’orario applicabili. Se la durata è sconosciuta, fornisci invece un momento specifico per il prossimo aggiornamento oppure indica l’evento che lo attiverà.
Cosa dovrebbe dire un messaggio di trasferimento?
Spiega perché il trasferimento è necessario, chi è responsabile dell’azione successiva, conferma che la cronologia della conversazione accompagna il caso e indica dove apparirà la prossima risposta. Non far ripetere al cliente informazioni già fornite.
Quando si dovrebbe offrire al cliente un’escalation verso un operatore umano?
Offri o preserva un percorso umano quando l’automazione non può gestire la richiesta in sicurezza, quando il cliente è bloccato, quando un errore o un ritardo ha conseguenze rilevanti, quando contatti ripetuti mostrano che il problema resta irrisolto o quando la policy richiede una revisione specialistica. Rendi chiari il percorso e il passaggio successivo previsto.
Come possono i team verificare se questi messaggi funzionano?
Prima del lancio, confronta il testo dei messaggi con l’instradamento reale, gli orari e i livelli di servizio. Dopo il lancio, esamina i contatti ripetuti, gli abbandoni, i trasferimenti, i tempi della prima risposta e dell’assegnazione, le valutazioni e il feedback sulle conversazioni. Riesamina campioni di stime non rispettate, trasferimenti non accettati ed escalation, quindi modifica il messaggio o l’operazione che causa la discrepanza.
Quali controlli di accessibilità si applicano ai messaggi di stato sul web?
Usa un linguaggio semplice, assicurati che i messaggi abbiano abbastanza contesto quando vengono annunciati dalle tecnologie assistive e prova gli aggiornamenti dinamici senza spostamenti indesiderati del focus. Nelle interfacce web, role=status può comunicare in modo discreto gli aggiornamenti di stato alle tecnologie assistive. Mantieni in un ordine relativo coerente i meccanismi ripetuti per il contatto umano, il self-service e il contatto automatizzato quando compaiono nelle diverse pagine, e indica programmaticamente la lingua della pagina e dei passaggi in lingua diversa, secondo WCAG 2.2.
Fonti e approfondimenti
Riferimenti primari e autorevoli usati per verificare la base fattuale di questa guida.
- ISO 10002:2018 — Quality management: Customer satisfaction: Guidelines for complaints handling in organizations — International Organization for Standardization
- Lifecycle of an incident — Google Cloud Documentation
- Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative
- ARIA22: Using role=status to present status messages — W3C Web Accessibility Initiative
- Set up and manage user support — GOV.UK Service Manual
- Error message — GOV.UK Design System
- About open vs. pending and on-hold tickets — Zendesk Help
- Setting your schedule with business hours and holidays — Zendesk Help
- Analyzing your messaging tickets — Zendesk Help