Comment configurer le transfert de Zendesk du chat vers l'e-mail

Lorsqu'un client démarre une conversation dans votre widget de chat Zendesk mais doit s'absenter, la transition vers l'e-mail doit se faire en douceur. Un transfert maladroit frustre les clients et crée un travail supplémentaire pour les agents qui doivent reconstituer des conversations fragmentées. Bien fait, le transfert Zendesk du chat vers l'e-mail préserve le contexte, maintient le fil de conversation et maintient les temps de résolution bas.

Ce guide explique exactement comment configurer la fonctionnalité de conversations continues de Zendesk, de la configuration de base aux contrôles de synchronisation avancés. Que vous configuriez des transitions chat-vers-e-mail pour la première fois ou que vous résolviez les problèmes pour lesquels les clients ne peuvent pas démarrer de nouvelles conversations, vous trouverez des instructions étape par étape qui fonctionnent pour votre niveau Zendesk.

Qu'est-ce que le transfert Zendesk du chat vers l'e-mail ?

Avant de plonger dans la configuration, clarifions ce que nous configurons réellement. Zendesk utilise le terme « conversations continues » pour le flux de travail chat-vers-e-mail. C'est différent du transfert d'une conversation à un agent en direct (bien que les deux puissent fonctionner ensemble).

Les conversations continues permettent aux clients qui abandonnent un chat de messagerie de recevoir des notifications par e-mail lorsque les agents répondent. Le client peut alors poursuivre la conversation en répondant à l'e-mail ou en revenant au widget du site web. L'historique complet de la conversation reste intact quel que soit le canal utilisé.

C'est important car le comportement du client est imprévisible. Quelqu'un peut démarrer un chat pendant sa pause déjeuner, être appelé à une réunion et préférer continuer par e-mail plus tard. Sans les conversations continues activées, cette conversation reste non lue jusqu'à ce que le client revienne sur votre site web, ou pire, se perde complètement.

La fonctionnalité est distincte du transfert d'agent en direct, qui transfère le contrôle d'un agent IA à un agent humain au sein de la même session de chat. Vous pouvez utiliser les deux : un agent IA gère le triage initial, passe à un humain si nécessaire, et si le client part, les conversations continues prennent le relais pour maintenir le fil actif par e-mail.

Prérequis pour le transfert Zendesk du chat vers l'e-mail

Avant de pouvoir activer les conversations continues, votre compte Zendesk doit répondre à plusieurs exigences :

• Zendesk Suite OU Support + Chat (plan Team ou supérieur). La fonctionnalité n'est pas disponible sur les plans Support autonomes sans Chat.
• Agent Workspace activé. Il s'agit de l'interface Zendesk moderne qui unifie le chat et la billetterie. Si vous utilisez toujours le tableau de bord Chat classique, vous devrez d'abord migrer.
• Au moins un agent avec accès à Chat. Quelqu'un doit être disponible pour répondre lorsque les conversations arrivent.
• Une adresse e-mail de support configurée. C'est l'adresse qui envoie les notifications de conversation continue aux clients.
• Implémentation du widget Web. Les conversations continues ne fonctionnent que via le widget Web. Elles ne sont pas disponibles sur les implémentations SDK mobiles.

Si l'un de ces éléments vous manque, l'option de conversations continues n'apparaîtra tout simplement pas dans votre Centre d'administration, ou la fonctionnalité ne fonctionnera pas correctement.

Étape par étape : Configuration des conversations continues

Étape 1 : Activer les conversations continues dans le Centre d'administration

Commencez par accéder à Centre d'administration > Objets et règles > Tickets > Paramètres. Faites défiler vers le bas pour trouver la section Conversations continues et développez-la.

Cochez la case intitulée « Basculer les conversations de messagerie vers l'e-mail. » Cela active la fonctionnalité principale.

Lorsque vous enregistrez ce paramètre, Zendesk crée automatiquement un déclencheur appelé « Demander un e-mail pour les conversations continues. » Ce déclencheur s'exécute après qu'une conversation est restée inactive pendant 5 secondes et demande l'adresse e-mail du client si elle n'a pas encore été collectée.

Étape 2 : Configurer le déclencheur de demande d'e-mail

