Using Enhanced SLAs

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 prioritising 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 prioritisation 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.


  • 0

    Mathew, this is a great tip! Very useful info for other users who want to set up SLAs. Thanks for sharing it!

  • 0

    Hello Mat! Thanks for the insights!

    From your example I get the notion that you guys are operating across time zones as well, were you able to set up different business hours rules for it to work independently ? (so that no matter what country the service is being tackled on, it would make sense to the agent's schedules) 


  • 0

    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!

  • 0

    That makes a lot of sense =) 

    We will run some tests here to tweak around biz hours, but I'm pretty positive it will work pretty similar to what you guys have over there. 

    Cheers =D

  • 0

    Great post...thanks!   When I lead a support team many years ago, we had some strict SLAs and we printed them out on a pyramid (made out of paper) that sat on their desks.  We had response and resolution SLAs, so we used two sides of the pyramid for the details and used the 3rd side for our mission statement.  I guess today, there are more people working remotely sometimes, so having it centralized online some place is good too.  :)

Please sign in to leave a comment.