Creating a notification to identify tickets that are stuck at the back of the queue due to no SLA being applied
When sorting views by the Next SLA Breach time, we’ve found that there are cases in which a ticket lands in our Support queue but does not trigger a First or Next Response SLA.
A few specific examples of when this might happen:
- A Zendesk agent creates a ticket on a customer’s behalf.
- A user originally submitted a ticket under a shared email alias, but is now writing in from a different email address.
- A user that was CC’ed on the ticket clicks on ‘Reply’ instead of ‘Reply All’ (applicable for any Zendesk customer using the new CCs and Followers feature - more context here)
When that happens, these tickets end up stuck on the very last page of our queue.
We wanted a way to ensure that no tickets were getting indefinitely stuck at the back of our Support queue. As much as we do our best to keep an eye out for these types of tickets, it can feel impossible to achieve this on extremely busy days when our queue is multiple pages in length.
Additionally, since we have a shorter SLA for our Enterprise customers, it was challenging for us to identify these customers and ensure that they were still receiving faster response times.
That got me thinking. What if there was a way to be notified in Slack when a non-SLA ticket would hypothetically be at risk of breaching? That way, these customers wouldn’t have to suffer longer response times simply because their ticket was stuck at the back of our queue.
A Few Notes Before Getting Started
Before walking you through how we achieved this, I did want to call out a few things:
- For the specific group we've implemented this for, we only rely on First and Next Response targets. If you use other SLA targets, you might need to tweak the logic or actual implementation of this to get it to work just right.
- I’ll be using automations to fire the actual notification. Since automations only run once per hour, this solution will work best for companies that have 2+ hour response time SLAs.
- While all of my automations will be based on business hours, you can certainly update the logic to look at calendar hours instead.
- If you’d prefer to trigger an email notification instead, you can certainly modify Step 2 to accomplish this.
- That said, if you’d like to take the exact approach I took when it comes to triggering a Slack notification, you’ll first need to set up an HTTP Target for the specific Slack channel you’d like to post these notifications to.
Since there isn’t a way to identify tickets in Zendesk that do not have an SLA applied, you’ll first need to create an automation that would identify the tickets that do have an SLA applied.
To accomplish this, you can create an automation that adds a specific ticket tag (i.e. active_sla_ticket) to any ticket that does not already have this tag and will breach in more than 1 hour.
Now that you can identify which tickets already have an SLA applied, you’ll want to create at least one automation that fires a notification for any tickets that do not have this specific ticket tag.
For our specific use case, we’ve built out different automations based on which SLA Policy the ticket should have been on. Additionally, since we offer more technical support, we wanted the notification to fire ~2 hours before the ticket would’ve hypothetically breached.
Example: If we have a 6 hour response time for our partners, I want this Slack notification to fire around the 4 hour mark so we have ~2 hours to investigate the issue and get a response out.
To do this, I’m relying on the Tickets: Hours since update condition. It’s by no means perfect since it’s possible for the ticket to be updated after the customer wrote into Support, but it works well enough.
Finally, you’ll need to create a trigger that removes both of the tags we’ve added in the above automations upon the next public response from an agent. This helps ensure that all of these automations are rerun should the ticket reopen in your queue.
Hopefully that helps other Zendesk customers that might be struggling with this issue. We've been using this Slack notification for a few months now and it's been working really well.
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.
Thanks Chandra! We have the issue with SLAs not triggering and now I know why!
@... Of course! I'm thrilled to hear that you found this post to be helpful. :)
Woah, crazy timing on this! I actually implemented steps 1 & 2 last week before this article was written. I was having some trouble figuring out the solution provided in step 3, so I appreciate the detailed guide!
@... What timing! I'm so happy to hear that this helped you get this implementation across the finish line.
Thanks for this article! Excited to try it out. Tickets without an SLA are a big hurdle to organizing views how I'd ideally like to organize them.
Monica Agree completely! I love sorting views based on the Next SLA Breach column. Excited to hear how your team likes this solution once implemented.
Thanks for this sophisticated solution!
One question, I had in mind that a specific automation can only fire once per specific ticket. Obviousle I'm remembering this wrong, because your solution won't work twice on the same ticket. But can you confirm it does? So I'll happily adjust my brain and even more happily start identifying SLA-orphaned tickets!
Thanks so much!
Excellent question, @...! Automations must contain either a condition that is true only once or an action that nullifies at least one of the conditions.
In this case, I'm using the latter option which means this automation can run more than once should the ticket get stuck in the back of the queue once more. More detailed information on how I'm doing that below:
In the actual automation, I'm adding a stuck_notification_sent tag when this automation fires. Under the Conditions section. I'm then looking for tickets that match the criteria but do not already have the stuck_notification_sent tag. The action of adding tag nullifies that tag condition and prevents this automation from firing in an endless loop. Zendesk should show an error in the UI if you were to try to save this automation without that nullifying criteria.
To get this automation to run for future ticket updates, you'll need to remove the stuck_notification_sent tag (in addition to the active_sla_ticket tag that we added for some tickets in Step 1). I'm automatically removing both the stuck_notification_sent tag as well as the active_sla_ticket tag via the trigger in Step 3 after the agent's next public comment. That way, if that ticket reopens, the entire process will start over again depending on whether the latest ticket update has an active SLA target or not.
Let me know if you have any questions about that! I use that type of nullifying tag logic in several of my automations as it's a pretty handy trick.