Verifica dell’identità nell’assistenza clienti via chat: guida alla progettazione basata sul rischio

Perché la verifica dell’identità nella messaggistica richiede un approccio basato sul rischio

La verifica dell’identità nell’assistenza clienti non è un’unica domanda universale con un’unica risposta universale. Un cliente che chiede gli orari di apertura genera un rischio molto diverso da chi richiede una modifica dell’indirizzo, la divulgazione della cronologia dell’account o un’azione rilevante sull’account.

Un canale di chat può rendere semplice porre domande e raccogliere risposte. Questa comodità non dimostra che chi gestisce la conversazione debba ricevere informazioni protette o apportare una modifica sensibile. Definisci il livello di garanzia richiesto in base al potenziale danno di una decisione errata: esposizione della privacy, modifica non autorizzata, perdita finanziaria, perdita del servizio o danno a un cliente.

Usa il percorso meno invasivo che supporti l’azione in sicurezza. Le richieste a basso rischio devono restare semplici. Le richieste a rischio più elevato devono passare a un percorso autenticato più solido o a un processo di recupero documentato e gestito da persone. Non compensare un modello di rischio poco chiaro raccogliendo abitualmente più dati personali in chat.

• Inizia dall’esito richiesto, non da un elenco standard di domande sull’identità.
• Aumenta il livello di garanzia all’aumentare del possibile impatto di una decisione errata.
• Separa la normale gestione dell’assistenza dalla gestione del recupero dell’account e dei sospetti di impersonificazione.
• Considera minimizzazione dei dati, accessibilità ed escalation come requisiti del flusso di lavoro, non come miglioramenti facoltativi.

Separa tre decisioni che i team spesso chiamano “verifica”

La parola “verifica” spesso nasconde tre decisioni distinte. Combinarle porta a una raccolta di dati non necessaria da un lato e a un’eccessiva fiducia pericolosa dall’altro.

L’accertamento dell’identità chiede: “Chi è questa persona?”. Comprende la raccolta, la convalida e la verifica di informazioni per stabilire un livello di garanzia rispetto a un’identità dichiarata. Non è necessario per ogni conversazione di assistenza.

L’autenticazione chiede: “Questa persona può dimostrare di controllare un autenticatore associato all’account?”. Può stabilire l’accesso a un account, ma non prova ogni attributo del mondo reale, relazione o autorizzazione dichiarata dalla persona.

L’autorizzazione chiede: “Questa persona autenticata può eseguire questa specifica azione?”. Un titolare di account autenticato potrebbe comunque non avere il permesso di approvare un rimborso, modificare i dati di un altro utente, agire per conto di un’organizzazione o svolgere un’azione ad alto impatto. L’autorizzazione deve essere verificata per ogni richiesta protetta, con una mentalità di diniego predefinito.

• Accertamento dell’identità: stabilire un livello di garanzia rispetto a un’identità dichiarata quando il caso d’uso lo richiede.
• Autenticazione: stabilire il controllo di un autenticatore associato all’account.
• Autorizzazione: confermare il permesso per l’azione, l’account, l’oggetto e il contesto richiesti.
• Gestione del caso: raccogliere solo le informazioni necessarie per comprendere e risolvere il problema; ciò non costituisce automaticamente una prova d’identità.

Classifica le richieste in base al potenziale danno prima di progettare i messaggi

Una semplice classificazione delle richieste offre ad agenti e automazione una base coerente per l’instradamento. Impedisce inoltre che un cliente a basso rischio venga sottoposto a una verifica ad alto attrito che aggiunge poca protezione.

Definisci le categorie in base agli esiti che il tuo team può divulgare o realizzare, poi documenta esempi ed eccezioni. Le categorie seguenti sono un modello di partenza; le soglie corrette dipendono dal tuo servizio, dalla popolazione di clienti e dagli obblighi applicabili.

• Informazioni generali: policy pubbliche, indicazioni sui prodotti, orari del servizio e risoluzione dei problemi non specifica dell’account. Non deve essere richiesta la verifica dell’account soltanto per rispondere a queste domande.
• Informazioni specifiche dell’account: saldi, dettagli degli ordini, messaggi privati, cronologia dell’account, dati di contatto o stato del servizio. Usa un percorso di account autenticato prima della divulgazione.
• Modifiche dell’account: modifiche a dati di contatto, preferenze, impostazioni di accesso, dettagli di consegna o utenti collegati. Richiedi un percorso più solido e verifica se la parte autenticata è autorizzata a quella specifica modifica.
• Azioni ad alto impatto: recupero dell’account, modifiche alle impostazioni di sicurezza, azioni relative ai pagamenti, chiusura, importanti modifiche del servizio o azioni con gravi conseguenze per il cliente. Usa un processo ad alta garanzia progettato intenzionalmente e una revisione da parte di personale formato quando rimane ambiguità.

