Come definire i limiti dell’assistenza clienti su WebChat e WhatsApp

Perché i team di messaggistica hanno bisogno di limiti di servizio chiari e documentati

Un limite di servizio stabilisce cosa può portare a termine un team di assistenza durante una conversazione, in quali condizioni può occuparsene e cosa deve essere gestito attraverso un altro processo. Non è semplicemente un elenco di argomenti che gli operatori devono rifiutare. Un limite ben definito aiuta il cliente a capire cosa succederà in seguito.

Senza limiti scritti, due operatori potrebbero dare risposte diverse alla stessa richiesta. Ai clienti potrebbero anche essere chieste informazioni di cui il team non ha bisogno, oppure potrebbero essere indirizzati altrove senza il contesto necessario per agire. Documentare la decisione e il passo successivo rende le risposte più coerenti su WebChat e WhatsApp.

Un limite è una regola operativa, non una funzionalità della piattaforma di messaggistica. Una casella di posta condivisa può aiutare i team a organizzare conversazioni, operatori, reparti, instradamento, turni, livelli di servizio, modelli e tag; spetta comunque all’organizzazione definire cosa ogni team è autorizzato e attrezzato a fare.

• Definire il risultato consentito, non solo l’argomento. Per esempio, un team può spiegare una regola, ma non approvare un’eccezione.
• Indicare chi è responsabile delle richieste che non possono essere gestite nella conversazione in corso.
• Documentare eccezioni, regole di urgenza e percorso di escalation verso una persona, così che gli operatori non debbano improvvisare.

Valutare ogni richiesta secondo quattro criteri decisionali

Prima di decidere se completare una richiesta nella conversazione, applicate le stesse quattro domande a ogni caso. In generale una richiesta potrebbe essere adatta alla messaggistica, ma richiedere comunque un altro percorso per via dei rischi, delle informazioni necessarie o delle opzioni di assistenza disponibili.

Adeguatezza dell’attività: il lavoro può essere svolto chiaramente attraverso uno scambio di messaggi oppure dipende da una richiesta formale, dall’esame di documenti, da un’azione fisica o da un altro processo? Distinguete tra fornire informazioni, prendere una decisione e compiere un’azione.

Rischio: cosa potrebbe andare storto se la risposta fosse errata, fraintesa o tardiva? Considerate le conseguenze finanziarie, di sicurezza, privacy, legali o di altro tipo rilevanti per il vostro servizio. Definite limiti più rigorosi quando un errore potrebbe causare danni significativi e non chiedete agli operatori di prendere decisioni che esulano dalla loro autorità.

Informazioni necessarie: quali sono le informazioni minime indispensabili per compiere il passo successivo? Se l’attività richiede informazioni che non è autorizzato raccogliere nella conversazione in corso, o che non possono essere esaminate in modo affidabile in quel contesto, utilizzate invece il processo approvato dall’organizzazione. Non raccogliete ulteriori dati sensibili solo per dare l’impressione che la conversazione sia completa.

Percorsi disponibili: esiste un canale concreto e presidiato in grado di gestire la richiesta, e il cliente può accedervi? Individuate il team responsabile, come contattarlo, quali informazioni preparare e cosa fare se il canale preferito non è disponibile. Un percorso che esiste solo sulla carta non è un passo successivo utile.

• Chiedetevi: l’attività rientra nell’autorità e nelle competenze di questo team?
• Chiedetevi: il livello di rischio è accettabile per questo canale e processo?
• Chiedetevi: possiamo raccogliere e utilizzare le informazioni necessarie in modo appropriato?
• Chiedetevi: possiamo indicare un passo successivo accessibile e disponibile e una persona responsabile?

Creare una matrice dei limiti di servizio con tre possibili esiti

Create una matrice breve che gli operatori possano consultare rapidamente. Adattatela al vostro servizio: gli esempi seguenti descrivono criteri decisionali, non regole universali. Verificate con i responsabili delle relative regole chi si occupa della richiesta, quali azioni sono consentite e quali percorsi sono approvati.

Completare qui: scegliete questo esito quando la richiesta è adatta alla messaggistica, l’operatore ha l’autorità necessaria, le informazioni richieste possono essere gestite in modo appropriato e il rischio è accettabile. Spiegate cosa è stato fatto e indicate eventuali azioni o limitazioni ancora in sospeso.

