La version bêta du routage omnicanal vous permet d’envoyer des tickets provenant de l’e-mail, de la messagerie, du formulaire Web et de l’API aux membres de l’équipe en fonction de leur disponibilité, de leur capacité et de la priorité des tickets. Avec le routage omnicanal, les tickets les plus urgents sont affectés aux agents disponibles pour les traiter en priorité. Cela s’accompagne des avantages suivants :
- Les agents peuvent répondre plus rapidement aux tickets.
- Vous pouvez traiter les tickets des clients VIP en priorité.
- Les agents se voient automatiquement affecter les tickets et n’ont pas à les chercher.
- Les agents ne peuvent pas choisir les tickets sur lesquels ils veulent travailler.
- Les agents peuvent travailler dans plusieurs canaux de tickets en même temps.
Vous pouvez utiliser les règles de capacité pour limiter le volume de travail affecté aux agents en même temps. Cependant, malgré ces règles, vos agents peuvent s’affecter plus de travail (et donc ignorer ces limites) s’ils le souhaitent (consultez Charge de travail des agents et règles de capacité).
Le routage omnicanal inclut des statuts d’agent qui viennent compléter les statuts par défaut (en ligne, absent, transfert uniquement et hors ligne) pour vous permettre de définir vos propres statuts, par exemple « Pause déjeuner » ou « En réunion ». Cela peut vous aider à décider comment router les différentes tâches (appels, tickets et messages) en fonction du statut et de la capacité des agents (consultez Configuration des statuts de l’agent).
Le routage omnicanal est disponible pour les comptes dans lesquels l’espace de travail d’agent est activé. En outre, si votre compte inclut un abonnement à Chat, la messagerie ou Sunshine Conversations doivent être activées.
Cet article contient les sections suivantes :
Fonctionnement du routage omnicanal
Le routage omnicanal dirige le travail vers les agents en fonction des éléments suivants :
- Disponibilité. Elle est définit par le statut configuré par l’agent.
- Capacité pour chaque canal de travail. Vous définissez la capacité pour chaque canal et décidez quels tickets peuvent être routés.
Vous utiliserez alors des déclencheurs pour affecter les tickets aux groupes, affecter une priorité aux tickets et leur ajouter un marqueur de routage. Le tableau suivant montre l’ordre dans lequel les tickets (provenant de l’e-mail, du formulaire Web, de l’API et de la messagerie) sont routés aux agents.
| Édition | Ordre de routage des tickets |
|---|---|
|
Suite Team et Growth |
Les tickets sont affectés aux agents dans l’ordre de création. |
|
Suite Professional et Enterprise |
Le ticket avec la priorité la plus élevée et la date de création la plus ancienne est routé à un agent du groupe affecté qui a un statut éligible et la capacité disponible la plus importante. |
Les tickets sont affectés aux agents en fonction des éléments suivants :
- Le statut de l’agent pour le canal :
- Conversations de messagerie : un agent doit avoir le statut En ligne pour recevoir des tickets de messagerie. Consultez Configuration de votre statut de chat dans l’espace de travail d’agent Zendesk.
- Tickets par e-mail : un agent doit avoir le statut En ligne ou Absent pour recevoir des tickets par e-mail.
Si un agent oublie de définir son statut sur Hors ligne, le statut de l’agent est automatiquement défini sur Hors ligne lorsque l’un des événements suivants est détecté :
- Un agent ferme l’espace de travail d’agent sans se déconnecter (en éteignant son ordinateur, fermant sa fenêtre de navigateur ou en mettant son ordinateur en veille).
- Un agent perd sa connexion à cause d’un problème de réseau.
- La capacité disponible de l’agent pour ce canal :
- Un agent doit avoir moins de tickets ouverts ou de conversations de messagerie actives que la capacité maximale définie pour ce canal.
- Si plusieurs agents ont un statut éligible et la capacité disponible, c’est à l’agent avec la capacité disponible la plus importante pour le canal concerné que le ticket est affecté.
Si plusieurs agents ont un statut éligible et la capacité disponible la plus importante, c’est à l’agent à qui un ticket a été affecté il y a le plus longtemps que le ticket est affecté.
Voici un exemple de scénario pour le routage omnicanal :
- Un utilisateur final VIP a un problème urgent qui doit être résolu.
- Il envoie un ticket via le canal E-mail.
- L’administrateur du compte a configuré un déclencheur pour le compte qui ajoute un marqueur de routage automatique à ces tickets, puis qui affecte un groupe et une priorité.
- Ainsi, le ticket de l’utilisateur final est automatiquement routé à un groupe spécifique avec une priorité urgente.
- Le routage omnicanal évalue alors le ticket en fonction du statut et de la capacité de l’agent.
- Le système voit d’abord que deux agents sont disponibles.
- Puis, il trouve l’agent avec la capacité disponible la plus importante pour les e-mails et lui affecte le ticket.
Considérations pour le routage omnicanal
Le délai de réaffectation réaffecte un message à un agent du groupe si le premier agent n’accepte pas le message dans un délai spécifique.
- Le paramètre de délai de réaffectation doit être activé pour réaffecter automatiquement les tickets qui ne sont pas acceptés dans un délai spécifié. S’il n’est pas activé, le moteur de routage continue de réessayer de l’affecter au même agent. Un message reste actif pendant 10 minutes dans la file d’attente. Si après 10 minutes, il n’a toujours pas été affecté à un agent, il est réaffecté à l’agent en ligne suivant (on parle de routage tourniquet ou Round-Robin) et ne consommera pas de capacité.
Limites de la version bêta du routage omnicanal
Les limites suivantes s’appliquent actuellement à la version bêta du routage omnicanal :
- Les tickets générés à partir des appels Talk ne sont pas inclus à cette version bêta. Cependant, Talk continuera de fonctionner normalement quand vous activez le routage omnicanal. Pour en savoir plus et être tenu courant de la sortie des versions futures, consultez Bientôt disponibles : Appels dans le routage omnicanal.
- La capacité de configuration du statut d’un agent s’il n’accepte pas un certain nombre d’affectations de messages (statut Inactif automatique) n’est pas prise en charge.
- Les modes de diffusion et hybride pour la messagerie ne sont pas pris en charge.
- Le moteur de routage omnicanal ne prend pas les compétences en compte. Cette fonctionnalité sera disponible dans les prochaines versions.
- Si vous activez la version bêta du routage omnicanal, vous ne pourrez plus changer le statut d’un agent Talk dans le tableau de bord Talk ou en utilisant les API Talk. Nous introduirons de nouvelles API dans une version ultérieure.
- Si le transfert d’appels est activé et que le statut d’un agent est automatiquement défini sur Hors ligne car l’agent est déconnecté, les appels à cet agent ne sont plus transférés à son téléphone.
Articles connexes
Consultez les articles suivants pour en savoir plus sur la configuration et l’utilisation du routage omnicanal et des statuts de l’agent :
0 Commentaires
Vous devez vous connecter pour laisser un commentaire.