Applica la minimizzazione dei dati a ogni passaggio della chat

Prima di scrivere un messaggio, indica il suo scopo preciso: quale decisione consentirà questa risposta e qual è la quantità minima di informazioni necessaria per prendere tale decisione? La minimizzazione dei dati richiede che le informazioni siano adeguate e pertinenti allo scopo dichiarato, ma limitate a quanto necessario.

Non chiedere a un cliente di dimostrare più di quanto richieda l’azione richiesta. Per esempio, un agente può aver bisogno di dettagli non sensibili per individuare un caso, mentre il sistema dovrebbe richiedere un percorso di account autenticato prima di rivelare informazioni specifiche dell’account. La richiesta di inviare un documento, la data di nascita completa o altri dati sensibili non deve mai essere un sostituto predefinito di un percorso di verifica progettato.

Rendi visibili gli input vietati nel percorso. I clienti devono essere informati di non inviare password, codici di recupero dell’account o altri segreti riutilizzabili in una conversazione di assistenza. Se inviano comunque informazioni sensibili, segui una procedura di contenimento documentata invece di ripeterle o copiarle in registri aggiuntivi.

• Per ogni campo, registra lo scopo, se è essenziale, chi può visualizzarlo e per quanto tempo viene conservato.
• Usa risposte convalidate solo per informazioni realmente necessarie a instradare o gestire il caso.
• Evita di raccogliere credenziali, codici di recupero e altri segreti riutilizzabili in chat.
• Non considerare una risposta conversazionale a domande personali come un controllo universale dell’identità.
• Rivedi modelli e macro degli agenti per individuare richieste che raccolgono informazioni “per ogni evenienza”.

Scegli un metodo di verifica adatto all’azione

Per informazioni e modifiche protette dell’account, il modello più sicuro consiste nell’indirizzare il cliente a un processo di account autenticato già consolidato, invece di chiedergli di stabilire la propria identità tramite messaggi di chat. La chat può spiegare perché il passaggio è necessario e restare disponibile per aiutare con la risoluzione di problemi non sensibili.

In caso di perdita dell’accesso, usa un percorso di recupero documentato basato sull’analisi del rischio. Il recupero può prevedere un processo approvato di recupero dell’account, un nuovo accertamento dell’identità, un contatto di recupero o un’interazione con un agente specifica dell’applicazione. La regola operativa chiave è non abbassare la soglia normale semplicemente perché il cliente non riesce a superarla in chat.

Quando il recupero riesce, avvisa l’abbonato o il delegato appropriato dopo l’evento di recupero, affinché possa essere rilevato un recupero potenzialmente fraudolento. Incoraggia i clienti, laddove la progettazione dell’account lo supporti, a mantenere più di un modo indipendente per autenticarsi, così da ridurre la dipendenza da percorsi di recupero eccezionali.

• Usa informazioni pubbliche in chat per domande pubbliche.
• Usa un percorso di account autenticato per la divulgazione di informazioni specifiche dell’account.
• Verifica ruolo, relazione e permesso sull’account per le modifiche richieste da un utente autenticato.
• Usa un processo separato e documentato per casi eccezionali ad alto impatto o di recupero.
• Non chiedere una password o un codice di recupero come prova in un messaggio di chat.

Crea un flusso di messaggistica sicuro e comprensibile

Un flusso sicuro deve essere anche comprensibile. Spiega cosa il team deve fare, perché il passaggio è necessario, cosa il cliente non deve inviare e cosa accadrà se non riesce a completarlo. Una spiegazione chiara riduce la condivisione eccessiva accidentale e fa percepire un rifiuto come un controllo protettivo anziché come un vicolo cieco.

Un modello pratico è: classificare la richiesta, spiegare lo scopo, offrire il percorso appropriato, convalidare lo stato risultante, prendere la decisione autorizzata e registrare il minimo contesto operativo. Evita di rivelare dettagli protetti mentre il cliente sta ancora tentando la verifica.

