Automatically assign a follow-up ticket to the original group / assignee
Hello Zendesk. We are also struggling with this. We are an enterprise customer with multiple brands, multiple forms, multiple groups. We have 4 new groups onboarding with very high ticket volumes. There is a high percentage of Follow-Up tickets that have to be manually assigned to the group they originated from. I cannot understand how a new ticket emailed in can follow triggers to map to the correct groups but the follow-up tickets cannot follow that same path, they retain every other bit of form information. Is there a workaround that does not require a bunch of additional triggers to facilitate this? Thank you to anyone who has advice on this.
Thanks for reaching out in the Community!
If I understand correctly, your triggers set up to route tickets to the correct agents/groups work perfectly well for newly created tickets, but are not applying to follow-up created tickets. Is that correct?
Not being able to see the specifics of the triggers, I can't say exactly what the solution would be, but I've outlined an example below that might be what you're dealing with or at least provide useful concepts you can apply to your situation:
Imagine you had a trigger that routed all tickets created through the Web Widget to a certain agent group:
In this case, the trigger won't apply to follow up tickets because follow up tickets are actually created through the channel "closed ticket". So you can either clone that trigger and create an identical one where you change that one condition to "Channel is closed ticket". Or if you have no conditions in the "any of the following" conditions section, you can do this:
That's just one solution to one scenario. But hopefully it helps!
If you'd like to share an example of a trigger/scenario you have where the follow ups aren't routing correctly I can definitely tackle that specifically and try to get you up and running! If you'd prefer to work on this in a private ticket we can do that as well.
Let me know!
My large enterprise organization has the same challenge as Jennifer's. The issue with the trigger you shared is that we have no way to identify what group the ticket previously belonged to, which is instrumental for the "group = support" action. We have many groups per brand that consist of very different groups of resources that support very different products and services. As such, we cannot just assume that a ticket belongs to a given group based on the brand for which the ticket was created (and channel being closed ticket) - we need to know which group or assignee was handling it. Are there any other ways?
As it stands right now, we are forced to tell our end users to create a new ticket when they attempt a follow-up, because the effort it would require to manually distribute these tickets to the appropriate groups would be cost prohibitive for our agents.
Would love a solve for this one as well. We have many different groups, but the Group doesn't get attributed to follow-up tickets, so we can't send follow-ups 'back' to the group it belongs to. If there's a fix for this in the roadmap, that would be great to hear.
If you haven't found a solution yet, I can help with this: sign up with the API Lookup app and I can configure it to automatically fill in the Group for follow-up tickets.
We have the same issue here at my large enterprise. We have many groups supporting the entire HR function.
Colleagues submits a form.
That form can get moved between 2-6 different groups
Ticket is solved
Ticket is closed
Colleague creates follow up
Ticket either goes back to the initial group rather than the solving group
Tickets are private so different groups can't see other groups tickets. I end up stuck and using 3 triggers per group would result in thousands of triggers!
Same issue here. We need a better way to handle follow-up tickets with users.
This is the way I think could work for everyone. It includes a few triggers and tags.
Follow-up tickets inherit tags. We can use this to assign them to the group the original ticket was assigned to. For this, I add a unique tag per group on every ticket created.
- Ticket is created, assign to group1
- Add tag tag_group1
Remove tag trigger:
If the ticket is updated and assigned to a different group (e.g., group2), remove tag_group1, add a new tag of the newly assigned group (e.g., tag_group2). This helps avoid assigning a follow-up ticket to the wrong group.
Follow-up group assignment trigger:
Assign to the group.
Fernando's workaround does work, but you have to have a separate one for each group (or agent) and that may not be practical for all uses. It really seems like the ability to create a follow-up should go hand-in-hand with the ability to reassign.
But, of course, it also seems like merging should come with an unmerge.
The software is cool, but I am shocked we don't have an option of Auto reassigning of Follow up tickets.
I tried to explain to the support agents of Zendesk even though they are not understanding it, strange - But I could see most of us facing a similar problem.
I have 2 agents A & B.
Our client raised an issue requesting to change his account mobile number and the client didn't share the mobile number in the first email. And the ticket id is 100.
So the ticket first got assigned to agent "A". And agent A requested the client to share the mobile number so he can update it to the account, then agent A kept the ticket in "Follow up/ Pending"
The agent is done with his shift and logged out.
After agent "A" is logged out, the client replies to the same email chain the ticket id is 100 -- and the client says this is my mobile number please update it.
Here my agent B is online now, but agent B is not been assigned that specific ticket: 100.
1) The biggest challenge is that these replies are going to agent A's follow-up ticket.
2) Till Agent A joins the shift the client has to wait, but agent B is not been reassigned with the ticket.
This is the biggest challenge or drawback I could say and it would be a bigger issue for us to use this tool...
I wish someone could help us on this, but seeing the above comments it makes me think Zendesk doesn't have it :-(
Please sign in to leave a comment.