Fusion de conversations de messagerie Zendesk : un guide technique complet

Lorsque vos clients vous contactent via plusieurs canaux, ils s'attendent à ce que vous vous souveniez de qui ils sont. Mais dans Zendesk Messaging, les identités des utilisateurs peuvent se fragmenter. Un client peut commencer sur votre site Web, continuer sur WhatsApp et faire un suivi par courriel, créant ainsi trois profils d'utilisateurs distincts. C'est là que la fusion de conversations devient essentielle.

Comprendre comment Zendesk gère la fusion des utilisateurs et des conversations vous aide à créer une expérience de support transparente. Examinons comment le processus fonctionne, quand il se déclenche et ce que vous devez savoir pour le gérer efficacement.

Qu'est-ce que la fusion de conversations dans Zendesk Messaging ?

La fusion de conversations dans Zendesk Messaging est le processus de combinaison de profils d'utilisateurs distincts et de leurs historiques de conversation associés en un seul enregistrement unifié. C'est important, car sans une fusion appropriée, vos agents voient des interactions client fragmentées. Un client qui revient peut apparaître comme trois personnes différentes, ce qui oblige les agents à parcourir plusieurs tickets pour comprendre le contexte complet.

Il est important de distinguer deux concepts connexes :

La fusion d'utilisateurs combine deux profils d'utilisateurs en un seul. L'utilisateur « survivant » conserve l'identité fusionnée, tandis que l'utilisateur « supprimé » est supprimé. Toutes les données de profil, les métadonnées et les historiques de conversation sont transférés à l'utilisateur survivant.

La fusion de conversations fait spécifiquement référence à la combinaison de fils de conversation distincts en un seul historique. Cela se produit automatiquement dans certains scénarios, mais pas dans d'autres, selon votre configuration.

Le processus de fusion affecte plusieurs points de données. Lorsque les utilisateurs fusionnent, leurs informations de profil se combinent, les valeurs de l'utilisateur supprimé prévalant en cas de conflit. Les métadonnées fusionnent également, mais restent dans une limite de taille de 4 Ko. Les listes de clients et d'appareils sont dédupliquées et combinées. Plus important encore, les historiques de conversation fusionnent en un seul fil de discussion ou restent séparés, selon que vous avez activé ou non les multi-conversations.

Quand Zendesk fusionne-t-il les conversations ?

Les fusions ne se produisent pas au hasard. Zendesk les déclenche via trois mécanismes spécifiques, chacun servant des cas d'utilisation différents.

Fusions d'appels API

Parfois, vous devez combiner manuellement des utilisateurs. L'API Sunshine Conversations vous permet de déclencher des fusions par programme en spécifiant un ID d'utilisateur survivant et un ID d'utilisateur supprimé. Ceci est utile pour :

• Nettoyer les utilisateurs en double après les importations de données
• Corriger les problèmes d'identité découverts par votre équipe de support
• Mettre en œuvre une logique de fusion personnalisée basée sur vos règles métier

Voici un exemple de base de l'apparence d'un appel de fusion API :

POST /v1.1/apps/{app_id}/appusers/merge
{
  "surviving": {"_id": "user_a_id"},
  "discarded": {"_id": "user_b_id"}
}

Soyez prudent avec les fusions API sur les utilisateurs SDK. Si un utilisateur non authentifié fusionne avec un utilisateur authentifié, son jeton de session est révoqué. Il aura besoin d'un nouveau JWT pour continuer. Deux utilisateurs authentifiés qui fusionnent créent des complications avec les ID externes. Dans la plupart des cas, il est plus sûr de laisser Zendesk gérer automatiquement les fusions via l'authentification.

Fusions de transfert de canal

Les transferts de canal se produisent lorsque les clients souhaitent poursuivre les conversations sur différentes plateformes. Imaginez qu'un client commence à discuter sur votre widget de site Web, mais doit partir. Il choisit de continuer sur WhatsApp à la place. Ce transfert peut déclencher une fusion si Zendesk détermine que les deux identités représentent la même personne.

Ces fusions se produisent via deux flux :

Les transferts initiés par l'entreprise se produisent lorsque votre système propose de manière proactive le changement de canal. Par exemple, un client fournit son numéro de téléphone lors d'une discussion en ligne et vous proposez de continuer par SMS. Lorsque le client confirme la propriété de ce numéro de téléphone, Zendesk fusionne les profils d'utilisateurs Web et SMS.

Les transferts initiés par l'utilisateur se produisent lorsque les clients choisissent de poursuivre eux-mêmes les conversations. Un client qui discute sur votre site Web clique sur « Continuer sur Messenger », authentifie son compte Facebook et Zendesk reconnaît la connexion entre les deux sessions.

Fusions d'événements de connexion

Le déclencheur de fusion le plus courant est l'authentification. Lorsqu'un utilisateur non authentifié se connecte à votre application ou à votre site Web, et que cette connexion correspond à un profil d'utilisateur existant via un ID externe, Zendesk fusionne les profils.

