Deskhero
Français
Essayer gratuitement

← Back to articles

Comment préserver les fils d’e-mails lorsque les e-mails deviennent des tickets

Comment préserver les fils d’e-mails lorsque les e-mails deviennent des tickets

Conserver une conversation par e-mail après sa conversion en ticket dépend des règles de regroupement utilisées par le service d'assistance. Les signaux courants incluent les en-têtes Message-ID, In-Reply-To et References. Certaines plateformes utilisent également un identifiant de ticket ou un autre identifiant dans le corps du message ou l'adresse de réception.

Utilisez cette liste de contrôle avant de vous fier à un nouveau canal e-mail :

  • Connectez l'adresse d'assistance à l'aide d'une méthode officiellement prise en charge par le service d'assistance.
  • Envoyez un ticket de test et répondez-y via le même itinéraire que celui qu'utiliseront les clients.
  • Comparez les en-têtes du message d'origine et de la réponse, puis vérifiez que la réponse apparaît dans le ticket existant.

Si le test crée un nouveau ticket, consultez les règles de regroupement documentées par le service d'assistance avant de modifier le routage des e-mails. Chaque plateforme peut combiner différemment les en-têtes, les identifiants de ticket et les vérifications de l'expéditeur.

Points clés à retenir

Le regroupement des e-mails ne repose pas uniquement sur les lignes d'objet. Les services d'assistance examinent généralement les en-têtes de réponse standard et peuvent utiliser leurs propres identifiants de ticket comme signaux de correspondance supplémentaires.

Point Détails
Les en-têtes relient les réponses In-Reply-To et References font référence aux identifiants de message de la conversation existante.
Les règles varient selon la plateforme Un service d'assistance peut également examiner un identifiant de ticket, un identifiant masqué, une adresse de réception ou l'expéditeur.
Utilisez des connexions prises en charge Suivez la configuration de boîte aux lettres documentée par votre service d'assistance et votre fournisseur d'e-mail.
Testez l'itinéraire réel Répondez en tant que client et vérifiez que le message est ajouté au ticket d'origine.
Options de boîte aux lettres Deskhero Deskhero prend en charge les connexions bidirectionnelles aux boîtes aux lettres Google et Microsoft, ainsi que le transfert de domaine avec envoi authentifié.

Sommaire

Quels en-têtes préservent réellement les conversations par e-mail

Un e-mail possède normalement un Message-ID. Une réponse peut contenir une valeur In-Reply-To qui pointe vers le message auquel elle répond, ainsi qu'une valeur References listant les identifiants des messages précédents. Un service d'assistance peut utiliser ces relations pour associer les messages à une conversation. La documentation d'Amazon Connect décrit les conversations chronologiques ainsi que les structures arborescentes créées lorsqu'une personne répond à un message plus ancien.

Les plateformes peuvent ajouter leurs propres méthodes de correspondance. Zendesk documente trois vérifications : les éléments des en-têtes, un identifiant encodé dans le corps du message et un identifiant encodé dans une adresse de réception Zendesk. Il s'agit de règles propres à Zendesk, et non d'un modèle pouvant être copié dans tous les services d'assistance.

Le regroupement est important, car séparer une réponse de ses messages précédents rend l'historique d'assistance plus difficile à suivre :

  • Les utilisateurs peuvent devoir rechercher un autre ticket pour retrouver des pièces jointes ou des décisions antérieures.
  • Les destinataires et les réponses précédentes peuvent être séparés de la question la plus récente.
  • Deux utilisateurs peuvent répondre à des messages associés sans se rendre compte qu'ils appartiennent à une seule conversation.

La documentation e-mail de Freshdesk présente une autre approche propre à une plateforme. Elle vérifie un identifiant de ticket, un identifiant de message ou un identifiant unique, puis effectue une vérification de l'expéditeur. La leçon pratique consiste à déterminer quels signaux votre propre service d'assistance utilise et à préserver ces signaux tout au long de l'itinéraire réel des e-mails.

Configurer vos serveurs de messagerie pour préserver les conversations

