Torna al blog
WebChat design

Come progettare un percorso alternativo per WebChat quando la chat non è disponibile o è difficile da usare

Un percorso alternativo per WebChat è un servizio di assistenza definito per le persone che non possono, non vogliono o non dovrebbero essere costrette a completare la propria richiesta in chat. Scopri come renderlo accessibile, gestito, testabile e rispettoso della privacy.

Percorso di assistenza clienti con WebChat integrata che conduce ad alternative accessibili via telefono, modulo e richiamata

Mappa i punti in cui la chat può non funzionare o diventare difficile da usare

Inizia con una mappa dei guasti end-to-end. Un widget può non caricarsi; può caricarsi ma risultare difficile da usare con la tastiera; un cliente può essere bloccato dall'autenticazione, dal caricamento di file, dalla convalida o da una risposta automatizzata; oppure la conversazione può raggiungere una coda senza una persona adeguatamente disponibile. Ogni punto richiede un passaggio successivo definito.

Distingui i guasti per cui il tuo team web può progettare una soluzione dalle condizioni che non può controllare completamente. Il tuo team controlla la visibilità e l'accessibilità dell'alternativa, la formulazione, la progettazione del modulo, i dati raccolti, le regole di instradamento e la politica di assegnazione del personale. Il supporto del browser, le condizioni di rete e la disponibilità di canali di terze parti possono influire sull'esperienza, ma non eliminano la necessità di un'alternativa utilizzabile.

Includi la scelta del cliente nella mappa. Una persona che afferma di preferire telefonare, di aver bisogno di un interprete o di non poter continuare in sicurezza in chat non è una conversione fallita. Sta richiedendo un percorso di servizio appropriato.

  • Il widget non compare perché gli script sono bloccati, la connessione è lenta o il browser non è supportato.
  • Il pulsante di avvio, i controlli, lo spostamento del focus o l'inserimento dei messaggi non possono essere usati efficacemente con una tastiera o una tecnologia assistiva.
  • L'accesso, le verifiche di identità o i processi con codice monouso impediscono di procedere.
  • Il caricamento di file, la convalida dell'input o il feedback di invio non sono chiari o falliscono ripetutamente.
  • L'automazione non comprende la richiesta, non può convalidare una risposta o raggiunge un caso fuori ambito.
  • Nessun operatore formato è disponibile nell'intervallo di tempo richiesto dal cliente.
  • Il problema richiede un canale con funzionalità che la chat non può fornire in sicurezza, come un appuntamento specifico per il servizio o assistenza in presenza.
Mappa i punti in cui la chat può non funzionare o diventare difficile da usare

Definisci uno standard minimo per ogni percorso alternativo

Usa quattro test: visibile, comprensibile, utilizzabile e disponibile. Un cliente dovrebbe poter vedere il percorso senza completare la chat, capire cosa accadrà dopo, usarlo senza puntatore o barriere non necessarie e raggiungere un servizio realmente presidiato oppure che fornisca un esito chiaro fuori orario.

Per un modulo alternativo accessibile, chiedi soltanto ciò che serve per gestire la richiesta di assistenza. Fornisci a ogni controllo un'etichetta visibile associata, inserisci istruzioni dove necessario e non fare affidamento sul testo segnaposto per comunicare informazioni obbligatorie. Se si verifica un errore, identifica il campo interessato, spiega il problema e come correggerlo, quindi collega al campo quando opportuno.

Testa i moduli sul server oltre che nel browser. I controlli lato client possono essere aggirati e il supporto dei browser varia. Dopo l'invio, fornisci una conferma inequivocabile che la richiesta è stata ricevuta, oppure un esito di errore chiaro e un modo per proseguire se l'invio non può essere completato.

  • Tastiera: tutti i controlli del percorso, i campi e le azioni di invio funzionano senza mouse, e il focus visibile resta evidente.
  • Zoom e ridisposizione: a una larghezza equivalente a 320 pixel CSS, non si perdono informazioni o funzionalità e l'uso ordinario non richiede lo scorrimento bidimensionale.
  • Autenticazione: non richiedere un test della funzione cognitiva, salvo che sia disponibile un metodo alternativo o un meccanismo di assistenza.
  • Feedback: i messaggi di successo, errore e passaggio successivo sono chiari ed esposti in modo accessibile.
  • Coerenza: i percorsi di assistenza ripetuti compaiono in una posizione relativa coerente nelle pagine pertinenti.

