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 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.
Mathew, this is a great tip! Very useful info for other users who want to set up SLAs. Thanks for sharing it!
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)
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!
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.
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. :)
Can you get SLAs to work on reopened tickets that have been solved?
As we have some customers who reply to a solved ticket about another query.
Can you clarify which SLA targets you're looking to use with re-opened tickets?
Any additional information you can provide is greatly appreciated :)
We have first reply time, next reply time and pausable update on the same SLA.
I would understand the first reply time not working for recently opened tickets from being solved but the other two.
Would I have to add a criteria to the SLA for these to generate?
As you mentioned, FRT would not be factored in assuming your agents already submitted their first public response on this re-opened ticket previously.
However, if the ticket is re-opened then Next Reply Time and Pausable Update should automatically continue without you have to set up new criteria.
Let me know if you experience anything different on your end.
We have had a ticket responded to within the first reply time but the ticket got solved at the same time.
The customer replied to the ticket, opening it back up but the SLA have not shown to resume the next SLA that it should encounter.
The ruling of our SLA is
Channel - Email
Tags contain none of u_no_notification, t_wpd_no_notify, t_solved_no_notification, t_deleted_ticket.
FRT - 9 business hours
NRT - 9 business hours
PU - 27 business hours
The relevant ticket has the following tags
t_annual_leave, t_email_query, t_hrandpayroll_email, t_reopened
I'm not sure why this is not continuing with the SLA
I would take a look into the events of your ticket to see if there is anything out of place. Are some of your blocked tags on the ticket at any time? Is the Priority field still populated? Is there a schedule applied?
Hopefully that gives you a few things to check into. It may be worth opening a ticket with that as an example for Zendesk to walk through it and see if they can identify where the SLA should have fired.
La publicación no admite más comentarios.