Running triggers, automations, and reporting based on ticket SLA
One of the things I love about Zendesk’s SLA functionality is that it gives me an easy way to prioritise tickets, and see which ones need focus (and when). This is a really reactive way of working, though, and so I wanted to find a way to flip it on its head.
This tip is to share what I came up with to do that: our new setup for SLAs, a couple of trigger ideas, and a thought on reporting.
Our updated SLA setup
You can see how we originally set up SLA polices in a previous post of mine, “Using Enhanced SLAs”. In a nutshell, we have an SLA for each ‘user need’, with the conditions for being assigned that SLA defined in the SLA policy.
With this setup you can perform automations based on the hours since last, or until next, SLA breach, but that’s about it. You can’t do anything in triggers.
To get around this, we decided to shift the logic for setting SLAs. This is what we did:
- Created a new custom ticket field ‘SLA’.
- Each SLA has only one condition: Ticket: SLA Is SLA_SomeSLA (the unique name of the SLA)
- We have a set of triggers that run when a ticket is created, and these add the SLA name (as above) to the ticket custom field. This is where the logic for being assigned an SLA now lives.
- We have another set of triggers that run when a ticket is updated, and these deal with times when the ticket is updated such that a different SLA policy applies. These triggers remove any SLA value, and add the new one.
- When our ‘notify requester of update’ trigger runs, we add a tag to the ticket (public_reply_sent).
The application of SLAs happens after triggers and automations run on a ticket. That means that the correct SLA will be applied every time by Zendesk if configured in the above way. Sweet!
Our tickets still get the right SLA applied, but now we’re much more in control of the logic. The addition of the SLA field to the ticket is the secret sauce that means we can start getting proactive.
You could also do all of the above using tags instead of a custom field, by the way.
Using the SLA field for triggers and automations
Before, we were limited in doing anything to tickets based on SLA. With the addition of unique SLA tags, we can do anything to these tickets that we can do based on tag.
Here are two of the things we did using this:
- Changing assignment of tickets: We very occasionally see that a ticket is Open, close to breaching its ‘requester wait time’ SLA, and our agent hasn’t updated the ticket in some time. In this scenario we use the ticket SLA custom field, the tag we add to tickets when we send a public reply (so we know the first response SLA has been met), hours until next SLA breach, and ticket status attributes to run an automation to reassign the ticket to the group. This allows someone else to pick the ticket up before the SLA is breached.
- Managing customer expectations: This doesn’t need the ticket SLA field, but does use the public_reply_sent tag. If this tag is present we know that the first response has been sent, and so the next SLA target is the requester wait time. This automation checks to see whether the tag is present and if the hours until next SLA breach are 5 or less, we send a courtesy email to our customer. This lets them know that we are dealing with their ticket, but it’s taking a little longer than usual to reply.
We’re also looking at building an in-ticket app that looks for the SLA field value and then provides useful information and prompts to our agents. For example, if the SLA is for the user need ‘refund’ we might show a summary of recent transactions or a one-click refund capability.
Now that we have a custom field that tells us the SLA of a ticket, doing SLA-related reporting in Insights is a doddle. Until SLA metrics are integrated, this is potentially a really useful workaround.
Hope that’s helpful, folks!
Thanks for sharing this, Mat! Awesome!
Love it! This will help a lot of people, Mat! Thanks so much for posting it.
Thanks Mat for sharing this one. It gave another perspective on managing the SLAs .
I would like to initiate a trigger when SLA is breached where SLA is 30 minutes. Would these steps solve this?
Can you please explain what do you mean by
"We have another set of triggers that run when a ticket is updated, and these deal with times when the ticket is updated such that a different SLA policy applies. These triggers remove any SLA value, and add the new one."?
What are the trigger conditions?
Thanks in advance.
Is there a way that I can set up a daily report that will get sent to all my agents telling them which tickets are going to breach in the next 24 hours? I have tried to do this in Good Data, but not really sure where to start.
This would be a big help in ensuring tickets aren't breaching.
We have an article that should answer this question for you. You can find it here
It would be nice to review the formatting of this article, it's hard to read.
I'm looking into what happened on this Tip...we'll fix it if we can. Otherwise we'll archive it. Thanks for the heads-up!
I'd really like to have the formatting fixed on this. It looks like he included pictures and I'm a visual person, so seeing what he did would be great.
Hi Breonna -
We're looking into why the images are broken and working on getting it fixed if the error is on our end. Standby!
We heard back from our internal team and it appears that the images included in the original post were copied and pasted from a source that is no longer available.
The recommended work-around here is to download the image you'd like to include in a post and then upload directly to the post instead of using the copy past method mentioned previously.
We were able to get the formatting fixed in this Community Post, however, we're unable to retrieve the images since they are no longer available.
Let me know if you have any additional questions regarding the above.
This is an interesting approach to using the SLAs. I'm wondering how the SLA breach was actually used in a trigger though? Maybe I'm not following fully, but the two examples listed appear to be for an automation (since they run off of the 'hours until/after SLA breach'). Is there any way to use an SLA breach in a trigger?
It would be great to get a ticket event when an SLA is breached that we can then use to have a trigger run to push a notification to a team slack channel. An automation can technically do this - but it's a little limited because of the question around when exactly an automation would run on a ticket.
Iniciar sesión para dejar un comentario.