Quando interagisci con gli utenti tramite gli agenti di Business Messages, tieni presenti le seguenti best practice.
Non fornire o richiedere informazioni sensibili
Evitare contenuti sensibili durante le chat consente di proteggere le informazioni tue e dei tuoi clienti. Le informazioni sensibili includono, a titolo esemplificativo:
- Numeri di carte di credito
- Numeri di previdenza sociale, passaporto e altri documenti di identità ufficiali
- Credenziali di accesso, come le password
Rispondere rapidamente agli utenti
Tempi di risposta lenti o irragionevoli ai messaggi degli utenti creano un'esperienza negativa per i clienti. Assicurati di progettare l'infrastruttura di risposta in modo da fornire risposte tempestive e coerenti ai messaggi degli utenti.
Peggio di una risposta lenta è non ricevere alcuna risposta. Assicurati che gli utenti ricevano sempre risposte ai loro messaggi, indipendentemente dal carico di messaggi. Ad esempio, se il personale in tempo reale non è disponibile, invia un messaggio automatico di conferma all'utente e includi una stima di quando può aspettarsi una risposta completa.
Google misura il tempo di risposta (TTR) tra i messaggi. Se l'agente di un brand è lento a rispondere ai consumatori, Google rimuoverà i pulsanti di messaggistica del brand.
Quando l'automazione non riesce a soddisfare le richieste, la gestione viene trasferita a persone fisiche
Gli utenti si arrabbiano quando l'automazione non risponde correttamente. Ecco perché tutti gli agenti che vengono avviati da punti di contatto gestiti da Google (ad eccezione del punto di contatto Google Ads) devono avere rappresentanti umani che possono gestire le conversazioni quando l'automazione non è in grado di farlo. Prima del lancio, devi impostare il tipo di interazione con l'agente in modo da includere i rappresentanti umani.
Quando l'automazione non riesce a soddisfare la richiesta di un utente due volte di seguito, è meglio inviare un messaggio con un suggerimento per la richiesta di un agente in tempo reale.
Quando un utente tocca questo suggerimento, il tuo agente riceve un evento di richiesta di un agente in tempo reale. L'agente deve rispondere trasferendo la conversazione a un rappresentante umano, in modo che l'utente riceva l'aiuto di cui ha bisogno.
Le persone non devono essere disponibili 24 ore su 24, 7 giorni su 7. Imposta la disponibilità dell'agente in modo che gli utenti sappiano quando possono aspettarsi una risposta da un essere umano.
Autenticare gli utenti con OAuth
Per verificare le identità degli utenti e fornire loro informazioni personalizzate, effettua l'autenticazione degli utenti con i sistemi di backend tramite OAuth. L'autenticazione con OAuth consente agli agenti di accedere rapidamente ai dati utente e impedisce agli utenti o agli agenti di includere informazioni sensibili (come nomi utente o password) nella conversazione. Consulta Eseguire l'autenticazione con OAuth.
Misurare il CSAT in Business Messages
Business Messages misura i punteggi di soddisfazione del cliente (CSAT) con sondaggi direttamente all'interno delle esperienze di messaggistica. Per impedire agli utenti di ricevere più sondaggi, utilizza la funzionalità di sondaggio di Business Messages. Non implementare le tue tecniche di misurazione del CSAT.
Attieniti all'argomento
Non inviare messaggi indesiderati o non pertinenti alla conversazione in corso. Ad esempio,
- Messaggi relativi a un prodotto o servizio non correlato alla richiesta originale
- Messaggi ripetuti senza risposta dell'utente
- Messaggi troppo lunghi o l'uso eccessivo di emoji e URL
Utilizza l'ID luogo quando è disponibile
Per i punti di contatto basati sulla posizione, i messaggi possono contenere un placeId nel payload del contesto. Puoi utilizzarlo per fornire informazioni su ciò che l'utente potrebbe chiedere, ad esempio l'inventario in una determinata località. Un placeId
identifica in modo univoco un luogo nel database di Google Places e in
Google Maps Platform.
Anche se esegui il lancio solo con punti di contatto basati sulla posizione, assicurati di implementare una strategia per le situazioni in cui non è presente un placeId. Anche se
non è comune, esistono circostanze in cui un placeId, tra gli altri dati
contestuali, non viene passato all'webhook.
Implementare i nuovi tentativi con backoff esponenziale
Quando chiami qualsiasi API, è possibile che una chiamata non vada a buon fine a causa di problemi di infrastruttura, sovraccarico del servizio, limiti QPS e altri errori. Per recuperare in modo corretto dalle chiamate API non riuscite, implementa i nuovi tentativi con backoff esponenziale.
Con i nuovi tentativi con backoff esponenziale, l'infrastruttura si adegua automaticamente
- Identifica una chiamata API non riuscita
- Imposta la durata dell'attesa iniziale e il numero massimo di tentativi
- Mette in pausa per la durata dell'attesa
- Esegue di nuovo la chiamata API
Valuta la risposta della chiamata API:
- Se l'operazione è andata a buon fine, vai al passaggio successivo del flusso di lavoro
- In caso di errore, aumenta la durata dell'attesa e torna al passaggio 3
- Se si verifica un errore dopo il numero massimo di tentativi, viene attivato uno stato di errore
Le durate di attesa ideali e il numero massimo di tentativi ideali variano in base al caso d'uso. Determina questi numeri in base ai requisiti di latenza della tua infrastruttura e dei tuoi flussi di lavoro.
Controllare la presenza di messaggi in arrivo duplicati
Quando controlli e rispondi ai messaggi in arrivo dagli utenti, controlla il pulsante messageId e verifica di non aver già ricevuto e risposto al messaggio in precedenza.
Con i sistemi distribuiti, esistono due modi per inviare messaggi: al massimo una volta e almeno una volta. Con i sistemi "al massimo una volta", il sistema invia un messaggio una volta, ma se si verificano errori di rete o di comunicazione, il messaggio potrebbe non essere ricevuto. Con i sistemi "almeno una volta", il sistema potrebbe inviare un messaggio più volte, ma il messaggio può essere ricevuto anche in caso di errori di rete o di comunicazione.
Business Messages utilizza un sistema "almeno una volta". Sebbene ciò possa portare a duplicare i messaggi in arrivo, è facile deduplicare i messaggi monitorando le stringhe messageId. Se hai già ricevuto un messaggio, puoi tranquillamente ignorare eventuali messaggi aggiuntivi che ricevi con lo stesso messageId.