Creating a notification to identify tickets that are stuck at the back of the queue due to no SLA being applied
The Problem
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 thenew CCs and Followers feature- more contexthere)
When that happens, these tickets end up stuck on the very last page of our queue.
The Goal
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 wouldhypotheticallybe 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, youmightneed 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.
- 而我所有的自动化将基于business hours, you can certainly update the logic to look at calendar hours instead.
- 如果哟u’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 anHTTP Target for the specific Slack channelyou’d like to post these notifications to.
Instructions
Step 1
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 thatdohave 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.
Step 2
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 ticketshouldhave 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 theTickets: Hours since updatecondition. It’s by no means perfect since it’spossiblefor the ticket to be updated after the customer wrote into Support, but it works well enough.
Step 3
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.
That's it!
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.
如果哟u 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!
Thanks, Chandra!
-Rudolph
-
@...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.
-
MonicaAgree 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!
一个问题,我有记住特定的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!
Oliver -
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 astuck_notification_senttag when this automation fires. Under the Conditions section. I'm then looking for tickets that match the criteria but do not already have thestuck_notification_senttag. 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 thestuck_notification_senttag (in addition to theactive_sla_tickettag that we added for some tickets in Step 1). I'm automatically removing both thestuck_notification_senttag as well as theactive_sla_tickettag 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.
Pleasesign into leave a comment.
8 Comments