Lorsque vous interagissez avec les utilisateurs via des agents Business Messages, tenez compte des bonnes pratiques suivantes.
Ne fournissez ni ne demandez pas d'informations sensibles
Évitez d'aborder des sujets sensibles pendant les discussions par chat. La sécurité de vos informations et de celles de vos clients sera ainsi assurée. 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
- les identifiants de connexion, comme les mots de passe ;
Répondre rapidement aux utilisateurs
Des délais de réponse lents ou déraisonnables aux messages des utilisateurs nuisent à l'expérience de vos clients. Veillez à concevoir votre infrastructure de réponse pour qu'elle fournisse systématiquement des réponses rapides aux messages des utilisateurs.
Pire encore qu'une réponse lente, il n'y a pas de réponse du tout. Assurez-vous que les utilisateurs reçoivent toujours des réponses à leurs messages, quelle que soit la charge de messages. Par exemple, si l'équipe en direct n'est pas disponible, envoyez un message automatique pour confirmer la demande de l'utilisateur et indiquez-lui quand il peut s'attendre à une réponse complète.
Google mesure le temps de réponse (TTR) entre les messages. Si les agents d'une marque tardent à répondre aux consommateurs, Google supprime les boutons de messagerie de la marque.
Lorsque l'automatisation ne peut pas traiter les demandes, les transmettre à des humains
Les utilisateurs sont frustrés lorsque l'automatisation ne répond pas correctement à leurs demandes. C'est pourquoi tous les agents qui lancent des conversations à partir de points d'entrée gérés par Google (à l'exception du point d'entrée Google Ads) doivent disposer de représentants humains capables de gérer les conversations lorsque l'automatisation ne le peut pas. Avant de lancer votre agent, vous devez définir le type d'interaction de l'agent pour inclure des représentants humains.
Lorsque l'automatisation ne peut pas traiter la demande d'un utilisateur deux fois de suite, il est préférable d'envoyer un message contenant une suggestion de demande à un agent en direct.
Lorsqu'un utilisateur appuie sur cette suggestion, votre agent reçoit un événement "Agent en direct demandé". 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 vos agents 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 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 section S'authentifier avec OAuth.
Mesurer le CSAT dans Business Messages
Business Messages mesure le score de satisfaction client (CSAT) à l'aide d'enquêtes directement dans l'interface de messagerie. Pour éviter que les utilisateurs ne reçoivent plusieurs enquêtes, utilisez la fonctionnalité d'enquête de Business Messages. N'implémentez pas vos propres techniques de mesure du CSAT.
Rester sur ce sujet
N'envoyez pas de messages indésirables ou non pertinents par rapport à la conversation en cours. Par exemple,
- Messages concernant un produit ou un service non liés à la demande initiale
- Messages répétés sans réponse de l'utilisateur
- Messages excessivement 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 la position, les messages peuvent contenir un placeId dans la charge utile de contexte. Vous pouvez l'utiliser pour fournir des informations que l'utilisateur peut demander, comme l'inventaire d'un magasin spécifique. Un placeId identifie de façon unique un lieu dans la base de données Google Adresses et dans Google Maps Platform.
Même si vous ne lancez que des points d'entrée basés sur la localisation, veillez à implémenter une stratégie pour les situations où un placeId n'est pas présent. Bien que cela ne soit pas courant, il arrive qu'un placeId, parmi d'autres données contextuelles, ne soit pas transmis à votre webhook.
Implémenter des nouvelles tentatives avec un intervalle exponentiel entre les tentatives
Lorsqu'une API est appelée, il est possible qu'un appel échoue en raison de problèmes d'infrastructure, d'une surcharge de service, de limites de RPS et d'autres erreurs. Pour récupérer correctement après un échec d'appel d'API, implémentez des nouvelles tentatives avec un intervalle exponentiel entre les tentatives.
Avec les tentatives avec intervalle exponentiel entre les tentatives, votre infrastructure
- Identifie un appel d'API ayant échoué
- Définit la durée d'attente initiale et le nombre maximal de tentatives
- Met en pause pendant la durée d'attente
- Réessaie l'appel d'API
Évalue la réponse de l'appel d'API:
- Si l'opération réussit, passe à l'étape suivante du workflow
- En cas d'échec, 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 "fail" (échec)
Les durées d'attente et le nombre maximal de nouvelles tentatives idéaux varient en fonction 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 recherchez et répondez aux messages entrants des utilisateurs, vérifiez la valeur messageId et assurez-vous que vous n'avez pas déjà reçu et répondu au message précédemment.
Avec les systèmes distribués, il existe deux façons d'envoyer des messages: au plus une fois et au moins une fois. Avec les systèmes "au plus une fois", le système envoie un message une seule fois, mais en cas d'erreurs 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 le message peut être reçu même en cas d'erreurs réseau ou de communication.
Business Messages utilise un système "au moins une fois". Bien que cela puisse entraîner la duplication des messages entrants, il est facile de dédupliquer les messages 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.