Fonctionnement du transfert omnicanal Zendesk : Guide complet pour 2026

Lorsqu'un client entame une conversation avec votre agent d'IA mais a besoin de parler à un humain, que se passe-t-il ensuite ? Cette transition, le moment où le contrôle passe du bot à l'agent, est ce que les équipes de support appellent un transfert (handoff). Dans un environnement Zendesk, cela se complique rapidement car vous ne traitez pas seulement un seul canal. Vous gérez les e-mails, la messagerie, la voix et le chat, qui convergent tous vers le même système.

Ce guide explique comment fonctionne réellement le transfert omnicanal Zendesk. Nous aborderons les mécanismes du routage, les pièges courants qui font trébucher les équipes de support et comment configurer des transferts qui ne laissent pas les clients frustrés ou les agents confus.

Pour un aperçu plus large des stratégies de transfert de conversation, consultez notre guide sur le transfert de conversation Zendesk aux agents. Vous pourriez également trouver notre aperçu du support omnicanal Zendesk utile pour comprendre le contexte plus large.

Qu'est-ce que le transfert omnicanal Zendesk ?

Le transfert omnicanal est le processus de transfert d'une conversation client d'un intervenant à un autre sur différents canaux de support. Dans Zendesk, cela signifie généralement passer d'un agent d'IA à un agent humain, ou inversement.

Il y a deux actions distinctes à comprendre :

• Transfert (Handoff) : L'agent d'IA est supprimé en tant que premier intervenant de la conversation, et un agent humain prend le relais. Une fois que cela se produit, l'IA ne peut plus répondre à cette conversation.
• Restitution (Handback) : Lorsqu'un statut de ticket passe de Résolu à Fermé, l'agent humain est supprimé en tant que premier intervenant. Cela ouvre la voie à l'agent d'IA pour gérer de nouvelles conversations de ce client.

Les canaux couverts incluent l'e-mail (y compris les formulaires web et les soumissions d'API), la messagerie native, le chat en direct, WhatsApp, Facebook Messenger, les appels vocaux, les SMS et les messages directs des médias sociaux, y compris X (Twitter), Instagram et Telegram. Chaque canal a ses propres particularités en matière de routage et de comportement de transfert.

Pourquoi un transfert transparent est-il important ? Parce que les clients ne pensent pas en termes de canaux. Ils commencent un chat, puis envoient un e-mail, puis appellent lorsqu'ils sont frustrés. Si vos agents ne peuvent pas voir l'historique complet des conversations sur ces points de contact, vous obligez les clients à se répéter. C'est une voie rapide vers de mauvais scores de satisfaction.

Comment fonctionne le routage omnicanal dans Zendesk

À la base, le routage omnicanal est un contrôleur de trafic pour les tickets de support. Il examine les conversations entrantes de tous les canaux et décide quel agent doit traiter chacune d'elles en fonction de la disponibilité, de la capacité et des compétences.

Le moteur de routage

Lorsqu'un ticket devient éligible au routage, Zendesk évalue plusieurs facteurs dans l'ordre :

1. Attribution de la file d'attente : Les tickets sont placés soit dans la file d'attente de routage omnicanal standard, soit dans des files d'attente personnalisées (disponibles sur les plans Professional et Enterprise). Les files d'attente personnalisées vous permettent de router les tickets répondant à des conditions spécifiques vers des groupes désignés.

2. Statut de l'agent : Les agents définissent un statut unifié unique sur tous les canaux (en ligne, absent ou hors ligne). Pour la messagerie et les appels, les agents doivent être « en ligne » pour recevoir du travail. Pour l'e-mail, le statut « en ligne » ou « absent » est suffisant.

3. Règles de capacité : Elles contrôlent la quantité de travail que chaque agent peut gérer à la fois. Vous pouvez définir différentes limites de capacité pour les canaux de messagerie, de messagerie et vocaux.

4. Méthode d'attribution : Zendesk peut attribuer en fonction de la capacité de réserve la plus élevée ou du tour de rôle (celui qui est resté le plus longtemps sans recevoir de travail).