Proseguire con garanzie: scegliete questo esito quando la richiesta può essere gestita nella conversazione, ma a una condizione definita, per esempio fornendo una risposta più circoscritta, richiedendo il controllo di un collega autorizzato o limitando le informazioni condivise. Spiegate la condizione e cosa può aspettarsi il cliente. Se non è possibile rispettarla, passate a un altro processo.

Usare un altro processo: scegliete questo esito quando l’attività esula dall’autorità del team, le informazioni o l’azione richiedono un diverso processo approvato, il rischio è troppo elevato per la conversazione in corso oppure non è possibile completare la richiesta in chat in modo affidabile. Indicate al cliente un percorso concreto e, se opportuno, mettete la richiesta in contatto con un team o una persona responsabile.

• Per ogni tipo di richiesta frequente, registrate: esito, motivazione, azione autorizzata, informazioni consentite, responsabile e passo successivo da comunicare al cliente.
• Indicate separatamente le situazioni urgenti o potenzialmente dannose e specificate il percorso di escalation verso una persona e le aspettative sui tempi di risposta dell’organizzazione. Non lasciate che siano gli operatori a decidere come gestire l’urgenza senza indicazioni.
• Prima di aggiungere una nuova regola, discutete i casi ambigui con i responsabili delle regole, della privacy, della sicurezza o delle competenze specialistiche.

Spiegare il limite e rendere utile il passo successivo

Un rifiuto senza indicare un percorso crea un vicolo cieco. Un messaggio utile sul limite riconosce la richiesta, spiega brevemente la restrizione e indica un passo successivo che il cliente possa compiere. Evitate gergo interno, attribuzioni di colpa, indicazioni vaghe come «contatti il reparto competente» e promesse che il team non può mantenere.

Quando il cliente deve fornire informazioni, spiegate di cosa si tratta, perché sono necessarie e come inviarle tramite il percorso approvato. Le indicazioni W3C sul criterio di successo 3.3.2 delle WCAG prevedono etichette o istruzioni che aiutino gli utenti a sapere quali informazioni inserire. Quando viene rilevato un errore di inserimento e si conosce una correzione possibile, il criterio di successo 3.3.3 delle WCAG richiede di fornire il suggerimento, a meno che ciò non comprometta la sicurezza o lo scopo del contenuto.

Se il cliente non può usare il percorso suggerito, non limitatevi a ripeterlo. Chiedete quale difficoltà sta incontrando e seguite le opzioni documentate per fornire assistenza. Le esigenze di supporto variano; nella progettazione del servizio, tra i possibili canali si possono includere il telefono, l’assistenza di persona o, quando opportuno, la chat Web. Proponete solo le opzioni effettivamente offerte dalla vostra organizzazione.

• Riconoscere la richiesta: «Capisco che ci sta chiedendo di…»
• Spiegare il limite: «Non posso completare questa modifica in questa conversazione perché…»
• Indicare un’azione specifica: «Invii la richiesta tramite [percorso approvato] e includa [informazioni necessarie]».
• Definire le aspettative solo quando sono confermate: indicate il team o il passo successivo, ma non inventate tempi di risposta.
• Offrire un canale per parlare con una persona: «Se non può usare questa procedura, mi dica cosa glielo impedisce e le illustrerò le opzioni di assistenza disponibili».

Mantenere coerenti le regole su WebChat e WhatsApp senza dare per scontato che i canali siano identici

Partite da un’unica regola per il servizio, poi documentate le eventuali limitazioni specifiche di un canale che il team ha verificato. Il limite non dovrebbe cambiare solo perché un operatore risponde su WebChat invece che su WhatsApp. Tuttavia, le informazioni che è possibile raccogliere, il contesto del cliente e i modi pratici per proseguire possono variare: verificate quindi le istruzioni su ciascun canale.

webchat.vip offre una casella di posta condivisa per le conversazioni su WebChat e WhatsApp. Ogni canale WebChat dispone anche di un widget installabile, personalizzabile e multilingue. Queste funzionalità possono aiutare i team a organizzare le conversazioni e a presentare indicazioni, ma non definiscono quali richieste l’organizzazione debba accettare o autorizzare.

Applicate le indicazioni WCAG ai contenuti Web sotto il controllo della vostra organizzazione, come il widget WebChat. Le WCAG riguardano i contenuti dinamici e l’uso del Web su dispositivi mobili; questo non significa che la vostra organizzazione controlli l’interfaccia di WhatsApp. Usate testi leggibili su mobile, etichette e istruzioni chiare ed evitate di affidarvi soltanto alla formattazione o a elementi visivi. Se la procedura deve proseguire altrove, spiegate il percorso nella conversazione in corso ed evitate di chiedere ai clienti di ripetere informazioni quando le vostre procedure consentono di trasferire il contesto.

