Recent searches


No recent searches

Why does Chat update the assignee or group of an ended chat?



image avatar

Anna Lainfiesta

Zendesk Employee

Edited Jan 19, 2024


-9

3

3 comments

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


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


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

  1. Zopim action would happen after so all of this would be pointless, and
  2. Even if it did work, we'd still have the aforementioned issue where if the ticket had been assigned to an agent within the escalated team, that assignee would be stripped and you'd be back to it being only in the group with a null assignee, which is far less than ideal.

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


Please sign in to leave a comment.