Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 61

Interpréter les logs pour diagnostiquer un échec de routage

Recommended resources

Bonjour !

Dans la leçon précédente, nous avons appris à naviguer dans la vue Interaction Details pour analyser le cycle de vie d'une interaction. Vous savez maintenant comment retracer le parcours d'un contact et identifier la raison de sa déconnexion.

Aujourd'hui, nous allons approfondir cette analyse pour atteindre l'objectif de la leçon : diagnostiquer un échec de routage en interprétant les logs d'une interaction. Si la leçon précédente répondait aux questions "quoi ?" et "quand ?", celle-ci répondra au "pourquoi ?". Pourquoi cet appel n'a-t-il pas atteint un agent ? Pourquoi a-t-il été envoyé à la file d'attente B au lieu de la A ?

Pour quelqu'un avec votre expérience sur Cisco UCCE, cela équivaut à analyser les logs du routeur pour comprendre une décision de routage. Dans Genesys Cloud, cette information est intégrée directement dans la vue que vous connaissez déjà, rendant le diagnostic plus rapide et contextuel.

1. Le parcours de routage d'une interaction

Avant de plonger dans les logs, il est essentiel d'avoir une vision claire du processus de routage. Une interaction ne va pas directement du téléphone à l'agent ; elle suit un chemin logique que vous configurez.

Genesys Cloud Simple Interaction Routing Overview
Ce schéma illustre le parcours de routage de bout en bout. Un appel arrive sur un numéro (DID), est d'abord traité par un flux Architect (qui peut vérifier des plannings, par exemple), puis est potentiellement mis en attente dans un flux en file avant d'atteindre une file d'attente (Queue). C'est là que le moteur ACD de Genesys Cloud sélectionne un agent en fonction de ses compétences (skills) et d'autres règles. Un échec peut survenir à n'importe quelle étape de ce processus.

Notre travail de diagnostic consistera à identifier à quelle étape le problème s'est produit et pourquoi.

2. Le diable est dans les détails (de la timeline)

Dans la leçon précédente, nous avons examiné la timeline pour voir la séquence des événements. Maintenant, nous allons l'utiliser de manière interactive. La clé est de comprendre que chaque segment de la timeline est cliquable et révèle des détails techniques sur ce qui s'est passé pendant cette étape précise.

Imaginez qu'un appel n'a jamais été répondu. La timeline pourrait ressembler à ceci :

  1. Un segment pour le client (External).
  2. Un segment pour le flux SVI (IVR).
  3. Un long segment pour la file d'attente (ACD).
  4. L'appel se termine sans qu'un segment Interact avec un agent n'apparaisse.

C'est ce segment ACD qui détient les secrets du routage. En cliquant dessus, vous accédez à un journal détaillé des tentatives de routage.

