Question
Why does Zendesk Chat update the assignee or group of a recently ended chat?
Answer
When a Chat ends, the integration adds a comment update to the ticket with the string Chat ended. Right after that, the integration applies a zopim_chat_ended
tag and updates the ticket to ensure the agent who served the chat is assigned the ticket in their default group.
Since this is expected behavior, we encourage agents to wait until the zopim_chat_ended
tag appears on a ticket to change the group or assignee. If a trigger is being used to make these changes, the trigger should include criteria for that tag.
If this behavior doesn't suit your needs, you may want to consider switching to the Zendesk Agent Workspaces.
3 comments
Michael Mader
I am having the same issues as Laura above and with our SLA's we cannot account for the "few hours ago" time frame, which I wouldn't consider a "slight time delay". I would appreciate it as well if this could be brought up. Our agents are trained to hit "end-chat" after their conversations, however, the customer is still able to do this same action which results in the changing of the ticket assignee and group.
Our Tier 2 team is struggling with this, as they start working the ticket right away upon escalation, then it just disappears from their queue and they are no longer the assignee (this prevents them from even seeing the ticket until our Tier 1 team RE-ESCALATES) which is taking 2 agents away from helping customers effectively.
Thanks!
0
Tom Verkooijen
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.
2
Trevor Kanaya
Just went through literally the exact same odyssey as Tom. Each ticket escalation macro adds a tag unique to the team it's being escalated to, and I thought maybe we could use this to create a trigger (unfortunately, one for each macro of which there are dozens, but would have been willing to do the work if this would be a solution) that would catch the reassignments by the Zopim integration and reassign them back to the intended escalated group.
But
I was even into the weeds with Zapier seeing if there was a way we could reroute those tickets in a "smart" way but unfortunately there's no way to say "change it back to the group and/or assignee that it was prior to 'x' update". "Current user" won't work because if the escalated agent has assigned the ticket to themselves but hasn't updated it yet, then the ticket will just go back to the original agent that served the chat. Every possible solution is riddled with holes.
If anyone else comes up with a solution to this, I'm certain this will help a lot of people work around this currently very faulty assignment logic.
5