Cela permet une continuité de conversation transparente. Un client peut parcourir votre site anonymement, démarrer une discussion de support, puis se connecter à son compte en milieu de conversation. Après l'authentification, il voit l'intégralité de son historique de conversation et tous les tickets précédents, le tout au même endroit.

L'utilisateur survivant dans les fusions de connexion est toujours l'utilisateur créé en premier. Cela préserve l'enregistrement d'utilisateur établi tout en incorporant les données de la session la plus récente et non authentifiée.

Comment fonctionne le processus de fusion

Comprendre les mécanismes vous aide à gérer les cas extrêmes et à créer des intégrations appropriées. Voici ce qui se passe étape par étape lorsque Zendesk fusionne des utilisateurs :

Étape 1 : Élection du survivant Avant toute chose, Zendesk détermine quel utilisateur survit. Pour les fusions API, vous le spécifiez. Pour les transferts de canal, l'utilisateur qui initie le transfert devient le survivant. Pour les événements de connexion, le compte d'utilisateur le plus ancien gagne.

Étape 2 : Consolidation du profil Les champs de profil de l'utilisateur supprimé fusionnent dans l'utilisateur survivant. Si les deux profils ont des valeurs conflictuelles pour le même champ (comme des noms différents), la valeur de l'utilisateur supprimé prévaut. Pour l'horodatage signedUpAt, la date la plus ancienne est conservée.

Étape 3 : Fusion des métadonnées Les métadonnées utilisateur se combinent, les valeurs supprimées remportant les conflits. Cependant, il existe une limite de 4 Ko sur la taille des métadonnées. Si les métadonnées fusionnées dépassent cette limite, Zendesk supprime les champs individuels un par un jusqu'à ce qu'ils correspondent. L'événement webhook vous indique quelles métadonnées ont été supprimées.

Étape 4 : Consolidation des clients et des appareils Les clients connectés (canaux de messagerie) et les appareils des deux utilisateurs fusionnent en une seule liste dédupliquée. L'utilisateur survivant a désormais accès à tous les canaux et appareils des deux utilisateurs d'origine.

Étape 5 : Gestion des conversations Cette étape varie considérablement en fonction de votre paramètre de multi-conversations. Avec les multi-conversations désactivées, les historiques de conversation fusionnent en un seul fil de discussion trié par horodatage. Avec les multi-conversations activées, les conversations restent séparées même après la fusion des utilisateurs.

Étape 6 : Notification Webhook Zendesk déclenche un webhook user:merge contenant les ID des objets survivants et supprimés, ainsi que toutes les métadonnées supprimées. Votre système doit écouter ces événements pour mettre à jour vos propres enregistrements d'utilisateurs en conséquence.

Comprendre les multi-conversations et la fusion

La fonctionnalité de multi-conversations modifie fondamentalement le fonctionnement de la fusion. Ce paramètre est irréversible, il est donc essentiel de comprendre ses implications avant de l'activer.

Sans multi-conversations (par défaut)

En mode de conversation unique, lorsqu'un utilisateur s'authentifie en milieu de conversation, les profils d'utilisateur ET leurs conversations fusionnent. La conversation non authentifiée rejoint l'historique de conversation de l'utilisateur authentifié sous la forme d'un fil de discussion continu. Cela crée une vue propre et linéaire de toutes les interactions client.

Avec les multi-conversations activées

Lorsque les multi-conversations sont actives, la fusion des utilisateurs se produit toujours, mais les conversations restent séparées. Le profil d'utilisateur authentifié absorbe le profil non authentifié, mais la conversation reste distincte. Cela peut créer des tickets en double pour le même problème sous-jacent.

Voici le risque : si un utilisateur démarre une conversation avant de se connecter, puis s'authentifie, vous vous retrouvez avec deux tickets pour ce qui devrait être une seule interaction de support. Vos agents doivent identifier et fusionner manuellement ces tickets.

Il existe également une limite de capacité. Bien que les utilisateurs non authentifiés puissent avoir un nombre illimité de tickets actifs, les utilisateurs authentifiés sont limités à 100 tickets actifs à la fois. Si un utilisateur authentifié dépasse cette limite, Zendesk hiérarchise les conversations qui affichent l'icône de coche verte en fonction de l'activité récente.

Meilleure pratique : Authentifier tôt

Pour éviter les scénarios de tickets en double, authentifiez les utilisateurs AVANT qu'ils ne commencent à envoyer des messages dans la mesure du possible. Si votre site Web ou votre application nécessite une connexion, déclenchez l'authentification immédiatement lorsque le widget de messagerie se charge, et non après le début de la conversation.

Authentification, identité et flux de courriel vérifié

L'un des principaux points faibles de Zendesk Messaging est la création d'utilisateurs en double. Pendant des années, les administrateurs ont eu du mal à ce que les utilisateurs authentifiés créent de nouveaux profils au lieu de se lier à ceux existants. Zendesk a résolu ce problème grâce à l'identité de courriel vérifiée.

Le problème : Risque d'identité non vérifiée

Auparavant, si un utilisateur non authentifié entrait une adresse courriel correspondant à un profil existant, Zendesk liait cette conversation à l'utilisateur existant. Cela créait une vulnérabilité de sécurité. N'importe qui pouvait se faire passer pour un autre client simplement en entrant son adresse courriel.

