Torna al blog
Automation flows

Come gestire più richieste dei clienti in un'unica chat

Un modello operativo pratico per identificare, stabilire le priorità e seguire le esigenze secondarie dei clienti tramite automazione, passaggi di consegne e chiusura.

Operatore dell'assistenza che esamina una chat cliente con due richieste distinte

Una chat può contenere più di un obbligo di assistenza

Un cliente può scrivere: «Dov'è il mio ordine e, per favore, cambiate l'email del mio account?». Trattare questo messaggio come un unico intento crea un errore silenzioso: il team risolve la domanda più evidente sulla consegna, poi chiude la conversazione mentre la richiesta relativa all'account scompare.

L'unità operativa non è sempre il thread della chat. È ogni singola attività che richiede una risposta, un'azione, un responsabile o un follow-up. Un singolo thread può contenere diverse richieste e una richiesta può rimanere irrisolta anche quando un'altra è completata.

Questo aspetto è particolarmente importante nelle transizioni: un ramo automatizzato riconosce la prima richiesta, un trasferimento sposta il thread a uno specialista oppure un operatore usa un modello di chiusura dopo aver risolto una sola parte. Progetta ogni transizione in modo da preservare le richieste irrisolte nella tua procedura operativa.

  • Le richieste correlate riguardano lo stesso risultato, come cambiare un indirizzo di consegna e verificare che la modifica sia andata a buon fine.
  • Le richieste dipendenti devono avvenire in ordine, come verificare un account prima di modificarne i dati.
  • Le richieste separate richiedono attività, responsabili o aspettative di servizio diversi, come un'indagine su una consegna più una modifica dell'account.
  • Una richiesta separata non deve essere scartata silenziosamente solo perché è arrivata per seconda.
Una chat può contenere più di un obbligo di assistenza

Classifica le richieste prima di scegliere un intento primario

Inizia riassumendo le richieste con le parole del cliente. Questo conferma sia la comprensione sia la creazione di una registrazione chiara per l'operatore successivo. Per esempio: «Posso aiutarti con lo stato della consegna e con la modifica dell'indirizzo email».

Decidi quindi se una richiesta blocca realmente l'altra. In caso affermativo, rendi chiara la dipendenza e procedi un passaggio alla volta. Se le richieste sono indipendenti, il team può risolverle in sequenza, dividere internamente le responsabilità oppure chiedere al cliente quale questione sia più urgente quando i tempi o le policy lo rendono necessario.

Non chiedere ai clienti di ripetere una lunga spiegazione solo per adattarla a un menu. Le informazioni già fornite dovrebbero essere disponibili alla persona che gestisce la richiesta attiva, nei limiti consentiti dal tuo processo. Chiedi solo i dettagli mancanti necessari per l'azione successiva.

  • Usa una scelta del cliente quando entrambe le richieste sono indipendenti, nessuna è urgente e le opzioni disponibili sono brevi e chiaramente distinte.
  • Usa il triage umano quando il messaggio è ambiguo, contiene più di due esigenze, include un reclamo o una possibile questione di sicurezza, oppure potrebbe richiedere team diversi.
  • Dai priorità alla sicurezza, alla sicurezza dell'account, ai disservizi con scadenze ravvicinate e all'urgenza esplicitamente indicata dal cliente rispetto alle attività amministrative ordinarie.
  • Registra il motivo per cui il lavoro è stato messo in sequenza o rimandato, soprattutto quando si applica un obiettivo di livello di servizio.
Classifica le richieste prima di scegliere un intento primario

Usa un modello di raccolta sicuro per intenti multipli

Una prima risposta affidabile ha quattro parti: riconoscere, riassumere, stabilire le priorità e mantenere traccia. Dovrebbe mostrare al cliente che entrambe le questioni sono state ascoltate, chiedere al massimo una decisione alla volta e indicare cosa accadrà all'altra questione.

Esempio: «Vedo due richieste: verificare la consegna e modificare l'email del tuo account. Quale preferisci che affrontiamo per prima? Manterrò l'altra richiesta in questa conversazione per il follow-up». Se la consegna è urgente, un operatore può invece indicare l'ordine proposto: «Verificherò prima la consegna perché è prevista per oggi, poi gestirò la modifica dell'email».