Genesys Cloud: Chronologie d'une Interaction Téléphonique
Comme nous l'avons vu, la timeline décompose l'appel en segments (IVR, ACD, Agent). Pour diagnostiquer un échec de routage, notre attention se portera principalement sur le segment 'ACD' (la file d'attente).

3. Interpréter les logs de routage (ACD)

Lorsque vous cliquez sur le segment ACD d'un participant dans la timeline, la partie inférieure de l'écran se met à jour pour afficher des informations de bas niveau. C'est ici que vous trouverez les "logs" de routage. Bien qu'ils ne soient pas présentés comme un fichier de log brut, les informations sont chronologiques et très détaillées.

Voici les scénarios d'échec les plus courants et comment les identifier :

Scénario 1 : Aucun agent disponible avec les bonnes compétences

Le symptôme le plus courant est un appel qui reste en attente indéfiniment (ou jusqu'à ce que le client raccroche) parce que le moteur de routage ne trouve personne à qui l'attribuer.

Comment le diagnostiquer :

  1. Cliquez sur le segment ACD dans la timeline.
  2. Dans les détails qui s'affichent, cherchez des messages indiquant une évaluation de routage. Vous verrez des lignes comme :
    • Evaluating routing rules for conversation [ID]
    • Targeting queue: [Nom de la file d'attente]
    • Required skills: [Compétence X], [Compétence Y]
    • Le message crucial : No agents available for routing ou une phrase similaire.
  3. Si le routage Bullseye est configuré, vous pourrez voir les tentatives d'élargissement :
    • Starting bullseye ring 1 evaluation
    • No agents found in ring 1
    • Expanding to bullseye ring 2...
  4. Enfin, si le client a raccroché d'impatience, le disconnectType pour le participant externe sera Peer, comme nous l'avons vu dans la leçon précédente.

Ce diagnostic vous indique immédiatement que le problème n'est pas technique, mais probablement organisationnel (manque de personnel, mauvaise affectation des compétences).

Scénario 2 : Un agent est alerté mais ne répond pas

Parfois, un agent est disponible et le système lui envoie l'appel, mais pour une raison quelconque, il n'y a pas de réponse.

Comment le diagnostiquer :

  1. Suivez la même procédure : cliquez sur le segment ACD.
  2. Dans les logs de routage, vous verrez une séquence différente :
    • Evaluating routing rules...
    • Found available agent: [Nom de l'agent]
    • Alerting agent [Nom de l'agent]
  3. Après quelques secondes, vous verrez un message indiquant que l'agent n'a pas répondu :
    • Agent [Nom de l'agent] did not answer ou Alert timed out for agent [Nom de l'agent]
  4. Le système tentera alors de trouver un autre agent.
  5. Le disconnectType pour le segment de l'agent qui n'a pas répondu sera No Answer Transfer. Cela confirme que Genesys Cloud a mis fin à la tentative d'alerte pour cet agent et a poursuivi sa recherche.

Ceci indique un problème soit avec l'agent (distrait, loin de son poste), soit avec sa station (téléphone non branché, problème WebRTC).

Scénario 3 : L'appel est déconnecté par le système avant d'atteindre un agent

Dans certains cas, c'est le système lui-même qui met fin à l'attente.

Comment le diagnostiquer :

  1. Analysez la timeline. L'appel se termine pendant le segment ACD.
  2. Consultez les raisons de déconnexion. Pour cela, le document suivant reste notre référence.

Disconnect reasons in the interaction's detail view

Nous allons réutiliser cette ressource pour identifier les raisons de déconnexion spécifiques à un échec de routage.

Consultez à nouveau le tableau et portez une attention particulière aux raisons suivantes : 'Timeout', 'No Answer Transfer', et 'Error'. Ce sont des indicateurs clés d'un problème de routage ou de système.

  • Un disconnectType de Timeout peut indiquer qu'une limite de temps d'attente maximale (configurée dans le flux Architect) a été atteinte.
  • Un disconnectType de Error est plus grave et suggère un problème au sein de la plateforme. C'est à ce moment que l'ID de l'interaction devient essentiel pour ouvrir un ticket de support auprès de Genesys.

4. Méthodologie de diagnostic pas à pas

Pour synthétiser, voici la démarche à suivre face à un rapport d'échec de routage :

  1. Trouver l'interaction dans l'une des vues de performance (Interactions, Queues Interactions Detail, etc.).
  2. Ouvrir la vue Interaction Details.
  3. Analyser la timeline pour identifier l'étape où l'interaction s'est terminée prématurément (généralement pendant le segment IVR ou ACD).
  4. Cliquer sur le segment pertinent (ex: ACD) pour afficher les logs de cette étape.
  5. Lire les logs de routage en cherchant des mots-clés comme evaluating, skills, no available agents, alerting agent, did not answer.
  6. Vérifier la Disconnect Reason de l'interaction et des participants pour confirmer votre hypothèse (ex: Peer pour un client qui raccroche, No Answer Transfer pour un agent qui ne répond pas).

En suivant ces étapes, vous pouvez transformer une plainte vague en un diagnostic précis et factuel en quelques minutes.

Pour les problèmes de téléphonie plus complexes (liés au protocole SIP), sachez que la vue Interaction Details contient des liens vers des outils plus avancés. La ressource que nous avons consultée dans la leçon précédente, View an interaction's details, mentionne un lien "Work with SIP Diagnostics". C'est un outil pour les experts en téléphonie, mais il est bon de savoir qu'il est accessible directement depuis cette interface.

Conclusion

Vous avez maintenant ajouté une compétence essentielle à votre panoplie de diagnostic. Vous ne vous contentez plus de voir ce qui s'est passé, vous pouvez commencer à comprendre pourquoi cela s'est passé.

Points clés à retenir :

  • Le routage dans Genesys Cloud est un processus en plusieurs étapes (Architect -> Queue -> Agent).
  • La timeline de l'interaction est interactive ; cliquer sur un segment révèle des logs détaillés pour cette étape.
  • Le segment ACD contient les informations cruciales sur l'évaluation des compétences, la disponibilité des agents et les tentatives d'alerte.
  • Les messages comme No agents available ou Agent did not answer sont des indicateurs directs de la cause d'un échec de routage.
  • La combinaison des logs de routage et des Disconnect Reasons permet de poser un diagnostic complet.

Et ensuite ?
Nous avons appris à diagnostiquer un échec de routage en analysant les traces d'une interaction terminée. Mais que faire si le problème vient de la logique complexe de votre flux Architect lui-même ? Dans la prochaine leçon, nous passerons du diagnostic a posteriori au diagnostic en temps réel en apprenant à déboguer une erreur de logique dans un flux Architect en utilisant le mode debug et les logs.