Le déclencheur créé automatiquement gère la plupart des cas d'utilisation, mais vous devez l'examiner et le personnaliser pour qu'il corresponde à votre flux de travail.

Accédez à Centre d'administration > Objets et règles > Règles métier > Déclencheurs de messagerie et ouvrez le déclencheur « Demander un e-mail pour les conversations continues ».

Examinez ces paramètres clés :

• Conditions : Par défaut, il se déclenche lorsqu'une conversation est inactive pendant 5 secondes et que l'e-mail du client est inconnu. Vous pouvez ajuster le délai ou ajouter des conditions en fonction de vos heures d'ouverture.
• Actions : Le déclencheur envoie un message demandant l'e-mail du client. Personnalisez ce message pour qu'il corresponde à la voix de votre marque.

Si vous collectez déjà des adresses e-mail au début des conversations (via un formulaire de pré-chat, par exemple), vous pouvez désactiver ce déclencheur pour éviter de demander l'e-mail deux fois.

Étape 3 : Personnaliser le modèle de notification par e-mail

Les e-mails de conversation continue utilisent votre modèle de notification par e-mail Zendesk standard. Ils comprennent :

• Le nombre de messages d'agent non lus
• Un extrait de la conversation
• Des instructions pour continuer par e-mail ou revenir sur le site web

Pour examiner ou personnaliser votre modèle, accédez à Centre d'administration > Canaux > E-mail > Modèles d'e-mail. La fonctionnalité de conversations continues extrait le format de votre notification par e-mail de compte Support.

Si vous avez considérablement personnalisé votre modèle d'e-mail, testez la façon dont les e-mails de conversation continue s'affichent. Le modèle est localisé et traduit en fonction de la langue du profil de l'utilisateur dans Support.

Étape 4 : Tester le flux de travail

Avant de passer en direct, effectuez un test complet :

1. Ouvrez votre site web et démarrez une conversation dans le widget Web
2. Envoyez un message, puis fermez le navigateur ou quittez la page (simulant un abandon)
3. Demandez à un agent de répondre à la conversation depuis l'Agent Workspace
4. Attendez le seuil d'inactivité (par défaut : conversation considérée comme inactive avec des messages non lus)
5. Vérifiez que la notification par e-mail arrive avec le contenu correct
6. Répondez à l'e-mail et vérifiez que la réponse apparaît dans le ticket Zendesk
7. Revenez au widget du site web et confirmez que vous pouvez également y poursuivre la conversation

Testez les deux chemins : réponse par e-mail et retour au widget. Les deux doivent conserver le fil de conversation complet.

Gérer le timing du transfert et le statut du ticket

C'est là que la plupart des équipes rencontrent des problèmes. Le cycle de vie par défaut des tickets de Zendesk crée un écart qui déroute les clients.

Lorsqu'un agent résout un ticket, Zendesk attend 4 jours par défaut avant de changer le statut en Fermé. Pendant ces 4 jours, si le client revient sur votre widget de messagerie, il ne peut pas démarrer une nouvelle conversation. Son message est ajouté au ticket existant à la place, et l'agent précédent reste affecté.

Cela pose deux problèmes :

1. Les clients ne peuvent pas signaler de nouveaux problèmes car ils sont bloqués dans un ancien fil de conversation
2. Le contexte devient confus lorsque de nouveaux problèmes se mélangent à ceux qui sont résolus

Ajuster le timing de résolu à fermé

Vous avez deux options pour résoudre ce problème :

Option 1 : Modifier l'automatisation par défaut

Zendesk inclut une automatisation appelée « Fermer le ticket 4 jours après que le statut est défini sur résolu. » Vous pouvez réduire ce délai :

1. Accédez à Centre d'administration > Objets et règles > Automatisations
2. Trouvez et modifiez l'automatisation de fermeture par défaut
3. Modifiez la condition de temps de 4 jours à la durée de votre choix (aussi courte que 1 heure, aussi longue que 28 jours)
4. Enregistrez et testez

Option 2 : Créer un déclencheur de fermeture immédiate

Pour plus de contrôle, créez un déclencheur qui ferme les tickets immédiatement lorsqu'ils sont étiquetés :