Evita di chiedere in un'unica risposta tutte le informazioni mancanti per entrambe le attività. Le persone potrebbero rispondere a una sola domanda, creando incertezza sul resto. Raccogli le informazioni necessarie per l'attività attiva, poi torna esplicitamente all'elemento rimandato.

  • Riconosci ogni richiesta identificabile prima di creare un ramo o effettuare un trasferimento.
  • Riassumi con un linguaggio breve e concreto; non reinterpretare una richiesta come una promessa che il team non può mantenere.
  • Quando pratico, poni una domanda o richiedi una decisione per messaggio.
  • Documenta la richiesta secondaria nella conversazione o nel processo di follow-up stabilito dal team prima di perseguire l'attività primaria.
  • Dopo l'attività primaria, riapri esplicitamente l'elemento secondario: «La tua domanda sulla consegna ha ricevuto risposta. Vogliamo ora proseguire con la modifica dell'email?»

Usa l'automazione per scelte ristrette, non per interpretazioni forzate

I flussi automatizzati di webchat.vip possono inviare messaggi e file, raccogliere risposte validate, creare rami, trasferire e passare il caso alle persone. Queste funzionalità sono utili per una scelta ristretta e ben compresa, come chiedere se un cliente desidera iniziare dallo stato della consegna o dai dettagli dell'account.

L'automazione dovrebbe indirizzare direttamente al triage umano anziché forzare una scelta quando non può preservare con sicurezza l'intero messaggio, quando il cliente fornisce una spiegazione in testo libero o quando la scelta stessa potrebbe influire sull'accesso, sulla privacy, sulla sicurezza o sull'esito di un reclamo. L'automazione può organizzare il passaggio successivo; non dovrebbe nascondere l'incertezza.

In una casella di posta condivisa, configura l'instradamento in base al lavoro necessario, non semplicemente alla prima parola chiave rilevata o al reparto selezionato all'inizio. Una parola chiave relativa alla consegna non rende una richiesta di modifica dell'account di competenza del team consegne. L'instradamento e la configurazione dei flussi automatizzati di webchat.vip sono le regole operative del tuo team; non controllano il modo in cui un fornitore di canali esterno recapita i messaggi.

  • Offri non più opzioni di quante il cliente possa esaminare rapidamente e includi un chiaro percorso per ricevere assistenza umana.
  • Fai in modo che «Qualcos'altro» o «Ho bisogno di aiuto con entrambi» conducano a un'escalation, non a un vicolo cieco.
  • Prima di implementare un trasferimento, verifica che il team ricevente disponga dei dettagli della conversazione e del riepilogo necessari per proseguire senza ripetizioni inutili.
  • Verifica le interruzioni: un cliente può introdurre una seconda richiesta, porre una domanda a metà della raccolta dati o annullare il percorso corrente.
  • Dopo le modifiche, rivedi i rami con casi di test rappresentativi a intenti multipli.

Rendi la convalida recuperabile e accessibile

Le risposte validate possono migliorare la qualità dei dati, ma un ciclo di risposte non valide è un modo comune per perdere la seconda questione originale. Se un cliente risponde con una spiegazione anziché nel formato previsto, conserva il messaggio, spiega in testo ciò che non è stato accettato e offri un passaggio successivo pratico.

Per le esperienze web, le WCAG 2.2 richiedono che gli errori rilevati automaticamente identifichino l'elemento errato e descrivano l'errore in testo. Quando è nota una correzione, forniscila, a meno che ciò non comprometta la sicurezza o lo scopo del contenuto. Accetta, ove possibile, formati di input legittimi invece di trattare variazioni innocue come un errore.

