Using Zendesk Support can often create a back-and-forth dialogue between agents and end-users. It's pretty common for agents to set a ticket to the Pending status when they're waiting for an end-user to reply. But what happens when the end-user doesn't respond? In a default environment, the answer is simple: nothing happens. Unless an agent goes in and personally solves out the ticket, or nudges the customer for an update, those tickets will sit in the Pending status until the end of time.
However, 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.