• Condition : Balises | Contient au moins l'une des suivantes | close
• Action : Statut | Fermé

Ensuite, ajoutez la balise close via une macro ou une automatisation lors de la résolution des tickets qui sont passés par la messagerie.

Une mise en garde importante : si vous utilisez des enquêtes CSAT, ne fermez pas les tickets immédiatement. L'enquête est envoyée lorsque le ticket est marqué comme Résolu, donc une fermeture trop rapide peut interférer avec l'expérience de l'enquête. La plupart des équipes trouvent qu'une mémoire tampon de 1 à 4 heures fonctionne bien.

Préserver le contexte lors du transfert Zendesk du chat vers l'e-mail

Rien ne frustre plus les clients que de répéter des informations qu'ils ont déjà partagées. Voici comment vous assurer que le contexte survit à la transition de canal.

Zendesk joint automatiquement la transcription complète de la conversation au ticket. Les agents voient tout ce que le client a dit dans le chat, y compris son interaction avec tout agent IA. Mais les transcriptions brutes peuvent être longues, et les agents occupés ne les lisent pas toujours attentivement.

Pour transmettre un contexte structuré :

Les champs de ticket personnalisés vous permettent de capturer des points de données spécifiques pendant la conversation. Si vous utilisez des agents IA Zendesk avec le générateur de dialogue, ajoutez des étapes « Demander des détails » qui correspondent à des champs de ticket comme le numéro de commande, la catégorie de produit ou le type de problème. Ceux-ci apparaissent en évidence dans la barre latérale du ticket.

Le transfert de métadonnées gère les données techniques comme les ID de compte ou les informations de session. Cela nécessite du code dans votre widget Web pour transmettre des données personnalisées dans le ticket. C'est plus de travail à configurer, mais précieux pour le commerce électronique ou le support SaaS où vous devez référencer des enregistrements spécifiques.

Les notes internes peuvent inclure des résumés générés par l'IA. Certaines équipes configurent leur agent IA pour qu'il rédige un bref résumé du problème du client avant tout transfert. Cela donne aux agents le « TL ;DR » sans avoir à fouiller dans les transcriptions.

L'objectif est simple : les agents doivent savoir ce dont le client a besoin quelques secondes après l'ouverture du ticket. S'ils doivent demander au client de répéter des informations, vous avez perdu les gains d'efficacité que l'automatisation était censée fournir.

Résoudre les problèmes courants de transfert Zendesk du chat vers l'e-mail

Problème : Les tickets reviennent par défaut au canal de messagerie

C'est un point sensible connu que Zendesk a reconnu. Lorsqu'un ticket qui a commencé comme Messagerie est rouvert, il revient par défaut au canal de Messagerie même si la dernière interaction était un e-mail.

Le résultat ? Les agents cliquent sur « envoyer » en pensant qu'ils envoient un e-mail à un client, mais ils ont en fait envoyé un message de chat. C'est particulièrement frustrant lorsque le client n'est pas en ligne pour le recevoir.

Selon un chef de produit Zendesk, c'est le comportement attendu et il n'y a pas de plans immédiats pour le changer. Cependant, la communauté s'est exprimée sur le problème :

C'est très gênant qu'il y ait un ticket de messagerie entrant et que nous changions le canal en e-mail pour résoudre le ticket. Mais si le ticket est rouvert, le canal revient à la messagerie. Cela n'a aucun sens.

Communauté Zendesk

Solutions de contournement :

• Former les agents à toujours vérifier le sélecteur de canal avant d'envoyer
• Créer des déclencheurs qui étiquettent les tickets lorsque le canal change, alertant les agents de vérifier
• Utiliser des notes internes pour documenter quand une conversation est passée à l'e-mail

Problème : Les clients ne peuvent pas démarrer de nouvelles conversations

Symptôme : Un client revient sur le widget de messagerie, mais sa conversation précédente se rouvre au lieu de démarrer une nouvelle.

Cause : Le statut du ticket est Résolu, pas Fermé. Tant qu'il n'est pas Fermé, le client ne peut pas démarrer une nouvelle conversation.

