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 lit des tickets à partir d'une vue et que l'on s'attende à ce que le système évite les collisionsd'accès et ne leur donne jamais un ticket pour lequel un autre utilisateur est actuellement présent.
Cette fonctionnalité fonctionne comme défini ci-dessus si :
- Tous les tickets de cette vue ne sont jamais consultés par quelqu'un d'autre que ce groupe.
- Chaque agent du groupe lit toujours ces tickets en utilisant le bouton Play
- Aucun agent n'est autorisé à ouvrir les tickets d'une autre façon à partir de la vue.
Cependant, il existe quelques scénarios dans lesquels un agent en mode Play peut recevoir un ticket qui a déjà un utilisateur. Dans cet article, nous expliquerons ces scénarios et comment les éviter.
Cet article aborde les sujets suivants :
Pour en savoir plus sur les collisions d'agents et le mode Play, consultez Utilisation des tickets.
Scénarios de collision d'agents potentielle en mode Play
Il y a trois scénarios relativement courants qui peuvent déboucher sur des collisions d'agents en mode Play :
Scénario 1 : Un autre agent ouvre manuellement un ticket
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 manuellement ce ticket (par ex. après l'avoir trouvé lors d'une recherche). L'agent en mode Play verra alors qu'il y a quelqu'un d'autre sur son ticket et pensera 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 que vous jouez ces tickets, tout semble aller bien. Puis A part pour le déjeuner, avec un onglet de ticket ouvert. (Supposons le ticket T). Elle est en ligne pour le ticket T, puis pendant le déjeuner, un problème survient : elle perd la connectivité réseau. Cette perte peut être due à une panne d'Internet pendant un certain temps ou à la 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 est concerné par le ticket.
L'agent B reçoit alors le ticket T servi pendant le jeu et il travaille sur le ticket. C'est à ce moment-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 désormais en ligne pour le ticket T. B voit cela et dit : Je croyais que ce bouton Play n'était jamais censé me donner des tickets que d'autres agents consultent !
Scénario 3 : Perte de connexion hors du mode Play
Supposons que ce qui suit se produise :
- 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 un message lui indique que le ticket est aussi ouvert avec l'agent B.
- L'agent A perd la connectivité Internet et le message reste
- L'agent B clôture le ticket T
- L'agent A revient en ligne et voit toujours le message, même si l'agent B ne fait plus partie du 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 d'un agent, vous devez vous pencher sur les points suivants :
Vider le cache du navigateur et vider les cookies
Zendesk utilise divers cookies pour gérer la présence des agents. Par conséquent, si vous rencontrez des problèmes, les agents doivent d'abord actualiser ces cookies régulièrement. Consultez Options pour vider le cache et les cookies pour savoir comment faire.
URL de présence d'agents
Les connexions à Zendesk pour vérifier si un agent participe à un ticket ne se font pas via la même URL que les demandes adressées au reste de Zendesk (par ex. mydomain.zendesk.com), mais 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 aurait pu être n'importe quel nombre compris entre 1 et 4
Les URL suivantes devraient donc être autorisées pour ce compte, ainsi que 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
De longues périodes d'inactivité des agents
Une collision d'agents peut survenir en cas 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 Comment éviter les collisions d'agents pour savoir comment identifier les agents qui consultent, modifient ou restent inactifs dans 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 sur lesquels ils travaillent. Cela peut entraver le bon fonctionnement de la collision d’accès.
Prise en charge 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 le 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.