Recherches récentes
Pas de recherche récente

Tom Verkooijen
Adhésion le 13 mai 2021
·
Dernière activité le 16 oct. 2021
Suivis
0
Abonnés
0
Activité totale
1
Votes
0
Abonnements
0
APERÇU DES ACTIVITÉS
BADGES
ARTICLES
PUBLICATIONS
COMMENTAIRES DE LA COMMUNAUTÉ
COMMENTAIRES SUR L’ARTICLE
APERÇU DES ACTIVITÉS
Dernière activité effectuée par Tom Verkooijen
Tom Verkooijen a ajouté un commentaire,
I have the exact same scenario and problem that Michael highlights with one of my clients. The problem is that for end users it is not intuitive to end the chat. So most likely it times out after 20 minutes, when the chat agent has already moved on to other tickets/chats. And with the SLAs being 30 minutes on urgent issues, we can't wait 20 minutes to make the Tier-2 assignment, or wait for an hourly automation to make the Tier-2 assignment.
It is a major productivity and service level inhibitor. Is there any line of sight into a solution for this? The only thing I could think of was making agents set a Tier-2 team (of which there are 15) on the chat via a tag, and when the zopim_chat_ended tag is set, re-assign the ticket to the Tier-2 team based on that tag. But if the ticket was already assigned to a specific agent, that agent assignment is undone, which is still very frustrating to the Tier-2 team. However... the zopim integration that assigns the ticket to the chat agent and default group appears to always as a final step be assigning the agent to the chat user. So even though the trigger looks for the condition that the group is set back to support, and that condition is met, the zopim integration fires after the triggers are run, so there really is no event we can anchor on to affect that.
Afficher le commentaire · Publication le 01 mai 2021 · Tom Verkooijen
0
Abonnés
2
Votes
0
Commentaire