Recent searches
No recent searches
Help with fixing triggers for tickets that haven't been responded to by an agent
Posted Jan 23, 2024
So far, I have set up 4 triggers and 1 view for this issue.
View "Tickets That Need a Reply" - All tags with needs_reply or needs_first_reply is going into this view - this part is fine, it's the triggers I need help with!
The triggers are set up to tag tickets that need a reply (it's like having unread messages/messages not responded to)
Can someone help me see if there's a better way to do this? Thanks! See below:
Trigger #1: New tickets that need first reply
Description: Any new ticket that is not created by an agent needs to be tagged with needs_first_reply
Trigger #2: Open tickets that need reply
Description: Any open ticket that is not responded to by an agent and the requester has responded to us (the ticket is updated by not by agent) needs to be tagged with needs_reply
Trigger #3: Remove the tag once replied
Description: Removes tags once an agent responds, so it gets out of the "Tickets That Need a Reply" view
Trigger #4: Remove tag once created
Description: Removes tags so new tickets that are created by agents are not being tagged for some reason, is there a better way around this and include this in Trigger #1 somehow?
Issues: Sometimes, tickets are not being tagged due to some reason I can't figure out. Some tickets get left not being responded by agents to unless they check our other views (want to avoid this). I want to make sure this is automated with triggers, so the tickets are being shown in "Tickets That Need a Reply" properly.
The last trigger was created because it kept tagging as needs_first_reply when the agent is the one who created the ticket, and it shouldn't be tagged based on the agent not requester (usually the customer) being the one who created the ticket or sent the email/text out.
0
3 comments
Brandon (729)
Hey there Sandy,
Welcome to the community! Let me preface this by saying that, as with most things in Zendesk there are several ways to tackle this problem. The easiest might be to deploy Zendesk SLAs.
Short of that, working through your Triggers i would make the following adjustments:
Trigger #1 - move your negating Triggers condition (Tags does NOT contain) to the ALL section. This ensures that if even one of those tags is present, regardless of the subject line or other tags, the Trigger will not fire. You can also add an ALL condition here for Current User is end-user, thus removing the need for Trigger #4
Trigger #2 - I would add the ALL condition, Ticket Status (or status category) is or is changed to open (or is not / is not changed to solved), assuming you only want this to fire when the ticket is brought back to an open status.
Trigger #3 Looks Good
With these adjustments, things should fire as expected. There is also a view column on last updated by "Agent / End-User" that you may be able to leverage to streamline this effort.
Give it a go and let us know if things are working better!
Brandon
1
Stephan Marzi
Hi Sandy,
Brandon is always the fastest community member with a great expertise. I would add to Brandons advice the following:
Trigger #1 - adding to status category new to ALL
Trigger #2 - follow up symbols are also useful to show the update as well
Trigger #3 - it should run without problem (if using a follow up you can also remove this)
Trigger #4 -
Regards,
Stephan
0
Mark Leci
Definitely agree that SLAs are a better approach here and I would really strongly advise that you use them. I've found that using non best practice or more complex methods tends to spring surprises later on (we've had multiple issues in this area!) and is really only a good idea when the built in functionality doesn't meet your needs. I don't expect that's the case with Zendesk SLAs though since you can do quite a bit of heavy lifting with them, particularly once you include triggers or automations. And you can of course build views based on the SLAs.
I would also be interested to hear the whole process you're using. When an agent adds a reply, are they marking the ticket as pending? If so, trigger 3 isn't really needed. And if not, you're probably losing out on metric data that could be useful.
0