Resolve tickets sooner, improve communications and Increase customer satisfaction rating by optimising your bump, solve, and close procedures.

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 bump stage.

Three stages of the ticket lifecycle can be described as:

Bump

When a ticket has reached a particular point in the process such as:

breaching an SLA
the ticket has aged
a period of time passes while waiting for an internal group or 3rd party to take action or respond

In these situations, the support team can 'bump' the ticket by entering a comment (following up), adding a tag, changing the priority or some other action to bring the ticket to attention. Without this, the ticket may go stale and get forgotten about.

Solve

It sounds obvious and means resolving the ticket by setting the status to Solved. Not surprisingly, tickets that are solved don't always actually get moved into Solved status. When this happens we need to employ creative ways to ensure tickets don't go stale here too.

Close

When no further action is required after a ticket is solved, it should be closed. Zendesk by default will close tickets in Solved status after 4 days of changing to Solved but, if preferred, it can be immediate or up to 28 days.

Need longer than 28 days? That can be achieved too.

Look familiar? Implementing an effective bump, solve, and close procedure can eliminate these situations.

Solution

By addressing each of the 'bump, solve, close' stages using automation we can effectively mitigate the risks, and ensure a high level of customer satisfaction.

The following sections describe two possible approaches but proceed with caution!

Every support org has its own set of customers with their own needs and service level requirements. Ensure you adapt accordingly to your situation.

Semi-automating bump stage with a 👁️Watch List👁️

This is the most important stage because a well-designed bump automation can re-bump if the ticket remains ignored.

One semi-automated approach is this:

Create a single view called 👁️Watch List👁️ which is configured to only show tickets with the tag t_watchlist. The view is placed at the very top of the view pane in the agent workspace.
We then build automations with various conditions which, when met, add the tag t_watchlist to the ticket thus making it appear in the 👁️Watch List👁️ view. We can optionally notify the agents.
Our agents react by opening the ticket and taking the 'bump' action needed. Once they take action and submit the ticket, a trigger should remove the t_watchlist tag so it disappears from the 👁️Watch List👁️ view

What's great about this approach is that we can create so many independent ways of adding the t_watchlist tag such as automations, triggers, external inputs, apps, etc.

It brings the most needy tickets front and centre for agents to action so now it's a matter of ensuring the agents have the 'bump' procedures in place to action as appropriate.

Fully Automating Bump Stage With ⚙️ 📧 Automated Follow Up

A second approach is fully automated and is designed to detect stale tickets, figure out who the ticket is waiting for and send a 'bump'.

The example I'll use here is when a low-priority ticket has been assigned to an internal group but the other group has not reacted within 7 business days.

💡 Important Note:

The next steps leverage a webhook to update the ticket via the Zendesk API. You can learn how to create this webhook here.

Make these form changes

This requires first setting a date field on your form to capture the date the ticket was assigned to the other group. Here are the steps:

Create a new date field called T3 Follow Up Date and add it to your form.
Now create a new trigger with the following (your conditions can be adapted)
1. Conditions:
  - Ticket > Group Changed From [source group name]
  - Ticket > Form Is [your form name]
  - Ticket Status > Contains at least one of the following > Open, Waiting For Change
  - Ticket > Priority Is Low
2. Actions
  - Ticket > T3 Follow Up Date > Set to a number of days from now > 7

Now any time your ticket is assigned from your specific group to any other group, e.g., Tier 2 team to any Tier 3 team, a date 7 business days in the future will be placed in the T3 Follow Up Date field.

Now we're ready to automate the bump so the T3 team gets notified or bumped if they don’t react by the date set in the T3 Follow Up Date field.

Create a new automation

This automation is designed to act on tickets that have not been assigned back to the source group and the T3 Follow Up date has passed.

Create a new automation with the following (your conditions can be adapted):

Meet all of the following conditions:
1. Ticket: Group > Is not > [source group name from your trigger]
2. Ticket: T3 Follow Up Date > Is within the previous > 1 days
Perform these actions:
1. Notifications: Group email > (assigned group). Set the follow-up subject & body as you wish. Example shown above.
2. Notifications: Active webhook > Update tickets (see this page for help creating a webhook)
3. Set the JSON body to something like this. Feel free to adjust the actual text with the "body":
  {
  "ticket": {
  "comment": {
  "body": "Internal Note - the assigned group was sent a follow-up.",
  "public": false
  }
  }
  }
4. Ticket: T3 Follow Up Date > Set to a number of days from now > 7

💡 Important Note

If your T3 group does actually send the ticket back to the source group (the happy path), be sure to set a trigger which removes the T3 Follow up Date.

To Recap

OK, so now the automation will check for tickets where the date in the T3 Follow Up Date field is in the previous day as well as anything else you'd like to check for.

Once all conditions are met, the automation will send an email to the whole group, post an internal comment (so all teams know the 'bump' occurred) and reset the date 7 business days from now so it re-bumps automatically.

You can easily add to this by adding tags, or even adding a numerical field to the form to count how many times groups are getting bumped.

This would provide valuable data to help improve internal processes and quality.

In Part 2, we'll look at optimising the 'Solve' stage.

And finally, in Part 3 you can find out how to extend the auto-close beyond Zendesk's maximum of 28 days.