Non usare mai la convalida per raccogliere informazioni senza uno scopo definito. Spiega perché un dettaglio è necessario quando non è evidente e offri un percorso umano se il cliente non può o non dovrebbe fornirlo in chat.

  • Non efficace: «Risposta non valida. Riprova».
  • Meglio: «Scegli “consegna” o “account” così saprò da cosa iniziare. Se hai bisogno di aiuto con entrambi, rispondi “entrambi” e inoltrerò la richiesta a un collega dell'assistenza».
  • Mantieni limiti ai tentativi; dopo ripetuti insuccessi, passa il caso a un operatore includendo il testo originale del cliente e le risposte tentate.
  • Non richiedere dettagli sensibili tramite un ramo generico solo per classificare una richiesta.
  • Verifica che il widget WebChat offra messaggi di errore chiari, utilizzo da tastiera, linguaggio comprensibile e accesso tramite lettore di schermo.

Mantieni visibile il lavoro secondario senza creare duplicazioni di responsabilità

Il controllo chiave è un processo di follow-up documentato con un responsabile nominato o una coda di follow-up definita. In webchat.vip, i team possono organizzare operatori, reparti, instradamento, pianificazioni, livelli di servizio, modelli e tag. Usa la configurazione disponibile e il processo documentato del tuo team per rendere visibili le richieste irrisolte alla persona o alla coda responsabile dell'azione successiva.

Un tag può segnalare una richiesta secondaria, ma da solo non dimostra la responsabilità. Definisci il significato di ciascun tag, chi lo monitora, entro quando deve essere gestito e come viene rimosso. Se il lavoro deve passare a un altro team, usa un riepilogo conciso e verifica che il team ricevente disponga di contesto sufficiente per evitare che il cliente debba ripetere il caso.

Evita di creare due conversazioni cliente indipendenti per un singolo messaggio, a meno che il tuo modello operativo non possa preservare il contesto, la responsabilità e la comunicazione con il cliente in entrambe. Suddividere il lavoro può essere appropriato internamente; far inseguire al cliente due thread di solito non lo è.

  • Registrazione minima di follow-up: riepilogo della richiesta, stato attuale, responsabile o coda successiva, azione successiva, punto di scadenza e dettagli rilevanti della conversazione.
  • Usa un processo documentato che distingua tra «rimandato», «in attesa del cliente», «trasferito» e «risolto»; non trattare la chiusura di una conversazione come prova che ogni richiesta sia risolta.
  • Se un trasferimento non riesce, la coda ricevente non è disponibile o la responsabilità non è chiara, esegui l'escalation a un responsabile dell'assistenza designato o al supervisore della coda.
  • Quando sono coinvolti dati personali o dell'account, applica le procedure di controllo degli accessi e verifica prima di apportare modifiche.

Chiudi solo dopo una verifica della risoluzione di entrambi gli elementi

Prima di chiudere, l'operatore dovrebbe controllare ogni richiesta identificata in fase di raccolta, comprese quelle introdotte durante trasferimenti o interruzioni. Un messaggio di chiusura dovrebbe separare ciò che è completato da ciò che rimane in sospeso e dire al cliente cosa accadrà dopo.

Un modello di chiusura utile è: «Lo stato della tua consegna è stato verificato. La modifica del tuo indirizzo email è stata inviata al team account ed è ancora in sospeso. Ti aggiorneremo qui quando l'attività sarà completata». Usa un linguaggio sui tempi solo se il tuo team può effettivamente rispettarlo.

Se la richiesta del cliente non è chiara, è potenzialmente dannosa, sensibile dal punto di vista della sicurezza, legalmente rilevante o al di fuori dell'autorità dell'operatore, non fare supposizioni. Esegui l'escalation al team umano qualificato appropriato, fornisci il riepilogo completo e il contesto disponibile e comunica al cliente che un collega esaminerà la questione.

  • Checklist di chiusura: tutte le richieste distinte sono state elencate?
  • Checklist di chiusura: ogni richiesta è contrassegnata come risolta, in sospeso, trasferita o in attesa del cliente nel processo del team?
  • Checklist di chiusura: ogni richiesta in sospeso ha un responsabile, un'azione successiva e un percorso di follow-up?
  • Checklist di chiusura: il cliente ha ricevuto uno stato espresso in linguaggio semplice per ogni richiesta?
  • Checklist di chiusura: il registro della conversazione ha acquisito il passaggio di consegne e la motivazione delle decisioni, quando necessario?

