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.

Reporting

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!