Une configuration fiable commence par la méthode de connexion prise en charge par le service d'assistance. Évitez de supposer qu'un relais SMTP, une règle de transfert ou une synchronisation de boîte aux lettres se comporte de la même manière selon les produits.

  1. Choisissez la connexion de boîte aux lettres documentée. Si le service d'assistance propose une connexion directe à Google ou Microsoft, suivez son processus d'autorisation. S'il exige un transfert, utilisez exactement la destination et les enregistrements DNS fournis par le produit.
  2. Configurez le transfert pour l'adresse prévue. Le guide de transfert Google Workspace de Deskhero explique comment créer un groupe et ajouter l'adresse de destination Deskhero en tant que membre. Microsoft 365 et les autres fournisseurs proposent des procédures de configuration différentes.
  3. Conservez les identifiants de la plateforme. Si votre service d'assistance ajoute un marqueur de ticket à une notification sortante, ne le supprimez pas du modèle, sauf si la documentation du produit indique qu'il est facultatif. Freshdesk recommande d'inclure son format d'identifiant de ticket, tandis que Zendesk ajoute par défaut un identifiant encodé aux notifications sortantes.
  4. Examinez les systèmes qui transforment les e-mails. Les règles de routage, les listes de diffusion et les passerelles peuvent modifier un message avant sa réception par le service d'assistance. Comparez la source brute à chaque étape disponible au lieu de deviner où une valeur a changé.
  5. Effectuez un test de vérification reproductible. Créez un ticket, envoyez une réponse et examinez la source brute. Vérifiez si In-Reply-To pointe vers un Message-ID antérieur, si References contient la chaîne attendue et si la réponse a été ajoutée au ticket existant.

Conseil de pro : Testez via la même adresse, le même chemin de transfert et le même client de messagerie que ceux qu'utiliseront vos clients. Un message direct envoyé à une adresse de test interne ne permet pas de tester l'intégralité de l'itinéraire de production.

Pourquoi les conversations se séparent et comment corriger chaque cause

Une réponse peut devenir un nouveau ticket pour plusieurs raisons. La cause exacte dépend des règles de correspondance de la plateforme.

  • En-têtes de réponse manquants. Un message rédigé comme un nouvel e-mail peut ne pas contenir les valeurs In-Reply-To ou References attendues d'une réponse. Demandez à l'expéditeur d'utiliser la fonction Répondre, puis comparez la source brute.
  • Routage ou destinataires modifiés. Un message envoyé à une autre adresse d'assistance peut créer un ticket supplémentaire. Freshdesk, par exemple, documente un comportement particulier lorsque plusieurs adresses de service d'assistance configurées sont incluses.
  • Identifiant de plateforme supprimé. La modification d'un modèle de notification peut supprimer un identifiant de ticket ou un identifiant masqué utilisé par le service d'assistance comme solution de secours.
  • Correspondance des messages expirée. Freshdesk indique que son identifiant de message expire normalement sept jours après la dernière réponse. Passé ce délai, il recherche l'identifiant du ticket ou l'identifiant de ticket. Ce délai est propre à Freshdesk et ne doit pas être supposé pour les autres produits.

Commencez le diagnostic avec le message sortant d'origine et la réponse du client. Comparez leurs en-têtes bruts côte à côte, puis consultez la documentation du service d'assistance et l'historique du ticket. Si les en-têtes de réponse sont présents, examinez les autres exigences de la plateforme, telles que les marqueurs de ticket, l'adresse de réception ou l'expéditeur autorisé. Si les en-têtes sont absents, retracez l'itinéraire via le fournisseur d'e-mail et tout service de transfert afin de déterminer où le message a été modifié.

Comment Deskhero préserve l'historique des conversations

Deskhero transforme une boîte aux lettres Gmail, Google Workspace ou Microsoft 365 existante en service d'assistance. Il prend également en charge les boîtes aux lettres hébergées sur d'autres domaines dont vous êtes propriétaire, grâce à l'authentification DNS et au transfert des messages entrants.

  • Les connexions Google et Microsoft fournissent une synchronisation bidirectionnelle, de sorte que Deskhero peut lire les e-mails entrants et envoyer des réponses depuis l'adresse connectée.
  • Une boîte aux lettres DNS utilise des enregistrements DKIM pour l'envoi authentifié et une adresse Deskhero unique pour le transfert des messages entrants.
  • Les réponses d'une même conversation par e-mail sont ajoutées au ticket Deskhero existant.
  • Les réponses suggérées par l'IA utilisent les connaissances de l'espace de travail et restent sous le contrôle de l'utilisateur. Les réponses automatiques constituent une fonctionnalité distincte qui doit être activée pour chaque groupe et répond uniquement à partir de la FAQ publique approuvée.

Pour plus de contexte, consultez les articles de Deskhero sur la synchronisation bidirectionnelle des e-mails du service d'assistance, l'utilisation d'une boîte aux lettres existante comme service d'assistance et la conversion des e-mails entrants en tickets.

