Using business rules, you can set time intervals to first notify the requester that you're waiting for a response and then eventually notify the requester that the dormant ticket has been marked as solved. Below we'll go over the steps required to setting up this process of notifying and then solving out dormant pending tickets—or as we refer to it in our own workflow, the "Bump-Solve process".
For the purposes of this example, let's assume that you want to notify (or "Bump") the ticket requester after four calendar days and then solve out the ticket after seven calendar days, but you can use a different time interval and/or business days instead, depending on what works well for your workflow. This process will involve creating three new business rules:
- An automation which will "bump" the ticket requester after the ticket has been Pending for four days
- An automation which will solve out and notify the customer three days later
- A trigger which will be used to reset this process if/when the customer responds after either of these notifications.
The bump automation
This automation is the first one that will run on your pending ticket. You'll want to set conditions and actions that will ensure that the automation runs only once per pending status and that it runs only after your designated period of time (in this case, four calendar days). As such, this automation will be adding a unique tag to the ticket (and checking that it's not there) as well as notifying the requester. The automation you set up should look something like this:
You'll notice that the "Tags contains none..." condition in the example above actually will check that two tags are not present on the ticket. The first tag, "bump1", will be used to signify that the automation has already fired and the customer has been notified. I've used "bump1" here so that you can differentiate between notifications if you decide you want to notify the customer more than once before solving the ticket.
The second tag, "dont_bump", can be used as a fail-safe by agents if they do not want this automated process to occur for any particular ticket. If this is the case, the agent will need to manually enter the "dont_bump" tag to the ticket to prevent these automations from running.
If you do decide to implement a second bump to this process (after six days of pending, let's say), the second bump automation would need to be set up like this:
You'll notice that this second automation has some different condition times as well as two new conditions. The first new condition checks that the "bump1" tag has already been added to the ticket. The second new condition checks that the ticket was updated longer than two days prior (when the first automation ran) to ensure that when you first implement this process, your end-users will not all be notified and then notified again an hour later or at the same time. A customer's response to the notification will reopen the ticket and our clean-up trigger will need to remove all of the bump tags from the ticket to reset this process.
The solve automation
Now that you've notified your requester once (or maybe twice) and given them adequate time to respond, you'll want another automation to come in and close the ticket. This automation will need to do two things: solve the ticket and notify the requester. If you've only set up one "bump" automation, you'll want the conditions of your solve automations to look like this:
If, however, you've decided to set up two bump automations, the conditions of the solve trigger should be set up like this:
These conditions will differ slightly based on the number of bumps you've implemented, so make sure you're using the correct ones. Regardless of how many bumps you use though, the actions of the trigger will still look the same:
When this automation fires, the requester will be notified that the ticket has been solved. If they respond to the notification before the ticket changes from solved to closed, the ticket will be reopened and the clean-up trigger should fire as well.
The clean-up trigger
As hinted at above, the clean-up trigger will be used to remove any of the bump-solve process tags if the ticket is reopened. The reason for this is so that if the ticket is reopened and the agent responds and sets it back to pending, this process can run again, even though it has already run. Your clean-up trigger should be set up in the following way:
And that's all there is to it! With these three or four business rules, you'll have an automated process that will automatically remind customers that you're waiting for their response and eventually solve it if they don't. You'll no longer have to worry about managing pending tickets.
21 Comments
I was trying to implement this set of automations (why aren't they available by default!?), but the last one cannot be implemented, because the "Changed from" option isn't available. What gives?
Hey Eric! Welcome to the Community!
Automations are time-based business rules that fire at intervals of time, rather than on a ticket update, so you wouldn't be able to use an action like "changed from" to make it fire. If you need a business rule to fire based on whether the status of a ticket has been changed at the time of update, you'd want to use a Trigger.
Let us know if you have any other questions!
Ahh...the final automation detailed above is not an automation--it's a trigger! That makes sense now, but was unclear above. Thanks!!
Glad I could help! Have a great weekend. :)
Hi,
Is there a way to building out these automation/trigger rules without having having them fire off immediately after submitting?
The idea is to have everything mapped out, reviewed and then "go-live".
Thx
Welcome to the Community, Adrien!
For clarification, do you mean that you want to be able to basically stage all your triggers and automations and then flip a switch so they all activate at the same time? Or am I misunderstanding your question?
Hi there-
Working on the second automation (to solve) and am receiving this error:
Any suggestions? Thanks!
Kinsley
Hi Kinsley!
This just means that you need some kind of condition in the automation that will prevent it from running over and over again on the same ticket. Most folks opt to use a tag for this.
In your conditions, you would specify something like Ticket: Tags > Contains none of of the following > bump_solve.
Then you'll include an action in the automation that adds the tag: Ticket: Add tags > bump_solve.
So, when your automations run, this one will test each ticket for the bump_solve tag. If it doesn't see the tag, it will run the automation and add the tag, along with whatever other actions you want it to take.
The next time your automations run, those tickets won't be included because they have the bump_solve tag, and the automation knows to skip them.
Let us know if that's not clear!
Can you all please use higher resolution screen shots for your help guide articles? These especially are really low resolution and very hard to read any of the text
Hi Sunee! Welcome to the Community!
Thanks for the feedback on this; I'll be sure to pass it along to our Documentation team to let them know!
I was creating a trigger for collecting surveys from customers. Is it possible that one customer receives a trigger just once, no matter how many ever tickets the customer creates.
Hi Shubham! Welcome to the Community!
The easiest way to ensure that a user doesn't receive a notification multiple times is to add a User Tag. Every ticket that user creates will inherit that tag. You can then set up the Trigger in question to only fire when that tag is NOT present.
I'm sorry. I have 2 questions.
1. Do we need create a trigger to add tag bump first?
2. Why is there a condition hours since update? What will happen if there is no such condition?
Hello,
Once an automation email notification is sent to the requester, is that notification attached to the original ticket?
Thanks.
@Wit - You don't need to add a "bump" tag to every ticket; rather, you should have a "no_bump" tag that you add to tickets that you DON'T want the bump automation to run on, and then add a condition to the automation so that it only runs when that tag is NOT present.
The "Hours since update" condition is necessary so that Zendesk will know when to run the automation. If you don't add such a condition, the automation won't ever run.
@Christine - Just like with Triggers, the email notification isn't added to the ticket. However, if you set the automation up the way Joe illustrates here, there will be a tag on the ticket that will show where in the bump process the ticket is.
Hi There,
I have implemented this solution in our Zendesk instance. Would like to get some suggestions with regards to the reporting aspect. What is the best way to filter through or distinguish the tickets solved by the automation against those tickets manually solved by the agent? I believe the bump_solve tag can be used as the identifier but are there other steps that I might be missing?
We created a drop down field with different outcomes. Tickets solved by automation both add a tag and change this value.
You don't even need to put the field on the ticket form to confuse agents. the automation can still set the value on the ticket anyways. The dropdown field makes reporting a lot easier.
Hi Dan,
Thanks for the tip. I added an additional tag in the bump solve automation to differentiate the tickets solved by the automation and added a remove tag condition in the clean-up trigger for these additional tag. You mentioned that you added a drop down field but not in the ticket form. Where did you add this drop down field? I'm thinking of trying this.
Thank you.
I just made a ticket field and have automations update the field. You don't have to put it on the form for the update to apply, it seems. A ticket is a ticket, the form is just a means to differentiate for the user in the UI what fields they should use.
Is there a way to send a daily/weekly reminder (digest) to ticket assignees to remind them of tickets they have unsolved? Other ticket systems use "subscriptions" based on a query to carry this out, but not sure I see this in Zendesk since it seems I'd have to set up a trigger every day with a different time interval each time. Please advise.
Hi Jimmy -
The best practice we typically suggest is for agents to have a view of all of their tickets that are less than solved, and to work out of that view on a daily basis. However if your agents aren't regularly working out of Support, there are a couple of other things you can do:
Set up an Automation
While there isn't a digest function that would batch all of the unsolved tickets for an agent into a summary, there are automations that you could set to fire on each unsolved ticket an agent has. There are conditions for automations that are time-based, for example, you could have it send the assignee a notification if a ticket has been sitting in, say, open status for X number of hours.
SLAs
If you're on a plan type that includes SLAs, there are some that you could apply that would help to remind your agents when they're running up against a window of time you'd like them to respond by.
Insights reports
If you use Insights, you could schedule a report to run and send on a daily basis that would let users know how many tickets they have unsolved. They wouldn't be able to click from the report into the tickets, but it would be a reminder system.
Let us know if any of those might work for you and if you need additional information.
Please sign in to leave a comment.