Automate Your Bump, Solve, Close - Part 3

Bump, solve & close refers to specific actions taken within a ticketing platform such as Zendesk to manage and resolve customer issues or service requests more efficiently.

In this post, we'll address the close stage.

Previously I described the solve stage of the bump, solve and close process. I gave examples of how to automate solving your tickets to free up your agent's time for more important things. You can find that post here.

This post looks more closely at the close stage of the ticket lifecycle and how you can:

change the timeframe a post moves from Solved to Closed status
prevent Zendesk from auto-closing your tickets when 28 days pass

Some Background

By default, Zendesk enforces auto-close of tickets 4 days after moving to Solved status.

Adjust the system automation Solved > Closed by setting this between 96 and 672 hours

📒 Important Note

Keeping tickets open longer is not good practice but there may well be specific use cases you have where it's better to keep the ticket in Solved status than Closed.

You can find the specific details of that in Zendesk's article About the standard Support automations.

After it auto-closes, it cannot be edited or re-opened so the Requester must create a follow-up ticket if they want to continue the conversation.

Let's look at two ways to influence that built-in auto-close action if you absolutely have to keep the ticket open.

Change the timeframe a post moves from Solved to Closed status

The system automation 'Close ticket 4 days after status is set to solved' can be changed to any timeframe between 1 hour and 672 hours (28 calendar days).

Simply set the number of hours to your preferred timeframe in the action:

Ticket: Hours since solved > (calendar) Greater than > 96 hours

If you try to set this number higher than 672, it will still max out at 28 days.

Prevent Zendesk from auto-closing your tickets after 28 days

Circumventing the system automation is possible but as mentioned, it's not best practice. Normally, 28 days should be plenty of time for the Requester to determine if a ticket is truly solved or not. However, you may have special use cases. Some examples are:

validation of the solution depends on a time-specific event that occurs > 28 days from the time the ticket is solved.
the person who needs to validate the solution is unavailable

We can prevent the auto-close by implementing two automation. The first one sets the ticket status to Open and the second immediately sets it to Solved again. They are done carefully and only under specific conditions.

We also use a mute tag to prevent notifications that would otherwise be sent when a ticket is re-opened or closed.

No Auto Close Stage 1

This automation sets the ticket status to Open under the defined conditions.

Create a new automation and set the All conditions as shown:

Ticket: Status category > Is > Solved
[only acts on tickets in Solved status]
Ticket: Hours since status category solved > (calendar) Is > 671
[This assumes you have adjusted your system automation 'Close ticket 4 days after status is set to solved' to 28 days / 672 hours. If not, set this value to 1 hour less than the system automation.]
Ticket: Tags > Contains at least one of the following > no_auto_close
[This checks the ticket for the presence of the tag no_auto_close]
Ticket: Tags > Contains none of the following > no_auto_close_reset
[This avoids the automation running multiple times on the same ticket]

Set the Actions as follows:

Ticket: Status category > Open
[Sets the status of the ticket to Open]
Ticket: Add tags > mute
[Adds a mute tag. We use this as a condition on all notifications so we can control the muting of notifications on specific tickets]
Ticket: Add tags > no_auto_close_reset
[This is used as a condition in both stage 1 and 2]

No Auto Close Stage 2

This automation immediately solves the ticket again.

Create a new automation and set the All conditions as shown:

Ticket: Status category > Is > Open
[only acts on tickets in Open status]
Ticket: Tags > Contains at least one of the following > no_auto_close
[Checks that we're acting on a ticket in scope of our No Auto Close routine]
Ticket: Tags > Contains at least one of the following > no_auto_close_reset
[Checks that this ticket is waiting to be re-solved]

Set the Actions as shown:

Ticket: Status category > Solved
[Solves the ticket once again]
Ticket: Remove tags > mute
[Removes the mute tag we set before to suppress notifications]
Ticket: Remove tags > no_auto_close_reset
[Removes the tag triggering these actions.]

💁🏽 Pro Tips!

Reporting: Consider that any reporting will show these tickets as re-opened. You can use tags to adjust your reporting accordingly.
no_auto_close_reset tags: It would be possible to omit the no_auto_close_reset tag and just base our conditions on status alone but this gives an extra level of control. If something goes wrong it makes it easier to find and troubleshoot, search tickets, etc.
mute tag: I use this tag across my entire implementation to allow the muting of notifications on tickets by simply adding/removing it. If you don't use this then your notifications will trigger!