Changement de canal Zendesk : ce qui est possible et ce qui ne l’est pas en 2026

Si vous avez déjà essayé de modifier le canal d’un ticket dans Zendesk (par exemple, d’un appel téléphonique à un e-mail), vous vous êtes probablement heurté à un mur. Vous n’êtes pas seul(e). C’est l’une des fonctionnalités les plus demandées dans la communauté Zendesk, et c’est une source de réelle frustration pour les équipes de support.

La confusion commence avec la terminologie. Zendesk propose des « transferts de canal » pour les conversations de messagerie, mais c’est complètement différent de la modification de la propriété de canal d’un ticket. L’un fonctionne. L’autre pas. Ce guide clarifie ce qui est réellement possible, pourquoi la limitation existe et comment la contourner.

La confusion du changement de canal

Soyons clairs tout de suite. Lorsque les gens disent « changement de canal Zendesk », ils veulent généralement dire l’une des deux choses suivantes :

Transfert de canal (pris en charge) : Déplacer une conversation d’un canal de messagerie à un autre, comme du Web Widget vers WhatsApp. Cela préserve l’historique de la conversation et garde tout dans un seul fil de discussion.

Changement de canal (non pris en charge) : Modifier la propriété de canal du ticket, comme passer d’un ticket Talk à un e-mail. C’est ce que la plupart des gens veulent réellement, et ce n’est pas possible nativement.

Voici la version courte : si vous essayez de déplacer une conversation entre des applications de messagerie, Zendesk peut le faire. Si vous essayez de modifier la façon dont un ticket est classé à des fins de routage et de reporting, vous n’avez pas de chance.

Tout récemment, un agent a fait un suivi d’une conversation téléphonique par e-mail, mais comme le ticket était toujours classé comme appel téléphonique, nos déclencheurs de routage normaux ne se sont pas déclenchés. Le ticket est resté non attribué jusqu’à ce que quelqu’un le prenne manuellement et le délègue.

Communauté Zendesk

Ce que Zendesk prend réellement en charge : les transferts de canal

Les transferts de canal sont conçus pour les conversations de messagerie. Ils vous permettent de déplacer un client d’un canal à un autre sans perdre le contexte. Le cas d’utilisation original était simple : un client commence à chatter sur votre site web, mais il doit partir. Au lieu de le perdre, vous pouvez transférer la conversation vers WhatsApp ou Facebook Messenger afin qu’il puisse continuer sur son téléphone.

Comment fonctionnent les transferts de canal

Il existe deux façons de lancer un transfert :

Lancé par l’utilisateur : Le client clique sur un bouton dans le Web Widget pour continuer la conversation sur un canal social. Zendesk gère cela automatiquement. Aucun codage n’est requis.

Lancé par l’entreprise : Votre système utilise l’API Conversations pour lier l’utilisateur à un nouveau canal. Cela nécessite un travail de développement, mais vous donne plus de contrôle.

L’approche API utilise ce qu’on appelle un « code de demande de lien ». Votre système génère un jeton unique, l’envoie à l’utilisateur, et lorsqu’il accepte, les canaux sont liés. L’utilisateur reçoit une invite lui demandant s’il souhaite connecter le nouveau canal, et une fois confirmé, la conversation se poursuit de manière transparente.

Types de confirmation

Lorsque vous utilisez l’API, vous choisissez comment l’utilisateur confirme le transfert :

Source : Documentation sur le transfert de canal Zendesk

Le piège

Les transferts de canal ne fonctionnent qu’entre les canaux de messagerie. Vous pouvez passer du Web Widget à WhatsApp, ou de Facebook Messenger à Instagram Direct. Mais vous ne pouvez pas utiliser cette fonctionnalité pour changer un ticket Talk en e-mail, ou un ticket e-mail en chat. La classification de canal d’origine du ticket reste la même.

Ce que Zendesk ne prend pas en charge : la modification des canaux de ticket

C’est là que les choses deviennent frustrantes. Zendesk ne vous permet pas de modifier la propriété de canal d’un ticket après sa création. Si un client vous appelle et que le ticket est créé en tant que canal « Appel téléphonique », il le reste pour toujours, même si toute la communication ultérieure se fait par e-mail.

Pourquoi c’est important