Scegli un percorso adatto all'attività e al cliente

Non esiste un'alternativa universalmente corretta. Seleziona i percorsi sulla base della ricerca con gli utenti, del rischio di servizio e della capacità operativa. Il telefono può essere la scelta migliore per problemi urgenti o complessi; una richiesta di richiamata può ridurre il tempo di attesa in coda; un modulo accessibile è adatto ai casi non urgenti che richiedono una traccia scritta; un percorso in presenza o specifico per il servizio può essere necessario quando il cliente necessita di assistenza pratica.

Non pubblicare un percorso soltanto perché esiste altrove nell'organizzazione. Verifica che accetti il tipo di problema pertinente, disponga di un team ricevente, protegga le informazioni del cliente e possa comunicare un esito. Un'alternativa che arriva a una casella di posta non monitorata crea un secondo fallimento.

Quando chat e alternativa fanno parte dello stesso processo, evita di chiedere ai clienti di ripetere informazioni che hanno già fornito. Nel rispetto di adeguati controlli sulla privacy, le informazioni necessarie nuovamente dovrebbero essere disponibili per la selezione o precompilate. Non trasferire automaticamente informazioni sensibili solo perché sono state inserite in chat.

  • Telefono: usalo per questioni urgenti, sensibili o molto complesse; pubblica gli orari di chiamata e, ove applicabile, le modalità di accessibilità.
  • Modulo web accessibile: usalo per richieste strutturate e non urgenti; fornisci un riferimento o una conferma dopo l'invio riuscito.
  • Richiesta di richiamata: usala quando i clienti non dovrebbero dover attendere in una coda; raccogli un metodo di contatto adeguato e solo i dettagli di pianificazione necessari.
  • Percorso in presenza o specialistico: usalo quando un'attività richiede assistenza locale, pratica o regolamentata.
  • Percorso di emergenza o tutela: rendilo distinto dalla normale assistenza quando pertinente, con formulazione e responsabilità approvate dal team di servizio responsabile.

Scrivi testi che indichino il passaggio successivo senza fare promesse che non puoi mantenere

Il testo dell'alternativa dovrebbe riconoscere la situazione, indicare l'azione disponibile e spiegare cosa accadrà dopo. Evita di attribuire la colpa al cliente, il gergo tecnico e formule vaghe come “riprova più tardi” senza altre possibilità. Evita promesse sui tempi di risposta, salvo che il team responsabile possa rispettarle in modo affidabile e abbia approvato la formulazione.

Usa testi specifici per canale. Un'opzione telefonica richiede un numero e gli orari. Una richiesta di richiamata richiede il meccanismo di conferma previsto ed eventuali limitazioni. Un modulo richiede una dichiarazione su ciò che il cliente può inviare e un chiaro messaggio di successo. Uno stato fuori orario richiede la prossima azione disponibile, non un vicolo cieco.

  • Esempio di messaggio per errore del widget: “La chat non è disponibile in questo momento. Puoi richiedere assistenza tramite il nostro modulo accessibile oppure chiamare [numero] negli orari [orari].”
  • Esempio di uscita dall'automazione: “Non sono riuscito a risolvere la richiesta in chat. Scegli ‘Richiedi aiuto a una persona’ per inviare i tuoi dati al team di assistenza, oppure usa [percorso alternativo].”
  • Esempio di conferma del modulo: “La tua richiesta è stata ricevuta. Conserva questa conferma per i tuoi archivi. Se il problema è urgente, chiama [numero].”
  • Evita: “Risponderemo a breve”, a meno che “a breve” abbia un significato operativo definito e monitorato.

Trasferisci il contesto con attenzione, rispettando confini di consenso e verifica