Offri un’alternativa accessibile. L’autenticazione non deve rendere un test delle funzioni cognitive l’unico percorso disponibile. Le opzioni di assistenza e recupero devono essere disponibili in modo coerente nei percorsi WebChat, così che i clienti possano trovarle quando un tentativo non riesce.

• Usa un linguaggio semplice: “Per proteggere il tuo account, dobbiamo chiederti di usare il percorso di accesso sicuro all’account prima di poter discutere questo dettaglio.”
• Indica un divieto chiaro: “Non inviare qui la tua password né alcun codice di recupero dell’account.”
• Spiega l’alternativa: “Se non riesci ad accedere, scegli l’assistenza per l’accesso all’account o chiedi uno specialista dell’assistenza.”
• Mantieni, dove possibile, la stessa posizione e le stesse formulazioni dell’assistenza tra i vari punti di accesso.
• Conferma solo ciò che è sicuro confermare; non esporre dati dell’account mentre la decisione resta irrisolta.

Considera il contesto della messaggistica come contesto, non come prova di autorità

Un messaggio proveniente da una conversazione o da un numero di telefono familiare può essere un contesto utile, ma non è una prova sufficiente per una richiesta sensibile. Un dispositivo può essere condiviso, un messaggio può essere inoltrato, un numero di telefono può cambiare e l’accesso a una conversazione non stabilisce automaticamente l’autorità su un account o su un’azione.

Quando un cliente segnala un nuovo numero o la perdita dell’accesso, non aggiornare il dato sensibile dell’account solo in base alla richiesta in chat. Instrada il caso attraverso la procedura pertinente di modifica autenticata o di recupero. Allo stesso modo, non divulgare dettagli dell’account a qualcuno che può citare informazioni tratte da un messaggio inoltrato.

I rappresentanti di terze parti richiedono due decisioni: stabilire l’identità pertinente della persona o la relazione autenticata, quindi confermare le autorizzazioni applicabili all’azione precisa. Un’affermazione generica come “Gestisco questo account” non è una decisione di autorizzazione.

• Dispositivo condiviso: non dedurre il controllo esclusivo dell’account dalla conversazione aperta.
• Messaggio inoltrato: non trattare il contesto copiato come prova di autorizzazione.
• Nuovo numero di telefono: usa il percorso approvato di modifica o recupero prima di cambiare i dati di contatto.
• Rappresentante di terze parti: convalida la relazione pertinente e il permesso con privilegio minimo per la richiesta specifica.
• Relazione o autorità incerta: nega l’azione protetta ed effettua l’escalation.

Definisci aspettative specifiche per canale senza confondere il comportamento del canale con i controlli del team

WebChat e WhatsApp sono punti di accesso alla messaggistica, non una policy completa di autorizzazione. La tua organizzazione resta responsabile di definire quali richieste possono essere gestite in ciascun canale, quali prove sono accettate, come vengono trasferiti i casi sensibili e cosa il personale può divulgare o modificare.

Per le indicazioni su WhatsApp, ricorda ai clienti di non condividere credenziali o informazioni personali sensibili in risposta a richieste inattese. Si tratta di indicazioni per la sicurezza del cliente, non dell’affermazione che una conversazione di messaggistica da sola dimostri identità o autorità.

In webchat.vip, una casella di posta condivisa può aiutare i team a organizzare le conversazioni WebChat e WhatsApp tra operatori, reparti, instradamento, pianificazioni, livelli di servizio, modelli e tag. Configura questi strumenti operativi in base alla tua policy; non lasciare che un’etichetta di instradamento o un identificatore di canale sostituisca l’autenticazione o l’autorizzazione.

Ogni canale WebChat può utilizzare un widget installabile, personalizzabile e multilingue. Mantieni coerenti l’avviso di sicurezza, il percorso di assistenza accessibile e le formulazioni dell’escalation nelle lingue del widget, quindi convalida le traduzioni con la stessa cura riservata al percorso principale.

• Definisci limiti appropriati al canale per divulgazioni e modifiche.
• Mantieni separati il comportamento del canale controllato dal fornitore e le tue procedure di assistenza e i controlli dell’account.
• Usa modelli approvati per gli avvisi di non condividere segreti e le spiegazioni del percorso sicuro.
• Assicurati che l’opzione di escalation sia facile da individuare in ogni lingua supportata.
• Forma gli agenti affinché non improvvisino mai una verifica dell’identità più debole per comodità.