La propriété de canal contrôle plusieurs éléments importants :

• Règles de routage : Vos déclencheurs et automatisations dépendent souvent du canal. Si un ticket est classé comme appel téléphonique, mais que le suivi se fait par e-mail, vos règles de routage « E-mail » ne se déclencheront pas.
• Comportement de l’agent : Les agents peuvent accidentellement répondre via le mauvais canal. Nous avons tous vu le représentant du support qui envoie « Bonjour [nom] » comme message de chat alors qu’il voulait envoyer un e-mail.
• Reporting : Vos métriques de canal sont faussées. Un ticket qui a commencé comme un appel, mais qui a été résolu entièrement par e-mail, compte toujours comme un ticket téléphonique dans vos rapports.

Dans ce monde de contact multicanal, il est insensé de devoir créer un nouveau ticket, ou de demander à votre équipe d’administration de surveiller une vue pour pousser les tickets qui étaient à l’origine un appel téléphonique vers un autre agent. La plateforme devrait simplement passer de manière transparente des appels, aux chats, aux tickets, aux messages, aux rappels.

Communauté Zendesk

Ce que dit Zendesk

Selon les publications de la communauté, Zendesk a reconnu cette limitation. Un chef de produit a noté que l’activation des changements de canal est sur la feuille de route, avec le début de 2026 mentionné comme échéancier probable. Mais pour l’instant, il n’y a pas de solution native.

Source : Communauté Zendesk : Activer le changement de canal

Pourquoi le changement de canal est important pour votre flux de travail

Vous vous dites peut-être : « Et alors ? Le ticket est résolu de toute façon. » Mais l’inadéquation des canaux crée de réels problèmes opérationnels.

Échecs de routage

Lorsqu’un canal de ticket ne correspond pas à la façon dont vous communiquez réellement, votre routage automatisé peut se briser. Voici un scénario courant :

1. Le client appelle et laisse un message vocal. Ticket créé en tant que « Appel téléphonique (entrant) ».
2. L’agent rappelle, n’obtient pas de réponse, envoie un e-mail de suivi.
3. Le client répond à l’e-mail.
4. Votre déclencheur qui attribue les tickets « E-mail » à l’équipe de support ne se déclenche pas, car le ticket est toujours classé comme appel téléphonique.
5. Le ticket reste en suspens jusqu’à ce que quelqu’un l’achemine manuellement.

Cela arrive plus souvent que vous ne le pensez, surtout dans les équipes qui gèrent plusieurs canaux.

Confusion de l’agent

Les agents travaillent plus rapidement lorsque l’interface correspond à leur intention. Lorsqu’un ticket est par défaut sur le mauvais canal, des erreurs se produisent. Les agents envoient des messages de chat alors qu’ils voulaient envoyer un e-mail. Ils déclenchent les mauvaises macros. Ils perdent du temps à vérifier quel canal est actif.

Une fois qu’un ticket est devenu un canal de messagerie, il devrait le rester par défaut.

Communauté Zendesk

Maux de tête de reporting

Si vous essayez de mesurer la performance des canaux, les tickets à canaux mixtes polluent vos données. Un ticket qui commence comme un appel, mais qui est résolu par e-mail, peut afficher de mauvaises métriques de « résolution d’appel » même si le problème réel a été résolu par e-mail. Il est donc difficile de comprendre quels canaux fonctionnent réellement pour vos clients.

Solutions de contournement qui fonctionnent réellement

En attendant que Zendesk ajoute le changement de canal natif, voici trois approches qui peuvent vous aider.

Approche des champs personnalisés

Créez un champ déroulant personnalisé appelé « Méthode de communication » ou « Canal réel ». Lorsqu’un agent passe d’un canal à un autre (comme d’un appel à un e-mail), il met à jour ce champ. Créez ensuite vos déclencheurs de routage pour qu’ils examinent le champ personnalisé au lieu de la propriété de canal native.

Avantages : Simple à configurer, donne le contrôle aux agents Inconvénients : Nécessite la discipline de l’agent pour mettre à jour le champ, ne corrige pas le canal de réponse par défaut

Routage basé sur des déclencheurs

Configurez des déclencheurs qui détectent quand le modèle de communication d’un ticket change. Par exemple :