Misura l'errore che stai cercando di prevenire

La qualità nella gestione di intenti multipli non può essere valutata solo dalla velocità della prima risposta o dal volume complessivo delle conversazioni. Esamina i registri delle conversazioni e le analisi operative per trovare prove che una seconda richiesta sia stata riconosciuta, assegnata attraverso il processo del team e completata. webchat.vip registra analisi operative, registri delle conversazioni, valutazioni e report esportabili, che possono supportare questa revisione.

I campioni di chat provenienti da rami automatizzati, trasferimenti e conversazioni chiuse sono particolarmente preziosi. Cerca le conversazioni in cui il cliente ripete una seconda richiesta, risponde «e per quanto riguarda...», viene trasferito più di una volta o riapre una chat chiusa di recente. Sono segnali che il contesto o la responsabilità sono andati persi.

Usa i risultati per affinare la formulazione degli intenti, le regole di instradamento, i modelli e i percorsi di escalation. Input inattesi sono normali in produzione; trattali come feedback per la progettazione anziché come un errore del cliente.

  • Monitora la quota di chat a intenti multipli sottoposte ad audit in cui ogni richiesta identificata ha uno stato finale registrato.
  • Monitora i modelli di riapertura o contatto ripetuto dopo chat che hanno coinvolto un trasferimento o un ramo di automazione.
  • Monitora i cicli di risposte non valide, i passaggi al triage umano e le eccezioni relative a richieste secondarie senza responsabile.
  • Verifica se la reportistica sui livelli di servizio riflette la gestione da parte del team di ogni richiesta, non solo la prima risposta della conversazione.
  • Esporta solo le informazioni necessarie per la revisione e rispetta i requisiti della tua organizzazione in materia di privacy, conservazione e controllo degli accessi.

Domande frequenti

I clienti dovrebbero sempre scegliere una questione primaria?

No. Chiedi una scelta solo quando le richieste sono indipendenti, facili da distinguere e sicure da gestire in sequenza. Invia i casi ambigui, urgenti, sensibili per la sicurezza o complessi al triage umano, includendo entrambe le richieste nel riepilogo del passaggio di consegne.

Come possiamo evitare che una richiesta secondaria si perda dopo un trasferimento?

Documenta la richiesta prima del trasferimento, includi un breve riepilogo delle due richieste e dell'azione successiva e assegna la richiesta irrisolta a un responsabile nominato o a una coda monitorata nel tuo processo operativo. Durante l'implementazione, verifica che il team ricevente disponga dei dettagli necessari per proseguire.

Un flusso automatizzato può gestire contemporaneamente due richieste dei clienti?

Può chiedere al cliente di identificare o dare priorità alle richieste e poi creare un ramo, trasferire o passare il caso a una persona. Non forzare l'automazione a dedurre intenti complessi o a raccogliere più serie di dettagli in un unico turno. Conserva il messaggio originale e offri un percorso umano.

Cosa dovrebbe accadere quando il cliente fornisce una risposta che non supera la convalida?

Spiega in testo cosa deve essere corretto, offri un esempio o una scelta valida quando opportuno, mantieni disponibile la richiesta originale ed esegui l'escalation dopo ripetuti insuccessi. Evita messaggi di errore generici e non considerare una risposta inattesa come prova che il cliente abbia abbandonato la seconda questione.

Chi dovrebbe essere responsabile di una richiesta che coinvolge più reparti?

Assegna un responsabile o una coda unica per coordinare l'esito rivolto al cliente, anche se team specialistici eseguono azioni separate. Il coordinatore dovrebbe tenere informato il cliente e confermare lo stato di ogni richiesta prima della chiusura.

Fonti e approfondimenti

Riferimenti primari e autorevoli usati per verificare la base fattuale di questa guida.

  1. Dialogflow CX: General agent design best practices — Google Cloud Documentation
  2. Handle user interruptions — Microsoft Learn
  3. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative
  4. Validating Input — W3C Web Accessibility Initiative
  5. Structuring forms — GOV.UK Service Manual
  6. Omnichannel customer communication — webchat.vip