In the Business Rules best practices section of Zen U I go over several unique use cases of how to use Zendesk's triggers and automations. For those of you who couldn't make it or just wanted to see them again to adapt and add to your account, I have added them here with a quick description of how they are intended to function.
The Abandoned Ticket Automation
This Automation is configured to pick up any ticket that has been neglected by a support agent. The automation will look for tickets that are abandoned for whatever reason (Requester update 48 hours ago and the Status as open to prevent false positives when the agent is waiting for a response in pending) and check that the ticket is supposed to be worked on by someone (Assignee is not -) to prevent your manager from being flooded if start to fall behind your SLA. This was originally inspired by a customer that had an agent go on vacation and had forgot to reassign all of that agent's currently open tickets. This would also be useful to make sure that your agents are not avoiding certain tickets and offering your customers a speedy response.
Add Current User as a CC when Escalating a Ticket
This is a fairly straight forward trigger, but can be very useful in preventing bad satisfaction ratings when you escalate a bug or another ticket to a group that does not directly interact with your end users. The trigger will look for any ticket that has its group changed to your Development group and add the level 1 support agent as a CC so they can stay updated and keep your end user informed. This trigger was created from a customer that noticed that his developers liked to communicate with each other in private comments, but did not publicly update the end user even on tickets with significant behind-the-scenes work being done.
Unassign a Ticket Within the Same Group
This is a trigger that will allow you to counteract a built in feature of Zendesk to prevent cherry picking. Many of you may have noticed that Zendesk will prevent you from unassigning a ticket from yourself when you keep the group the same. This was included to prevent agents from unassigning tickets that they feel are too hard so they can go back in the queue and grab easier tickets to pad their statistics. This trigger will look for when a ticket is updated and look for a specific tag being added (the tag can be whatever you want as long as the tag removed in the action is the same as the tag being checked) and then bypass the cherry picking protection and set the assignee of the ticket as -. If you do not have tags enabled for your agents or don't want to leave the possibility of misspelling the tag, you can easily do this with a custom ticket field checkbox. Just replace the Tag conditions in the screenshot above with a condition for your custom ticket field, and reset the checkbox in the action section.
Remove Tags from a Follow Up Ticket
This trigger is also fairly simple in design, but I have found that this functionality is less widely know by Zendesk administrators. This trigger was inspired from an actual call that I took working as a Zendesk Advocate and was designed to prevent tickets from skipping workflow processes that the admin had set up using an elaborate system of tags. When a ticket is set to closed from solved (this will occur by default after 4 days but can be changed to up to 28 days by editing the system automation) it is archived and cannot be updated. If an email response comes in from a customer that had been holding on to an email notification a new, linked, ticket will be created with the ticket fields from the closed ticket pre-populated. If this follow up ticket happens to be a completely new request, instead of your agents asking the end user to submit a new ticket with a clean email, this automation can prepare the ticket to be worked on as a completely new ticket. The trigger will look for newly created tickets that were created through the closed ticket channel (this means any ticket created as a follow-up ticket). The set tag action will remove all current tags and add the ones you indicate, but if you leave the field blank, all current tags will be removed and the ticket will be wiped clean.
Time Delayed Comment
(This first screenshot is a Trigger)
This business rule is a combination of a trigger and an automation and was thought up from a live question asked during our first Zen U event in Vancouver. This was created for the rare circumstance where you would want to delay when your response is sent to your end user. Although this is not a recommended best practice, it does showcase the power of Zendesk's business rules and will hopefully inspire a use case that works for you account. You will first need to set up business hours on your account, you can find out how to do that here: https://support.zendesk.com/entries/23245768-Setting-your-business-hours Once you have this up, you can start by creating the trigger in the first screenshot. This trigger will look for comments that would have been sent out to the requester and will add a tag if the comment was added after your business hours. You will need to add a condition to your other 'Notify requester' triggers of 'Tags contains none of the following delayed_message' to make sure that your normal method of communication does not fire and leave you with a double notification. Once the tag has been added, the automation in the second screenshot will begin checking the tickets with this tag and once your business hours start up again it will send your last public out to the requester.
Post is closed for comments.