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.
Por favor, entrar para comentar.