Lorsque vous interagissez avec des utilisateurs via des agents Business Messages, tenez compte des bonnes pratiques suivantes.
Ne pas fournir ni demander d'informations sensibles
En évitant les contenus sensibles pendant les discussions, vous protégez aussi bien vos informations que celles de vos clients. Les informations sensibles incluent, sans s'y limiter :
- Numéros de cartes de crédit
- Numéros de sécurité sociale ou de passeport, ou autres identifiants émis par l'administration publique
- Identifiants de connexion, comme les mots de passe
Répondez rapidement aux utilisateurs
Des temps de réponse trop longs ou déraisonnables pour les messages des utilisateurs peuvent nuire à l'expérience utilisateur. Assurez-vous de concevoir votre infrastructure de réponse de manière à fournir des réponses rapides aux messages des utilisateurs.
Pire encore qu'une réponse lente, il n'y a aucune réponse. Assurez-vous que les utilisateurs reçoivent toujours des réponses à leurs messages, quelle que soit leur charge. Par exemple, si le personnel en direct n'est pas disponible, envoyez un message automatisé accusant réception de l'utilisateur et incluez une estimation du moment où l'utilisateur peut s'attendre à une réponse complète.
Google mesure le délai de réponse entre les messages. Si l'agent d'une marque met du temps à répondre aux consommateurs, Google supprimera les boutons de messagerie de la marque.
Lorsque l'automatisation ne peut pas répondre aux demandes, vous devez les confier à des humains
Les utilisateurs sont mécontents lorsque l'automatisation ne leur répond pas correctement. C'est pourquoi tous les agents qui se lancent depuis des points d'entrée gérés par Google (à l'exception du point d'entrée Google Ads) doivent avoir des représentants humains capables de gérer les conversations lorsque l'automatisation ne le peut pas. Avant le lancement, vous devez définir votre type d'interaction avec l'agent afin d'inclure les représentants humains.
Lorsque l'automatisation ne peut pas répondre à la requête d'un utilisateur deux fois de suite, il est préférable d'envoyer un message incluant une suggestion de demande d'agent en direct.
Lorsqu'un utilisateur appuie sur cette suggestion, votre agent reçoit un événement demandé en direct par l'agent. Votre agent doit répondre en transmettant la conversation à un représentant humain, afin que l'utilisateur obtienne l'aide dont il a besoin.
Les humains n'ont pas besoin d'être disponibles 24h/24, 7j/7. Définissez la disponibilité de l'agent pour que les utilisateurs sachent quand ils peuvent s'attendre à une réponse humaine.
Authentifier les utilisateurs avec OAuth
Pour valider l'identité des utilisateurs et leur fournir des informations personnalisées, authentifiez les utilisateurs avec des systèmes backend via OAuth. L'authentification avec OAuth permet aux agents d'accéder rapidement aux données utilisateur et empêche les utilisateurs ou les agents d'inclure des informations sensibles (telles que des noms d'utilisateur ou des mots de passe) dans la conversation. Consultez la page S'authentifier avec OAuth.
Mesurer la satisfaction client dans Business Messages
Business Messages mesure les scores de satisfaction des clients (CSAT) à l'aide d'enquêtes directement dans les messages. Pour empêcher les utilisateurs de recevoir plusieurs enquêtes, utilisez la fonctionnalité d'enquête de Business Messages. N'implémentez pas vos propres techniques de mesure CSAT.
Restez dans le sujet
N'envoyez pas de messages indésirables ou non pertinents pour la conversation en cours. Par exemple :
- Messages concernant un produit ou service sans rapport avec la demande initiale
- Messages répétés sans réponse de l'utilisateur
- Messages trop longs ou utilisation excessive d'emoji et d'URL
Utiliser l'ID de lieu lorsqu'il est disponible
Pour les points d'entrée basés sur l'emplacement, les messages peuvent contenir un placeId dans la charge utile contextuelle. Vous pouvez l'utiliser pour fournir des informations que l'utilisateur peut poser, comme l'inventaire à un emplacement particulier. Un placeId identifie de manière unique un lieu dans la base de données Google Places et Google Maps Platform.
Même si vous ne lancez qu'avec des points d'entrée basés sur la localisation, veillez à mettre en œuvre une stratégie dans les cas où placeId n'est pas présent. Bien que cela ne soit pas courant, il existe des cas où une erreur placeId, entre autres données contextuelles, n'est pas transmise à votre webhook.
Implémenter des tentatives avec un intervalle exponentiel entre les tentatives
Lorsque vous appelez une API, il est possible qu'un appel échoue en raison de problèmes d'infrastructure, de surcharge du service, de limites de RPS et d'autres erreurs. Pour récupérer de manière optimale les appels d'API ayant échoué, implémentez les tentatives avec un intervalle exponentiel entre les tentatives.
Grâce à un intervalle exponentiel entre les tentatives, votre infrastructure est automatiquement
- Identifie un échec d'appel d'API
- Définit la durée d'attente initiale et le nombre maximal de tentatives
- Suspendu pendant la durée d'attente
- Nouvelle tentative d'appel d'API
Évalue la réponse d'appel d'API:
- Si l'opération réussit, passez à l'étape suivante du workflow
- En cas d'échec, cela augmente la durée d'attente et revient à l'étape 3
- En cas d'échec après le nombre maximal de tentatives, passe à l'état "Échec"
Les durées d'attente idéales et le nombre maximal de tentatives idéal dépendent du cas d'utilisation. Déterminez ces chiffres en fonction des exigences de latence de votre infrastructure et de vos workflows.
Rechercher les messages entrants en double
Lorsque vous vérifiez les messages entrants des utilisateurs et que vous y répondez, vérifiez le champ messageId et vérifiez que vous n'avez pas encore reçu de message ou y avez répondu.
Avec les systèmes distribués, il existe deux façons d'envoyer des messages: au moins une fois et au moins une fois. Avec le système "une seule fois", le système envoie un message une fois, mais en cas d'erreur de réseau ou de communication, le message risque de ne pas être reçu. Avec les systèmes "au moins une fois", le système peut envoyer un message plusieurs fois, mais il peut être reçu même en cas d'erreurs de réseau ou de communication.
Business Messages utilise un système "au moins une fois". Bien que cela puisse entraîner la duplication de messages entrants, il est facile de supprimer les messages en double en suivant les chaînes messageId. Si vous avez déjà reçu un message, vous pouvez ignorer les messages supplémentaires que vous recevez avec le même messageId.