Solution : Réduisez le délai de Résolu à Fermé en utilisant les méthodes d'automatisation ou de déclencheur décrites précédemment. Pour la plupart des équipes, une mémoire tampon de 1 à 4 heures offre suffisamment de temps pour les enquêtes CSAT sans causer de confusion chez les clients.

Problème : Les notifications par e-mail ne sont pas envoyées

Si les e-mails de conversation continue n'atteignent pas les clients :

1. Vérifiez que votre adresse e-mail de support est correctement configurée dans Centre d'administration > Canaux > E-mail
2. Vérifiez que le déclencheur « Demander un e-mail pour les conversations continues » est actif
3. Examinez votre dossier de spam et les paramètres de délivrabilité des e-mails
4. Confirmez que le statut du ticket n'est pas déjà Fermé (les e-mails ne sont pas envoyés pour les tickets fermés)
5. Vérifiez que la conversation était bien inactive avec des messages non lus lorsque l'agent a répondu

Approches alternatives pour le transfert chat-vers-e-mail

Bien que les conversations continues natives de Zendesk fonctionnent pour de nombreuses équipes, ce n'est pas la seule option. Les plateformes de chatbot tierces offrent différentes approches au même problème.

Ada fournit des blocs de transfert d'e-mail qui créent des tickets Zendesk tout en maintenant la continuité du fil. Leur connecteur SMTP permet aux agents humains de répondre depuis la même adresse e-mail que l'agent IA, gardant tout dans un seul fil.

Botsonic offre une intégration plus simple axée sur le transfert d'agent en direct plutôt que sur la continuation asynchrone par e-mail. C'est plus facile à configurer, mais cela ne résout pas le cas d'utilisation « le client est parti et doit continuer plus tard » aussi élégamment.

Deepconverse cible Zendesk Chat Classic avec des transferts basés sur des widgets. C'est utile si vous n'avez pas encore migré vers Agent Workspace, bien que Chat Classic soit en cours de suppression progressive.

Le compromis avec les solutions tierces est la complexité. Vous gagnez en flexibilité, mais vous ajoutez un autre système à gérer, une autre intégration à maintenir et un autre point de défaillance potentiel.

Si la configuration native de Zendesk vous semble limitative ou si la complexité du générateur de dialogue vous ralentit, nous offrons une approche plus simple. Chez eesel AI, nous nous intégrons directement à Zendesk et vous laissons définir des règles d'escalade en langage clair au lieu de faire glisser des blocs dans un générateur visuel. Vous pouvez également exécuter des simulations sur vos tickets historiques avant de passer en direct pour voir exactement comment les transferts fonctionneraient.

Commencez à gérer le transfert Zendesk du chat vers l'e-mail en douceur

Bien gérer les transferts chat-vers-e-mail est plus important que la plupart des équipes ne le réalisent. C'est la différence entre les clients qui ont l'impression que vous comprenez leur parcours et ceux qui ont l'impression de recommencer à chaque fois qu'ils changent de canal.

Les points clés à retenir :

• Activez les conversations continues dans le Centre d'administration pour activer les notifications par e-mail
• Ajustez le timing de Résolu à Fermé pour éviter que les clients ne restent bloqués dans d'anciennes conversations
• Préservez le contexte grâce à des champs personnalisés, des métadonnées et des notes internes afin que les agents ne demandent jamais aux clients de se répéter
• Formez les agents sur la particularité de la persistance du canal afin qu'ils n'envoient pas accidentellement des messages de chat alors qu'ils veulent envoyer un e-mail

Si vous trouvez le générateur de dialogue Zendesk complexe pour vos besoins d'escalade, ou si vous voulez tester des scénarios de transfert avant de passer en direct, nous pouvons vous aider. Nous gérons le transfert avec des règles en langage clair, apprenons de vos tickets et documents existants, et vous laissons simuler par rapport aux données historiques avant que les clients ne les voient.

Prochaines étapes :

• Vérifiez votre configuration actuelle des conversations continues et les paramètres de timing
• Testez le flux de travail complet du début du chat à la réponse par e-mail pour vous assurer que le contexte circule correctement
• Examinez le matériel de formation des agents pour inclure le comportement de changement de canal
• Déterminez si la complexité de votre escalade justifie une approche plus simple