• Usate le stesse categorie di esito e le stesse motivazioni delle regole su tutti i canali.
• Verificate che link, recapiti, istruzioni e opzioni linguistiche supportate siano corretti in ciascun canale.
• Non promettete che il cliente possa completare un’attività su un canale senza aver verificato che il percorso sia disponibile e appropriato.
• Considerate privacy, consenso e sicurezza come regole operative; raccogliete solo le informazioni necessarie per il passo successivo definito.

Trasformare le regole in una lista di controllo per gli operatori

Una lista di controllo breve rende il metodo utilizzabile durante le conversazioni in corso. Tenetela a portata di mano insieme alle indicazioni del team e assicuratevi che gli operatori sappiano a chi rivolgersi quando un caso non rientra nelle regole. Una regola sui limiti dovrebbe aiutare a prendere decisioni entro confini chiari, non spingere gli operatori a tirare a indovinare.

Per le richieste che richiedono l’invio di dati, specificate quali sono necessari e come il cliente dovrebbe fornirli. Il NIST Privacy Framework è una risorsa volontaria per individuare e gestire i rischi per la privacy tutelando quella delle persone; rivolgetevi ai responsabili della privacy della vostra organizzazione e considerate i requisiti applicabili per definire le regole effettive del servizio.

Per i controlli di sicurezza tecnica, non affidatevi soltanto alla formulazione dei messaggi. L’Application Security Verification Standard di OWASP fornisce una base per testare i controlli di sicurezza delle applicazioni Web. Fate stabilire ai responsabili tecnici e della sicurezza competenti quali controlli si applicano ai sistemi e ai processi coinvolti.

• Individuate il risultato desiderato dal cliente; non deducete più di quanto abbia dichiarato.
• Verificate la richiesta rispetto alla matrice dei tre esiti e confermate l’autorità dell’operatore.
• Limitate le domande alle informazioni necessarie per l’azione approvata; spiegate in parole semplici quali dati sono richiesti.
• Se il caso esula dall’ambito del servizio o non è chiaro, indicate il limite e seguite il percorso documentato per raggiungere una persona o un team autorizzato.
• Registrate motivazione ed esito usando il processo approvato dal team, senza aggiungere dati personali non necessari.
• Verificate che il cliente abbia un passo successivo praticabile e sappia cosa fare se non può accedere al percorso indicato.

Rivedere le decisioni sui limiti e risolvere i vicoli ciechi ricorrenti

I limiti devono essere rivisti quando cambiano le esigenze dei clienti, le regole e le condizioni operative. Cercate richieste ricorrenti che gli operatori non riescono a completare, trasferimenti ripetuti allo stesso team, commenti dei clienti che mostrano confusione e conversazioni che terminano senza una soluzione o un passo successivo chiaro. Questi schemi possono indicare un percorso mancante, una formulazione poco chiara, una regola non aggiornata oppure un’attività da rivalutare, non semplicemente la necessità di rifiutare con maggiore coerenza.

Esaminate gli esempi con gli operatori in prima linea e con i responsabili delle regole pertinenti. Verificate che la regola scritta corrisponda all’autorità effettiva e ai percorsi di servizio disponibili. Quando possibile, testate le formulazioni aggiornate con gli utenti e controllate che restino comprensibili e coerenti dall’inizio alla fine. Le indicazioni GOV.UK sulla progettazione dei servizi raccomandano di integrare i canali di servizio, rendere i servizi semplici da usare e migliorarli per tutta la loro durata.

• Monitorate gli esiti legati ai limiti, le richieste irrisolte, i rinvii ripetuti e il feedback dei clienti usando i dati operativi già raccolti dal team.
• Esaminate un campione di conversazioni per verificare che gli operatori spieghino la motivazione, seguano il percorso approvato ed evitino di raccogliere dettagli non necessari.
• Quando aggiornate una regola, informate gli operatori interessati, aggiornate modelli e indicazioni e verificate che il nuovo percorso sia effettivamente disponibile.
• Inoltrate i dubbi sulle regole, sulla privacy o sulla sicurezza al responsabile competente, invece di risolverli in modo estemporaneo durante una conversazione con il cliente.