Mat Cropper

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!

Hey Francisco!

We operate on the basis that every shift should cater to every skill set. Our primary skill is language based, and so if I'm an agent who supports Chinese language tickets, for example, there's a peak in traffic overnight from mainland China, and then later in the day there's a steady stream of tickets from Chinese speaking players in the USA and Europe.

That being the case, we plan to have every shift staffed with agents skilled in each of the 15 languages we support. Based on that, we decided not to have timezone-specific SLAs, but instead to structure our tickets based on channel and certain custom fields (player needs based, if you're interested!).

We don't always get it right, of course. When we get failed SLAs, for example a bunch of breached SLAs for Chinese tickets, we take that as an indicator that our shift planning failed. Were there the right agents on the shift? Were there too few?

Hopefully, that's helpful for you!

We had the amazing opportunity to get to play around with enhanced service level agreement (SLA) functionality in Zendesk, and it resulted in some pretty significant changes to the way we work. I thought I’d share some of what we learned along the way.

How SLAs helped us

If you have particularly complex SLA needs, as we do, then you’ll probably find yourself managing those through a combination of views and some creative business process. To give you an idea of what we’re dealing with, we support nearly 200 games, in 15 languages, for a global audience, using several channels, and prioritizing based on diverse player needs. Doing that using views is messy.

With the enhanced SLA functionality, here’s what we did:

• We simplified our View structure, keeping it down to language only
• We implemented SLA policies using channel, game, player need, and status (see screenshot below)
• We updated our simplified Views to order tickets based on the SLA time

This works well for us, as a we have a multi-skilled team of amazing Customer Care Specialists. They now know that they always have the next most important ticket sitting at the top of the View, and no longer need to search around for tickets across different places.

Additionally, this simplification has meant that we’re seeing an improvement in number of tickets that meet or exceed their SLA targets. They’re much more visible, and used as part of your workflow for prioritization they give you tons of opportunities to simplify. Part of the key to this is a culture of agents using the ‘Play’ button!

Some things to keep in mind

We also learned a few things. Some things to be mindful of:

• The order of your SLAs in the admin interface is important. When a ticket comes in it is given the first SLA in that list where the criteria are met. If you have similar SLAs, make sure that they’re in a logical order or have conditions to refine them. That’ll stop tickets getting unexpected SLA policies applied to them.
• We found that limiting the policies to be channel-specific made things super simple later when changes came about, particularly when doing this via the API.
• Regardless of whether your SLA is set up to monitor calendar hours or business hours, the timer in the ticket shows in calendar hours (eg. “23 hours to reply”). Towards the end of the day, these timers can be a bit confusing, so include that little bit of info in your training for agents when you decide to roll it out. That’ll avoid folks thinking, “Man! I have aaaaages to deal with this one!”
• We have a central place that shows everyone what the service levels are. Having that understanding of how and why SLA policies are applied has been really useful, particularly as it invites some really interesting feedback.
• Insights information for SLAs isn’t available yet, but is planned. You’ll need to be creative with your reporting if you’re using the feature in the same way as us.

How we set up our SLA policies

We implemented SLA policies using channel, game, player need, and status (see screenshot below).

Below: this is not our actual Zendesk, but to give you an idea of how we structured our policies (25 in total).

And here's an example of an individual SLA policy based on user need and channel (see screenshot below). You'll need a custom drop-down ticket field for customer need or customer segment, depending on how you want to set up your policies.

Below: again, this is not our actual Zendesk, but to give you an idea of how we structured our individual policies.