Il trasferimento del contesto può ridurre l'impegno del cliente, ma deve essere proporzionato. Definisci un piccolo record di passaggio per ciascun percorso alternativo: possono essere sufficienti la categoria del problema, un breve riepilogo scritto dal cliente, la fase del percorso, il riferimento della pratica pertinente e il metodo di contatto preferito. Identifica cosa non viene mai copiato automaticamente, come allegati non necessari, testo libero sensibile o credenziali.

Informa i clienti su ciò che verrà inviato al team successivo e, quando opportuno, offri loro la possibilità di rivederlo o modificarlo. Se è coinvolto un reparto, un sistema o una finalità diversa, i revisori della privacy dovrebbero determinare se sono necessari un nuovo consenso, una nuova informativa o un'altra base giuridica. Un percorso alternativo non è un motivo per raccogliere più dati di quanti ne richieda l'attività.

Il personale ricevente deve verificare l'identità attraverso il processo approvato dall'organizzazione prima di divulgare informazioni sull'account o agire su richieste sensibili. Un riferimento della pratica può aiutare a individuare l'attività, ma non costituisce automaticamente una prova di identità.

  • Definisci i campi minimi di passaggio e la regola di conservazione per ciascun percorso.
  • Non chiedere mai ai clienti di inviare password, codici di autenticazione o altre credenziali tramite chat o modulo alternativo.
  • Mantieni una spiegazione rivolta al cliente su quali informazioni vengono trasferite e perché.
  • Consenti al personale di vedere la conversazione originale solo quando il ruolo e la pratica lo richiedono.
  • Fornisci un percorso manuale quando il contesto non può essere trasferito in modo sicuro o tecnicamente possibile.

Crea uscite esplicite dall'automazione e un percorso di escalation verso una persona

L'automazione dovrebbe offrire una via d'uscita prima che la frustrazione si trasformi in abbandono. Definisci i trigger per un percorso assistito: intento ripetutamente frainteso, ripetuti fallimenti di risposte convalidate, richiesta esplicita di una persona, argomento ad alto rischio, richiesta fuori ambito o flusso automatizzato che non riesce a completare un passaggio richiesto.

Il percorso di escalation deve indicare una coda ricevente o un canale alternativo, non limitarsi a mostrare un messaggio rassicurante. Stabilisci cosa trasmette l'automazione, cosa devono fare i clienti successivamente e cosa accade se al momento non è disponibile nessuna persona. Quando un passaggio non può essere presidiato, offri invece il percorso approvato di richiamata, modulo o telefono.

Il giudizio umano resta necessario per eccezioni, richieste ambigue, reclami, indicatori di vulnerabilità e casi in cui le policy o la sicurezza richiedono una revisione. Il personale necessita di istruzioni per accettare, reindirizzare e chiudere le richieste alternative, incluso cosa fare quando la richiesta è arrivata al reparto sbagliato.

  • Trigger: il cliente seleziona “parlare con una persona” o equivalente; azione: offri un trasferimento presidiato oppure un percorso alternativo chiaramente identificato.
  • Trigger: due o più tentativi non riusciti con la stessa risposta convalidata; azione: spiega il blocco e offri assistenza senza imporre un altro tentativo.
  • Trigger: problema sensibile, urgente o definito dalle policy; azione: disattiva l'automazione non adatta e indirizza al percorso di servizio responsabile.
  • Trigger: fuori orario; azione: mostra la disponibilità attuale e la successiva azione supportata, senza far intendere che sia presente assistenza in tempo reale.

Assegna responsabilità tra code, orari e reparti

Ogni richiesta alternativa necessita di un responsabile incaricato dal ricevimento fino alla risoluzione. Mappa il modello operativo per tipo di richiesta, canale, team interno, ore di copertura, contatto per l'escalation e standard di chiusura. Distingui il team responsabile della presentazione sul sito da quello responsabile dell'esito del servizio; potrebbero non coincidere.

