Le mode Play sert automatiquement les tickets qui ne sont pas consultés par les autres agents. Il est donc possible qu’un groupe de personnes soit en train de lire des tickets à partir d’une vue et que le système évite les collisions d’agentset ne leur envoie jamais un ticket pour lequel un autre utilisateur est présent.
Cette fonctionnalité fonctionne comme défini ci-dessus si:
- Tous les tickets de cette vue ne sont jamais consultés par des tiers hors de ce groupe
- Chaque agent du groupe joue toujours ces tickets en utilisant le bouton Play
- Aucun agent n’est autorisé à ouvrir des tickets à partir de la vue d’une autre façon
Cependant, il existe quelques scénarios dans lesquels un agent en mode Play peut recevoir un ticket auquel est déjà affecté quelqu’un. Dans cet article, nous expliquerons ces scénarios et comment les éviter.
Cet article aborde les sujets suivants :
Pour en savoir plus au sujet des collisions d’agents et du mode Play, consultez Utilisation des tickets.
Scénario de collision potentielle entre agents en mode Play
Il existe trois scénarios relativement courants pouvant entraîner une collision d’accès en mode Play:
Scénario 1 : Un autre agent ouvre un ticket manuellement
Si un agent consulte un ticket en mode Play, rien n’empêche un autre agent qui n’est pas en mode Play d’ouvrir ce ticket manuellement (par ex. Après l’avoir trouvé dans une recherche). L’agent en mode Play voit alors quelqu’un d’autre est sur son ticket et pense que le mode Play ne fonctionne pas correctement.
Scénario 2 : Perte de connexion en mode Play
Supposons que les agents A et B utilisent le mode Play. Pendant la lecture de ces tickets, tout semble aller bien. Puis A part pour le déjeuner, avec un onglet de ticket ouvert. (Supposons que le ticket T). Elle est en ligne pour le ticket T et pendant le déjeuner, un problème survient: elle perd la connectivité réseau. Cette perte peut être due à une panne d’Internet ou à une mise en veille de son ordinateur portable. L’agent A n’est plus en ligne et le système ne pense donc plus que l’agent A participe au ticket.
L’agent B reçoit alors le ticket T pendant qu’il joue et travaille sur le ticket. C’est là que l’agent A termine son déjeuner et appuie sur une touche de son ordinateur portable. Il se réveille et instantanément, l’agent A est en ligne avec le ticket T. B le voit et dit: «Je pensais que ce bouton de lecture n’était jamais censé me donner des tickets que d’autres agents regardaient!»
Scénario 3 : Perte de connexion hors du mode Play
Supposons que ce qui suit se produit:
- L’agent A et l’agent B n’utilisent pas le mode Play
- L’agent B ouvre le ticket T
- L’agent A ouvre alors le ticket T et voit un message l’informant que le ticket est également ouvert auprès de l’agent B
- L’agent A perd sa connectivité Internet et le message reste
- L’agent B clôture le ticket T
- L’agent A revient en ligne et continue de voir le message, même si l’agent B ne figure plus dans le ticket
Identification et résolution des collisions d’agents en mode Play
Pour identifier et résoudre les problèmes liés au mode Play ou à la présence des agents, vous devez vous pencher sur les points suivants:
Effacer le cache du navigateur et les cookies
Zendesk utilise divers cookies pour gérer la présence des agents et si vous rencontrez des problèmes, la première chose à faire est d’actualiser ces cookies régulièrement. Consultez Options pour effacer le cache et les cookies pour savoir comment faire.
URL de présence des agents
Les connexions à Zendesk pour vérifier si un agent participe à un ticket ne se font pas par le biais de la même URL que pour les demandes au reste de Zendesk (par ex. mydomain.zendesk.com), mais plutôt via une URL du formulaire pubsub-shardC-P-N.zendesk.com, où:
- C est le groupe du compte (valeur comprise entre 1 et 3)
- P est le pod du compte
- N est un nombre aléatoire compris entre 1 et 4
Par exemple, en utilisant les outils de développement de Chrome et en filtrant par pubsub, nous voyons que l’URL est https://pubsub-shard2-17-3.zendesk.com:
Dans l’exemple ci-dessus, pour ce compte spécifique:
- C = 2
- P = 17
- N = 3, mais peut être n’importe quel nombre compris entre 1 et 4
Les URL suivantes doivent donc être autorisées pour ce compte et autorisées dans votre VPN, votre pare-feu et tout logiciel antivirus que vous utilisez:
https://pubsub-shard2-17-1.zendesk.comhttps://pubsub-shard2-17-2.zendesk.comhttps://pubsub-shard2-17-3.zendesk.comhttps://pubsub-shard2-17-4.zendesk.com
Longues périodes d’inactivité des agents
Une collision d’accès peut se produire en raison de longues périodes d’inactivité d’un ticket. Quand l’écran est inactif, le système ne détecte pas l’activité de l’agent sur le ticket.
Consultez Éviter les collisions d’agents pour savoir comment identifier les agents qui consultent, modifient ou inactivent un ticket.
Agents connectés à plusieurs appareils
Les agents connectés à Zendesk sur plusieurs appareils peuvent empêcher le système d’enregistrer les tickets en cours de traitement. Cela peut entraver le bon fonctionnement de la collision d’accès.
Prise manuelle des tickets
Si les agents utilisent le bouton Play et qu’un agent prend un ticket manuellement, cela peut provoquer une collision d’accès (voir scénario 1 ci-dessus).
Traduction - exonération : cet article a été traduit par un logiciel de traduction automatisée pour permettre une compréhension élémentaire de son contenu. Des efforts raisonnables ont été faits pour fournir une traduction correcte, mais Zendesk ne garantit pas l’exactitude de la traduction.
Si vous avez des questions quant à l’exactitude des informations contenues dans l’article traduit, consultez la version anglaise de l’article, qui représente la version officielle.
0 Commentaires
Vous devez vous connecter pour laisser un commentaire.