5. Correspondance des compétences : Sur les plans Professional et supérieurs, les tickets peuvent être routés uniquement vers des agents possédant des compétences spécifiques (comme la maîtrise de la langue ou l'expertise produit).

Files d'attente standard vs. personnalisées

La file d'attente standard route le travail vers les agents en fonction du groupe attribué au ticket. Les files d'attente personnalisées, disponibles sur les plans Professional et Enterprise, offrent plus de contrôle. Vous pouvez créer des files d'attente qui routent les tickets vers les groupes principaux en premier, puis vers les groupes secondaires si personne n'est disponible. Vous pouvez également hiérarchiser certains types de tickets par rapport à d'autres.

Limitations du routage basé sur les compétences

Voici quelque chose qui prend de nombreuses équipes au dépourvu : le routage basé sur les compétences fonctionne pour les tickets d'e-mail, mais il a des limitations avec la messagerie. Selon la documentation de Zendesk, le routage basé sur les compétences n'est pas disponible spécifiquement pour les tickets de messagerie. Cela signifie que si vous exécutez une opération axée sur la messagerie, vous aurez peut-être besoin d'autres stratégies de routage.

Configuration du transfert IA vers agent

Zendesk propose deux niveaux d'agents d'IA : Essential et Advanced. La configuration du transfert diffère selon celui que vous utilisez.

Options de transfert d'agent d'IA natif

Les agents d'IA Essential (inclus dans Suite Team et supérieur) gèrent les conversations de base et peuvent passer à des agents humains à l'aide de flux de dialogue intégrés.

Les agents d'IA Advanced (disponibles en tant que module complémentaire) offrent un raisonnement plus sophistiqué, des actions personnalisées et des capacités d'intégration plus approfondies. Ils utilisent un générateur de dialogue où vous pouvez configurer des blocs d'escalade qui déclenchent des transferts en fonction de l'intention, du sentiment ou des demandes spécifiques du client.

Le piège du timing Résolu vs. Fermé

C'est le problème de transfert le plus courant que rencontrent les équipes de support. Par défaut, Zendesk attend quatre jours entre le moment où un ticket est marqué comme Résolu et sa fermeture automatique. Pendant cette période, si un client revient sur votre canal de messagerie, il ne peut pas démarrer une nouvelle conversation. Ses messages vont au ticket existant, et l'agent humain reste le premier intervenant.

Cela crée une expérience frustrante où les clients pensent qu'ils recommencent à zéro, mais ils rouvrent en fait d'anciens tickets. L'agent d'IA ne s'engagera pas car il n'est pas le premier intervenant.

Vous avez deux façons de résoudre ce problème :

Option 1 : Ajuster l'automatisation par défaut Modifiez l'automatisation « Fermer le ticket 4 jours après que le statut est défini sur résolu ». Vous pouvez réduire cela à aussi peu qu'une heure ou l'étendre jusqu'à 28 jours.

Option 2 : Créer un déclencheur de fermeture immédiate Ajoutez une balise (comme « fermer ») lorsqu'un ticket est résolu, puis créez un déclencheur qui ferme immédiatement tout ticket avec cette balise. Les conditions du déclencheur seraient :

• Les balises contiennent « fermer »
• Action : Statut défini sur Fermé

Si vous utilisez des enquêtes CSAT, gardez au moins une petite marge entre la résolution et la fermeture pour éviter les conflits avec la livraison de l'enquête.

Préserver le contexte sur tous les canaux

La perte de contexte est le tueur silencieux des bons transferts. Un agent d'IA peut avoir recueilli des détails cruciaux, l'historique du client et des signaux d'intention. Si ces informations n'atteignent pas l'agent humain, vous repartez de zéro.

Voici comment maintenir la continuité :

Pièce jointe automatique de la transcription : Zendesk joint automatiquement les transcriptions de conversation aux tickets. Assurez-vous que vos agents savent où les trouver.

Champs de ticket personnalisés : Utilisez-les pour capturer des données structurées pendant les conversations d'IA, comme la catégorie de problème, le sentiment du client ou les résolutions tentées. Ces champs sont transférés à l'agent humain.

Transmission des métadonnées : Pour les intégrations techniques, utilisez les API Sunshine Conversations pour transmettre les métadonnées entre les systèmes. Cela peut inclure l'ID du client, l'historique des conversations et les attributs personnalisés.

Notes internes : Formez les agents d'IA à résumer les conversations dans les notes internes avant de transférer. Un résumé concis vaut mieux que de faire défiler 50 messages.

Formation des agents : Vos agents doivent savoir où se trouve le contexte. Créez un guide de référence rapide montrant comment accéder aux transcriptions, aux champs personnalisés et à l'historique des conversations à partir de l'espace de travail de l'agent.

Défis courants du transfert omnicanal

Même avec une configuration appropriée, les choses tournent mal. Voici les problèmes que nous rencontrons le plus souvent :

Les clients ne peuvent pas démarrer de nouvelles conversations : L'écart de statut Résolu vs. Fermé que nous avons couvert précédemment. Les clients reviennent en s'attendant à un nouveau départ et sont plutôt entraînés dans d'anciens tickets.

La mauvaise équipe reçoit les tickets escaladés : Les règles de routage ne sont pas assez spécifiques, ou les files d'attente personnalisées ne sont pas configurées pour correspondre à votre structure organisationnelle. Les tickets destinés au niveau 2 se retrouvent avec des agents de niveau 1 qui ne peuvent pas les résoudre.

Les agents manquent le contexte de la conversation : Les agents ne vérifient pas les transcriptions ou les champs personnalisés avant de répondre. Ils demandent aux clients de répéter les informations que l'IA a déjà collectées.

Délai d'attente des compétences et stagnation des tickets : Lorsque le routage basé sur les compétences est activé sans seuil de délai d'attente, les tickets peuvent rester dans la file d'attente indéfiniment si aucun agent possédant les compétences correspondantes n'est disponible. Les tickets d'e-mail et de messagerie attendent que quelqu'un possédant les bonnes compétences se connecte.

Limitations spécifiques au canal : Le routage basé sur les compétences ne fonctionne pas pour les tickets de messagerie. Les tickets vocaux ne peuvent pas être réaffectés une fois attribués à un agent. Les agents Light ne peuvent pas se voir attribuer de tickets ou définir leur statut.

Simplifier le transfert omnicanal avec eesel AI

Le routage natif de Zendesk est puissant, mais il nécessite une configuration importante et une maintenance continue. Si vous recherchez une approche plus simple, eesel AI gère les transferts avec moins de complexité.

Au lieu de créer des arborescences de dialogue dans le générateur de Zendesk, vous définissez des règles d'escalade en langage clair. Par exemple : « Si le client pose des questions sur les litiges de facturation, escaladez immédiatement vers l'équipe des finances. » Pas de codage, pas de configurations de déclencheur complexes.

L'intégration Zendesk préserve automatiquement le contexte. Lorsque eesel transfère à un agent Zendesk, l'historique complet des conversations, les données client et le résumé généré par l'IA l'accompagnent. Les agents voient tout ce dont ils ont besoin sans avoir à chercher dans plusieurs onglets.

Avant de passer en direct, vous pouvez exécuter des simulations sur des milliers de tickets passés pour voir exactement comment les transferts fonctionneraient. Testez différentes règles d'escalade, mesurez les taux de résolution et affinez votre approche sans toucher aux conversations réelles des clients.

eesel s'intègre également à plus de 100 sources de connaissances au-delà de Zendesk : vos documents Confluence, Google Drive, pages Notion, et plus encore. Cela signifie qu'eesel a un contexte plus large pour gérer les scénarios de transfert complexes.

Démarrer avec des transferts omnicanaux plus intelligents

Si vous configurez ou optimisez le transfert omnicanal Zendesk, commencez par ces étapes :

1. Vérifiez votre configuration de routage actuelle : Documentez les files d'attente existantes, la façon dont les tickets circulent entre elles et où les transferts se produisent actuellement.

2. Vérifiez le timing de l'automatisation Résolu → Fermé : Vérifiez cette fenêtre par défaut de 4 jours. Si cela cause de la confusion chez les clients, ajustez-la ou créez un déclencheur de fermeture immédiate.

3. Testez les flux d'escalade avec des scénarios réels : Exécutez des conversations de test via vos agents d'IA et vérifiez qu'ils atteignent les bons agents humains avec un contexte complet intact.

4. Tenez compte de votre tolérance à la complexité : Si la configuration du routage de Zendesk vous semble écrasante, des outils comme eesel AI offrent un chemin plus simple vers des transferts efficaces.

Vous voulez voir comment eesel AI gère les transferts ? Essayez-le gratuitement ou réservez une démonstration pour le voir en action avec votre configuration Zendesk existante.