The Problem 

We found ourselves breaching on SLA tickets in which we wouldn’t consider to be a true breach. For example, let’s consider the following scenario:

1. Customer writes into Support
2. Support confirms it’s a bug & escalates it to engineering
3. Support lets the customer know we’ll be back in touch by EOD Friday with an update
4. Customer responds and simply says “thank you,” triggering the Next Response SLA target

Since the customer didn’t ask any additional questions and we’ve already communicated clear next steps, the customer isn’t actually expecting a response back from us immediately, yet the Next Response SLA Target is.

We could send a public response back to the customer that says something similar to “Of course! We’ll be back in touch shortly.” But what happens when the customer responds back to that email with yet another “Thank you” message? All of a sudden, we feel caught in the middle of a “no, you hang up” scenario.

The Goal 

We wanted a way to be able to move a ticket into a Pending or On-Hold status without having to first send out a public response simply to satisfy the Next Response SLA target.

A Quick Note Before Getting Started

While the solution outlined below has worked great for our team, you might need to rework it to fit your exact Zendesk workflows. 

For instance, we have several automations in place that will reopen tickets after a specified time period. This helps us identify the exact tickets we need to follow up or check in on.

As a result, we don’t use the Pausable or Periodic Update targets for the majority of our SLA policies. If your team heavily relies on the Pausable or Periodic Update targets, you’ll want to take a closer look into exactly how your team is using SLAs as well as the Pending and On-Hold ticket statuses to make sure this approach makes sense for your team.

Instructions 

Step 1

Create a custom checkbox field. If you’re using multiple ticket forms, you’ll also need to add this new ticket field to any relevant ticket forms. 

Step 2

Add a condition to all SLA policies that you’d like to use this functionality on so that the SLA is only applied for tickets in which this checkbox is unchecked.

Step 3

Create a trigger to automatically unselect this checkbox upon the agent’s next public comment on the ticket. This helps ensure that all future Next Response Targets can be triggered without your agent needing to manually uncheck this field.

That's it!

Now, if you want to move the ticket into a different status without sending out a public response, you’ll simply want to select this checkbox when doing so.

As a final step, I’d recommend training your agents on how and when you use this new checkbox. When I initially rolled this out, I provided our team with the specific use cases we’d want to use this for so that the expectations were clearly set from the beginning. 

If you end up implementing this, definitely let me know. Would love to hear how it's been helping your team or if you found any ways to improve upon this solution, especially for your own unique SLA policies and workflows.