Una casella condivisa può essere utile quando le conversazioni WebChat e WhatsApp richiedono una gestione coordinata, ma non tutte le alternative devono entrare nello stesso spazio di lavoro. I percorsi telefonici, in presenza e specialistici possono avere sistemi e controlli separati. Ciò che conta è un passaggio documentato e un modo per identificare le richieste che non hanno ricevuto una risposta responsabile.

Pianifica le variazioni della domanda, la copertura con personale formato, la protezione della privacy e i cicli di feedback. Se un percorso non è disponibile fuori dall'orario operativo, definisci e testa la formulazione fuori orario e la responsabilità per le richieste ricevute in quel periodo.

  • Indica un responsabile del servizio, un responsabile operativo della coda e un responsabile dell'escalation per ciascun percorso.
  • Documenta orari di apertura, copertura linguistica, copertura specialistica e gestione fuori orario.
  • Definisci regole di instradamento per richieste arrivate al team sbagliato, duplicate, incomplete e urgenti.
  • Fornisci al personale modelli, istruzioni di verifica e un percorso chiaro per dubbi su accessibilità o privacy.
  • Esamina le richieste non risolte e i modelli di guasto ricorrenti con i team in grado di correggerli.

Domande frequenti

Che cos'è un percorso alternativo per WebChat?

È un percorso di assistenza alternativo definito per i clienti che non possono, non vogliono o non dovrebbero essere costretti a completare la propria richiesta nella chat integrata. Include il percorso rivolto al cliente, il team ricevente, gli orari operativi, i controlli sulla privacy e il processo di risoluzione.

Una pagina di contatto generica è sufficiente quando WebChat non è disponibile?

Di solito no. Una pagina di contatto generica potrebbe non identificare il problema pertinente, non offrire un metodo accessibile, non preservare il contesto necessario o non raggiungere un team in grado di agire. Un'alternativa utile dice ai clienti esattamente cosa fare e li collega a un percorso di servizio gestito.

Cosa dovrebbe raccogliere un modulo alternativo?

Raccogli solo le informazioni necessarie per gestire la richiesta, come la categoria del problema, una descrizione concisa, un metodo di contatto sicuro e un riferimento pertinente. Usa etichette visibili, istruzioni chiare, messaggi di errore accessibili e convalida lato server. Non richiedere password o codici di autenticazione.

Come dovrebbe l'automazione passare la richiesta a una persona?

Definisci trigger espliciti, tra cui una richiesta diretta di assistenza umana, ripetuti fallimenti della convalida, ripetuti fraintendimenti, argomenti ad alto rischio e richieste fuori ambito. Il trigger dovrebbe condurre a una coda presidiata quando disponibile oppure a un percorso chiaramente identificato via telefono, richiamata o modulo quando non lo è.

In che modo webchat.vip può supportare il servizio WebChat principale?

webchat.vip offre widget WebChat installabili, personalizzabili e multilingue, oltre a flussi automatizzati in grado di raccogliere risposte convalidate, diramare, trasferire e passare le richieste alle persone. I team possono organizzare operatori, reparti, instradamento e pianificazioni, e usare una casella condivisa per le conversazioni WebChat e WhatsApp. Analisi operative, registri delle conversazioni, valutazioni e report esportabili possono supportare la revisione. I responsabili del sito restano responsabili della progettazione e gestione di percorsi di assistenza alternativi al di fuori del servizio di chat principale.

Fonti e approfondimenti

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

  1. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C
  2. Understanding Success Criterion 2.1.1: Keyboard — W3C Web Accessibility Initiative
  3. Forms Tutorial — W3C Web Accessibility Initiative
  4. Validating Input — W3C Web Accessibility Initiative
  5. User Notification — W3C Web Accessibility Initiative
  6. Understanding Success Criterion 3.3.8: Accessible Authentication (Minimum) — W3C Web Accessibility Initiative
  7. Assisted digital support: an introduction — GOV.UK Service Manual
  8. Designing assisted digital support — GOV.UK Service Manual
  9. Set up and manage user support — GOV.UK Service Manual
  10. Quality assurance: testing your service regularly — GOV.UK Service Manual