La solution : Identité de courriel vérifiée

Zendesk fait désormais la distinction entre les identités de courriel vérifiées et non vérifiées. Un courriel vérifié signifie que l'utilisateur s'est authentifié via JWT et a prouvé la propriété de cette adresse courriel. Les agents voient une coche verte à côté des utilisateurs vérifiés, ce qui indique qu'ils peuvent faire confiance à l'identité.

Les 48+ scénarios de flux simplifiés

Une analyse d'expert a cartographié environ 48 permutations de flux d'authentification différentes. Bien que la matrice complète soit complexe, la plupart des scénarios réels se résument à deux résultats :

Authentifié + Vérifié = Profil lié Lorsqu'un utilisateur s'authentifie via JWT avec un external_id correspondant à un utilisateur Zendesk existant, et que cet utilisateur a un courriel vérifié, la conversation est liée au profil existant. Les agents voient la coche verte et l'historique complet des conversations.

Tous les autres scénarios = Nouveau profil créé Les utilisateurs non authentifiés, ou les utilisateurs authentifiés sans external_ids correspondants, créent de nouveaux profils d'utilisateur. Ces profils n'ont pas l'état de vérification de la coche verte.

Options de configuration

Dans votre Centre d'administration sous Messagerie > Paramètres > Avancé, vous trouverez des options d'identité de courriel :

• « Utiliser uniquement les courriels vérifiés » (nouvelle valeur par défaut) : Sécurité maximale. Seuls les utilisateurs vérifiés et authentifiés se lient aux profils existants.
• « Utiliser les courriels vérifiés et non vérifiés » (comportement hérité) : Moins sécurisé, mais permet aux utilisateurs non authentifiés de se lier via la correspondance des courriels.

Les nouveaux comptes Zendesk sont par défaut l'option sécurisée. Les comptes existants peuvent nécessiter un ajustement manuel.

Meilleures pratiques pour la gestion des fusions de conversations

Après avoir examiné les détails techniques, voici des recommandations pratiques pour votre mise en œuvre :

Authentifiez-vous tôt et de manière cohérente. Déclenchez l'authentification JWT lorsque votre widget de messagerie s'initialise, et non après le début de la conversation. Cela empêche complètement le problème des tickets en double.

Gérez les webhooks user:merge. Créez une logique pour recevoir et traiter les événements de fusion. Mettez à jour vos enregistrements d'utilisateurs internes lorsque Zendesk vous informe d'une fusion pour maintenir la cohérence des données entre les systèmes.

Planifiez le nettoyage des doublons. Si vous utilisez les multi-conversations, formez les agents à identifier et à fusionner manuellement les tickets créés par une authentification retardée. Envisagez des règles d'automatisation pour aider à signaler les doublons potentiels.

Testez les flux de fusion dans la mise en scène. Avant de passer en direct, simulez des scénarios de fusion dans votre environnement de mise en scène. Vérifiez que l'authentification déclenche une liaison appropriée, que les transferts de canal fonctionnent correctement et que vos gestionnaires de webhook répondent correctement.

Documentez vos décisions d'authentification. La complexité des paramètres d'identité de courriel signifie que votre équipe a besoin d'une documentation claire sur la configuration que vous avez choisie et pourquoi. Incluez des étapes de dépannage pour les problèmes d'identité courants.

Envisagez des approches alternatives. Bien que Zendesk offre de puissantes capacités de fusion, certaines équipes constatent que les plateformes de support basées sur l'IA gèrent la résolution d'identité inter-canal de manière plus transparente. Des solutions comme eesel AI unifient automatiquement le contexte client sur tous les canaux sans nécessiter une logique de fusion complexe ou des implémentations JWT.

Mise en œuvre de la fusion de conversations dans votre configuration Zendesk

Prêt à mettre cela en pratique ? Voici votre liste de contrôle de mise en œuvre :

Avant d'activer les multi-conversations :

• Confirmez que votre flux d'authentification fonctionne correctement
• Vérifiez que les jetons JWT incluent external_id correspondant à votre base de données d'utilisateurs
• Testez l'expérience utilisateur avec des scénarios d'authentification retardée
• Documentez la décision (rappelez-vous : vous ne pouvez pas revenir en arrière)

Liste de contrôle d'intégration API :

• Mettez en œuvre le gestionnaire de webhook user:merge
• Créez une logique pour interroger les utilisateurs existants avant d'en créer de nouveaux
• Ajoutez une surveillance pour les erreurs liées à la fusion

Pièges courants à éviter :

• Ne vous fiez pas uniquement à la correspondance des courriels pour l'identité (risque de sécurité)
• N'authentifiez pas les utilisateurs en milieu de conversation sans comprendre les implications sur les tickets
• N'ignorez pas la limite de métadonnées de 4 Ko lors des fusions
• N'oubliez pas de mettre à jour vos propres systèmes lorsque des fusions se produisent

Ressources pour en savoir plus :

• Documentation du développeur Zendesk pour la fusion d'utilisateurs
• Authentification des utilisateurs dans votre application
• Guide de configuration des multi-conversations