• Lorsqu’un ticket « Appel téléphonique » reçoit une réponse par e-mail, ajoutez une balise comme « email_follow_up »
• Créez une vue ou une règle de routage qui recherche cette balise
• Attribuez automatiquement ces tickets à un groupe spécifique qui gère les suivis multicanaux

Cela ne change pas le canal, mais cela garantit que le ticket est acheminé correctement de toute façon.

Macros pour la cohérence des canaux

Créez des macros que les agents peuvent utiliser lors du changement de canal. Par exemple, une macro « Passer à l’e-mail » pourrait :

• Ajouter une note interne documentant le changement de canal
• Appliquer une balise à des fins de routage
• Ajouter une réponse standard expliquant le changement au client
• Mettre à jour la priorité du ticket si nécessaire

Cela standardise le processus et garantit que rien ne passe entre les mailles du filet.

Une meilleure approche : comment l’IA eesel gère le support multicanal

Les solutions de contournement aident, mais elles ne résolvent pas le problème sous-jacent. Le vrai problème est que Zendesk traite les canaux comme des propriétés fixes alors que le support moderne est intrinsèquement fluide. Les clients passent de l’e-mail, au chat, au téléphone et aux médias sociaux sans penser aux « canaux ».

Chez eesel AI, nous adoptons une approche différente. Au lieu d’essayer de gérer les propriétés des canaux, nous nous concentrons sur la résolution des conversations, quel que soit l’endroit où elles se produisent.

Voici comment cela fonctionne avec Zendesk :

Autonomie progressive : Commencez par demander à eesel de rédiger des réponses pour l’examen de l’agent. Au fur et à mesure que vous gagnez en confiance, laissez-le envoyer des réponses directement. Finalement, il peut gérer le support de première ligne complet tout en ne faisant remonter que les problèmes complexes que vous définissez.

Fonctionne sur tous les canaux : eesel lit les tickets de n’importe quel canal Zendesk (e-mail, chat, messagerie, notes téléphoniques) et rédige des réponses appropriées. Le canal n’a pas d’importance, car l’IA comprend le contexte de la conversation.

Contrôle en anglais simple : Définissez les règles de routage et d’escalade en langage naturel. « Toujours faire remonter les litiges de facturation à Sarah » ou « Si la demande de remboursement est supérieure à 30 jours, refuser poliment. » Pas de configurations de déclencheur complexes.

Apprend de votre historique : Connectez eesel à vos anciens tickets, articles du centre d’aide et macros. Il comprend votre ton, vos politiques et les problèmes courants dès le premier jour. Aucune formation manuelle n’est requise.

Pour les équipes qui ont déjà investi dans Zendesk, notre agent d’IA pour Zendesk s’intègre directement à votre configuration existante. Vous ne remplacez pas votre centre d’assistance, vous l’améliorez. L’IA gère les réponses de routine sur tous les canaux, afin que vos agents puissent se concentrer sur les conversations qui ont réellement besoin d’une intervention humaine.

Si vous êtes intéressé(e) par la façon dont le support unifié fonctionne sans la complexité des canaux, notre guide sur l’unification de plusieurs canaux de support dans Zendesk couvre les stratégies complémentaires.

Choisir la bonne approche pour votre équipe

Alors, quelle est la meilleure solution pour votre situation ?

Si vous êtes une petite équipe avec un routage simple : L’approche des champs personnalisés est probablement suffisante. Formez vos agents à mettre à jour le champ lorsqu’ils changent de canal, et créez quelques déclencheurs pour gérer le routage.

Si vous avez des règles de routage complexes : Vous aurez besoin de l’approche basée sur des déclencheurs. C’est plus de travail à configurer, mais cela évolue mieux et ne dépend pas des agents qui se souviennent de mettre à jour les champs.

Si le changement de canal est un casse-tête quotidien : Envisagez d’augmenter Zendesk avec l’IA. Les outils comme l’IA eesel suppriment complètement la complexité des canaux en gérant les réponses de manière autonome, quel que soit l’endroit où la conversation a commencé.

En résumé : les limitations de canal de Zendesk sont réelles, mais elles ne sont pas insurmontables. Avec les bonnes solutions de contournement (ou le bon coéquipier d’IA), vous pouvez maintenir votre support en bon état de marche en attendant l’arrivée du changement de canal natif.