Exigence Option Deskhero
Connecter Gmail ou Google Workspace Connexion OAuth avec synchronisation bidirectionnelle
Connecter Microsoft 365 ou Outlook Connexion OAuth avec synchronisation bidirectionnelle, y compris les boîtes aux lettres partagées
Utiliser un autre domaine dont vous êtes propriétaire Authentification DNS pour l'envoi et transfert pour les e-mails entrants
Contrôler les réponses de l'IA Les utilisateurs relisent les réponses suggérées ; les réponses automatiques nécessitent une activation distincte

Ce que la plupart des guides de configuration présentent à l'envers

Il est tentant de réduire le regroupement à une seule règle, comme la conservation du Message-ID. La documentation des fournisseurs montre pourquoi cette approche est incomplète. Zendesk combine les vérifications des en-têtes et des identifiants encodés. Freshdesk combine plusieurs marqueurs d'e-mail avec une vérification de l'expéditeur. Amazon Connect relie les contacts à l'aide de données de contacts associés et des en-têtes e-mail conventionnels.

Ce que la plupart des guides de configuration présentent à l'envers, schéma récapitulatif

La meilleure approche consiste à considérer le regroupement comme un comportement de bout en bout. Utilisez une connexion de boîte aux lettres prise en charge, conservez les identifiants générés par le produit et testez avec une véritable réponse client. Lorsque le résultat est incorrect, comparez les messages bruts et suivez l'ordre de correspondance documenté par le service d'assistance.

Cela permet également d'éviter les modifications inutiles des serveurs de messagerie. Un nouveau relais ou un modèle réécrit peut introduire une variable supplémentaire sans résoudre le véritable problème de correspondance.

Mettre en place un service d'assistance avec regroupement sans perdre une seule réponse

Deskhero peut connecter une boîte aux lettres Gmail, Google Workspace ou Microsoft 365 existante grâce à la synchronisation bidirectionnelle. Pour un autre domaine dont vous êtes propriétaire, il prend en charge l'envoi authentifié via une configuration DNS et le transfert des messages entrants vers une adresse Deskhero unique.

Deskhero

Vos utilisateurs travaillent depuis une boîte de réception partagée, tandis que les réponses sont envoyées depuis l'adresse de l'entreprise connectée. Si votre service d'assistance utilise Shopify, l'intégration Shopify ajoute le contexte du client et de la commande à la barre latérale du ticket.

Deskhero propose un essai gratuit de 30 jours sans carte bancaire requise. Vous pouvez connecter une adresse existante au lieu de demander à vos clients d'en apprendre une nouvelle.

Sources

FAQ

Quelle est la différence entre la synchronisation bidirectionnelle et le transfert ?

La synchronisation bidirectionnelle permet à un service d'assistance de lire les messages d'une boîte aux lettres connectée et d'envoyer des messages via celle-ci. Le transfert envoie les messages entrants vers une autre destination et peut nécessiter une authentification distincte pour les e-mails sortants. Les méthodes disponibles et les règles de regroupement dépendent du service d'assistance et du fournisseur d'e-mail.

Pourquoi la réponse d'un client a-t-elle créé un nouveau ticket au lieu d'être regroupée ?

La réponse peut ne pas contenir les en-têtes attendus, utiliser une autre adresse d'assistance, provenir d'un expéditeur que la plateforme n'associe pas au ticket ou ne pas contenir un identifiant de ticket propre au produit. Vérifiez la source brute de l'e-mail et les règles documentées par votre service d'assistance.

Comment vérifier que le regroupement a correctement fonctionné ?

Vérifiez que la réponse apparaît dans le ticket existant. Si ce n'est pas le cas, comparez les valeurs In-Reply-To et References de la réponse avec les valeurs Message-ID précédentes, puis vérifiez les identifiants de ticket utilisés par la plateforme.

Ai-je besoin d'un relais SMTP authentifié si j'utilise déjà la synchronisation bidirectionnelle ?

Généralement pas comme solution distincte au problème de regroupement. Suivez la configuration d'envoi requise par votre service d'assistance. Une connexion directe à une boîte aux lettres peut déjà gérer les e-mails sortants, tandis qu'une configuration basée sur le transfert ou le DNS peut utiliser une autre méthode d'envoi authentifié.

Deskhero prend-il en charge Gmail et Microsoft 365 ?

Oui. Deskhero prend en charge les connexions bidirectionnelles pour Gmail, Google Workspace, Microsoft 365 et Outlook. Les boîtes aux lettres partagées Microsoft sont également prises en charge.