Le mode Play présente automatiquement les tickets qui ne sont pas en cours de consultation par d’autres agents. Ainsi, un groupe de personnes pourrait jouer les tickets à partir d’une vue, en supposant que le système évite les collision d’accèset ne leur donne jamais un ticket auquel un autre utilisateur est actuellement affecté.
Cette fonction fonctionne comme défini ci-dessus si :
- Tous les tickets de cette vue ne sont jamais consultés par quiconque n’appartenant pas à ce groupe
- Chaque agent du groupe joue toujours ces tickets en utilisant le bouton Play.
- Aucun agent n’est autorisé à ouvrir les tickets à partir de la vue d’une autre manière.
Cependant, dans certains cas, un agent en mode Play doit recevoir un ticket auquel quelqu’un est déjà affecté. Dans cet article, nous allons vous expliquer ces scénarios et vous expliquer comment les éviter.
Cet article aborde les sujets suivants :
Pour en savoir plus au sujet des collision d’accès, consultez Élimination des collision d’accès. Pour en savoir plus au sujet du mode Play, consultez Utilisation du mode Play.
Scénarios de collision d’accès potentielle en mode Play
Il y a trois scénarios assez courants qui peuvent déboucher sur des collision d’accès 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é dans une recherche). L’agent en mode Play voit alors qu’il y a une autre personne dans son ticket et pense que le mode Play ne fonctionne pas correctement.
Scénario 2 : Perte de la connexion en mode Play
Supposez que les agents A et B utilisent le mode Play. Pendant la lecture de ces tickets, tout semble aller. Puis A part pour le déjeuner, avec un onglet de ticket ouvert. (Disons le ticket T). Elle est en ligne sur le ticket T, mais pendant le déjeuner, un problème survient : elle perd la connectivité du réseau. Cette perte peut être due à une panne d’Internet pendant un moment 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 qu’il est dans le ticket.
L’agent B reçoit ensuite le ticket T pendant le jeu et travaille sur ce ticket. C’est là que l’agent A termine son déjeuner et appuie sur une touche de son ordinateur portable. Il s’exécute et l’agent A est maintenant en ligne sur le ticket T. B le voit et dit : « Je crois que ce bouton Play n’était jamais conçu pour me donner des tickets que d’autres agents seraient en train de consulter ».
Scénario 3 : Perte de la connexion hors du mode Play
Supposez que ce qui suit a lieu :
- L’agent A et l’agent B n’utilisent pas le mode Play.
- L'agent B ouvre le ticket T
- L’agent A ouvre ensuite le ticket T et voit un message lui indiquant que le ticket est aussi ouvert avec l’agent B.
- L’agent A perd la connectivité Internet et le message est conservé
- L'agent B ferme le ticket T
- L’agent A revient en ligne et voit toujours le message, même si l’agent B n’est plus sur le ticket
Identification et gestion des collision d’accès en mode Play
Pour identifier et résoudre les problèmes liés au mode Play ou à la présence d’un agent, consultez les sections suivantes :
Effacer le cache et les cookies du navigateur
Zendesk utilise divers cookies pour gérer la présence des agents. Si vous rencontrez des problèmes, les agents doivent donc commencer par actualiser ces cookies régulièrement. Consultez Options pour effacer le cache et les cookies pour savoir comment procéder.
URL Présence de l’agent
Les connexions à Zendesk permettant de vérifier si un agent est sur un ticket ne se font pas via la même URL que les demandes au reste de Zendesk (comme mydomain.zendesk.com), mais via une URL du formulaire pubsub-shardC-P-N.zendesk.com, où :
- C est le cluster du compte (une 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 Chrome pour les développeurs 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 pourrait être n’importe quel nombre compris entre 1 et 4
Les URL suivantes doivent donc être autorisées pour ce compte, ainsi que dans votre VPN, pare-feu et tout logiciel antivirus que vous utilisez :
-
https://pubsub-shard2-17-1.zendesk.com -
https://pubsub-shard2-17-2.zendesk.com -
https://pubsub-shard2-17-3.zendesk.com -
https://pubsub-shard2-17-4.zendesk.com
Périodes d’inactivité des agents pendant de longues périodes
Une collision d’accès peut se produire en raison de longues périodes d’inactivité sur 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 collision d’accès pour savoir comment identifier les agents en train de consulter, modifier ou inactif 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 de tickets
Si des agents utilisent le bouton de lecture et qu’un agent prend un ticket manuellement, une collision d’accès risque de se produire (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.