Earlier this month Zendesk announced the availability of Group SLA policies as an extension of the regular SLA policies that existed for customer facing tickets.

SLAs, or Service Level Agreements are a way to measure reply and handling time on tickets and to make sure tickets get replied to in a realistic timing.

About SLA policies and how they work

What’s my plan? Fastpath: Admin Center > Objects and rules > Business rules > Service level agreements A service level agreement, or SLA, is a policy you define that specifies and measu…

Zendesk helpColleen Hall

All SLA policies in Zendesk are are based on four elements:

• Priority, ranging from low to urgent as a way to differentiate different tickets
• Business schedule, or differentiating between counting only actual working hours or also continue counting when your agents are offline
• Measurement type, ranging from first reply, next reply to total working time.
• A filter to define which tickets an SLA policy applies too.

My approach

I like to keep my Zendesk environments rather sparse and easily readable. So when I go and setup SLA policies I've got a few basic steps I take first:

1. Split conversational and ticketing requests
2. Set priority on all tickets based on category or customer type
3. Map all tickets to a specific group
4. Have a schedule for each group

My SLA policies then follow a clear order. For a given group, e.g. Support I have the following two policies:

• SLA Support - Tickets
• SLA Support - Messaging

Within each SLA Policy I filter based on the group and channels, and I always set the operational schedule to Business Hours, cause we can't account for time we're not at work.

And once those policies are made I fill in only First Reply Time (create a sense of urgency) and Next Reply Time (create room for informed replies)

Preparation

Define Channels

Each business has their own needs, and each channel has to be treated differently, but in general we can define two types of channels: conversational and ticketing

Conversational channels, like chat or Facebook Messenger, tend to be focused on short messages sent in burst. Issues can be resolved quickly, and neither party expects the conversation to take long.

Ticketing channels like email are often used for longer, more complex interactions.  An email can contain a lot more nuance than a message, and we often even escalate conversations to email ticketing if the issue is too complex or needs to be handled by different teams (e.g. Finance or IT)

For that reason I like to make a difference in SLA between the two types of interactions.

Set Priority

Each SLA Policy can contain up to four different targets for each of the metrics, ordered by Priority. I used to create a lot of different SLA policies to handle different ticket types. An SLA for returns, an SLA for complaints, another one for downtime, ... This leads to a lot confusion on which SLA applies when.

To remove this confusion I now always fall back to four triggers that set the Priority for each incoming ticket, with a default of "normal".

That way, each ticket that comes into my Zendesk environment via a specific channel is first prioritised, then assigned to a group and then gets one SLA applied based on the combination of these 3 elements. For regular SLA policies you might be tempted to put these metrics in the conditions of the policy, but for Group SLA policies that isn't possible, and you can only work with Priority. So turned ticket conditions into priorities early one via triggers is worth it and makes working with SLA a lot easier.

I start by creating 4 triggers

The first three triggers are similar. They each contain a list of conditions in the Meet ANY of the following conditions step that should match that priority.

This can be any combination of elements, like Subject contains urgent, or customer is VIP, or category is GDPR, or any combination of elements. The goal here is to have a few triggers that narrow down your inquiries to a single item: priority.
Once you've got your conditions setup, you add a single action: proirity is urgent (or high, or low).

If the triggers get too complex, feel free to create multiple triggers for specific scenario's.

Once you've created the first three triggers, you can add the fourth one: Priority is Normal. This is our fallback trigger that makes sure if none of the above apply, your ticket gets treated as normal. Cause remember: no priority means no SLA!

Note that I did not add any conditions like ticket is updated or created to the triggers. I want these triggers to run on every ticket and update to make sure the SLAs get updated when needed. If you want agents to be able to manually update their priority too, add a Priority is not changed condition to the triggers.

Schedules

You should make sure to setup at least one schedule for your Zendesk instance, since SLA's can (and should) be based on Business Hours.

Note that if you have multiple schedules running, you should create triggers that assigns a schedule to a ticket. Otherwise tickets get created without a schedule and the SLA does not get calculated.

Creating the SLA Policies

Once the above steps are completed, creating the SLA's is pretty straightforward:

1. Go to the Admin Panel and create a new SLA policy.
2. Give it a logical name, eg SLA Messaging - Support or SLA Ticketing - Support to make it clear that this is an SLA that applies to tickets for the Support group and the Messaging Channels (or not)
3. Start by adding one condition to each SLA Policy: Channel is Messaging or Channel is not Messaging. Since Messaging is a parameter that contains all Messaging Channels (Twitter DM, Facebook Messenger, WhatsApp, Web Widget,...), and SLA Policies are applies top-to-bottom, with the first applicable rule applying, this will make sure all Messaging tickets get the first SLA, with the rest the other one.
4. Add a second condition: Group is Support, to scope the SLA to that group.
5. Set the Hours of operation to Business Hours so we only count the time agents can really have an effect on tickets.

Metrics

Now comes the crucial part. Setting up the metrics. I like to keep the data clear for Agent so they know how to interpret the numbers shown.

For Ticketing channels I often only fill in  First Reply Time and Next Reply Time. -

• First reply time should be kept short. The faster we acknowledge a problem, the happier the customer is. They know we're working on it.
• Next reply time can be longer. Giving agents time to look into requests in detail results in better responses and less chance of getting many back and forts.

If you're worried that longer next reply times will result in backlog I would recommend resolving this issue at the beginning and put more effort in enabling self service and ticket deflection.

For Messaging Channels these two metrics don't exist (yet). Here the Periodic update option can offer relief. It measures the time between Agent actions, and since messaging tends to be short and quick, we can use this as a good replacement.

Fill in the columns for each priority with the required value. Or, if you have no idea what to fill in, you can go for a 2-4-8-16 metric for first reply time, where urgent ones see a reply in 2 business hours, and low priority tickets see a maximum of 2 working days (measured as 9-5, 8h per business day). Let these SLAs run, and check back in a month to see if they are realistic.
For next reply I often go for a basic 4h for high/urgent and 8h for normal/high before a follow up reply is due.

The result

If you've followed the above steps you'll end up with a view not too dissimilar from this one, a clear overview of policies ordered by channel and responsible agent group.

What will happen with your tickets is also clear:

1. A VIP customer emails about a lost package
2. We have a trigger that sets these kinds of requests to High
3. And assign these tickets to our Support group

Since this is a request raised via email, and assigned to the group Support, our Ticket SLA - Support SLA should start. And since the request is Urgent, we need to reply within 4 hours.

Similar, a user sends a message over WhatsApp requesting info on getting a discount on a product. We tag discount requests as Low, and assign it to the Sales team. The Messaging SLA - Sales starts and we need to reply within 16h, or 2 days.

If a new type of requests requires a specific urgency in replies, you can add that type of requests to the trigger that sets priority as a condition and the SLA will automatically apply. Or if urgent now means "Within 30minutes" for your third level IT group, you can update the SLA Ticket - 3th level IT policy and update the metric for next reply time for that team.

SLA based views for a fair order

SLA Policies are only useful when we give Agents a good way to interact with them.  One way to make it more intuitive for agents to handle tickets based on priority and make sure they handle the most urgent ones first is to work with SLA based views.

Let's say I have an SLA setup with First Reply times of Urgent: 2h and Normal: 4h

1. A customer emails me with an normal question at 9AM
2. A customer emails me with a urgent question at 10AM
3. A customer emails me with a normal question at 10AM
4. A customer emails me with an urgent question at 11 AM

If we use an ID sorted view, or first in first out based, and I look at this list at 12PM, I might see the tickets 1-2-3-4 sorted as follows:

But how do we handle these tickets fairly once priority comes into play? Does ticket 4 come before or after ticket 1? You might be tempted to sort by priority. But that means the more urgent tickets are created, the lower that first ticket will drop. Not exactly fair for that user, right?

This is where SLA based views are useful. In these views we sort tickets by SLA in an ascending order, meaning the first ticket to breach comes first.

Let's take our four tickets as an example. Taking our priority and SLA policies into account:

1. Needs to be replied to by 1PM (9AM + 4h)
2. Needs to be replied to by 12PM  (10AM + 2h)
3. Needs to be replied to by 2PM ( 10AM + 4h)
4. Needs to be replied to by 1PM (11AM + 2h)

If we sort tickets based on their SLA expiration, the tickets will appear in the following order for your agents: 2143 at 1PM.
Urgent tickets still are handled before less urgent ones, but we make sure we handle all tickets taking their SLA into account, preventing tickets getting breach by always picking the first or most urgent one first

Once we also take Next Reply Time into account this logic becomes a bit more complex, but the same rules apply. Tickets where the Next Reply time expired will be intermixed with new tickets but everyone gets threated fairly.

Group SLA Policies

The inspiration for this article came from the recently announces Group SLAs. These SLAs are, in contrast to the regular SLA policies, not focussing on reply times to the customer, but measure ownership by a specific group of agents.

The setup has a lot less options, but builds upon similar concepts.

• Conditions are group based. So you can only measure data based on which group is the current owner of a ticket.
• Priority is the same priority as the regular SLA policies look at. Here you see another reason why having triggers assigning priorities and working only with those in SLA policies is worthwhile. Group SLA conditions can't use anything else to set metrics.
• Hours of operations are once again the choice between Business and Calendar hours. To keep things consistent, keep it the same as the regular SLAs.

So, going back to our VIP customer who lost their package above: imagine the customer requested a refund for the lost parcel. We could initiate a side conversation via Child Ticket with the Finance Team to get approval for a refund, or assign the ticket to the Finance Team directly. Depending on the Group SLA setup, that team would then see a Group Ownership SLA counter, with a timing depending on the Priority of the ticket.

Views

When I first setup Group SLA policies I assumed they would intermix with the regular SLAs in views. But, apparently it's a second column you can enable. Which means, if you sort tickets by SLA breach, you have to pick one of them.

Restrictions

Assignment vs Escalation

There is one weird behaviour I found with these new SLAs though: there's no way to differentiate between being the primary owner of a ticket, and getting a ticket escalated in these SLA policies.

In a flow where your Support team is a first line support team, and escalates to the Finance team like we showed above, we see that that Finance team gets 30 minutes to ownership time and reassign it to the Support team again.

But what happens if you set a Group SLA for your first line support team?

Imagine most tickets take two days to get resolved. But you set the Ownership to a day. How does that work? Cause the only way first line can fulfill that SLA is by solving in less than a day, and/or escalating. I wonder what Zendesk wants us to do here. Do we don't set a Group SLA for a first line team? Do we set the SLA to the expected resolution time of a ticket?

The same can be said for environments where the IT team is both a first line for colleagues and employees, but second line for customer request related to the website. Setting a Group SLA is logical for escalated tickets. Your CX team wants replies back fast. But illogical for requests from colleagues directly, if IT has a supporting role there the ticket lifetime is probably longer than the ownership time for escalations.

Group SLA Policies are fairly new though, so I can only assume these quirks get ironed out. But if you have any insight in this, feel free to let me know.

One workaround I though of was creating two groups: IT, and IT Escalated. One for first line IT support, and a second group for escalated tickets that takes a Group SLA into account.

Another solution could be custom statusses. Group + Custom Status = SLA. Tickets assigned as Open could then be measure one way, Open via Escalation could be measured differently. But that would require an expansion of the feature.

How to handle external escalations?

A second part of escalations that can't be measured is anything that escalates outside of Zendesk.

Imagine your IT team working in Jira and you use the Zendesk to Jira integration. Or you escalate to your Marketing in Slack, or an external vendor via Side Conversations. I'd assumed that we could measure these kind of escalations too since they fall under how Zendesk describes this feature:

Tickets often pass between multiple departments or teams on the path to resolution. Group SLAs allow admins to set target times for those groups and separately track resolution times between departments.

However, with groups as the only available condition, this seems impossible to do. You could work with placeholder groups for assignment + escalation and then re-assign to the main group if the ticket gets updates, but that would mean end-user responses are invisible until we re-assign to the main group, which then resets the other groups' SLA. Weird. But then again, this is a first release.

Additional Notes

What about specific SLAs for a customer?

Let's say you followed the above steps and configured a similar SLA policy for your instance. But have a few customers whose SLA contract differs from the default. They have unique SLA requirements that apply across all your agents and departments. Or their SLA metrics really differ from your general numbers.

You can still apply the above for all your tickets and create a few specific SLA policies for these specific customers. Just scope them with e.g. Organisation is Acme Inc or Ticket tags contain Gold SLA .
Just make sure they stay above the other policies so they get applied first, since the first applicable policy gets activated.

All other customers don't apply these policies and will use the normal ones we just build.

What about customers that have a paid SLA, and other customers?

The same flow can still apply. You could split up the policies to differ between those with a Paid SLA, and the others. It might seem redundant, but since all policies follow the same logic, it's a lot easier to maintain.

• Premier SLA - Messaging - Support
• Default - Messaging - Support
• Premier SLA - Email - Support
• Default - Email - Support
• ...

It's useful to use the clone button in these scenario's to speed things up.

What's next?

The new Group SLA policies were the incentive to write this article. I like the fact that Zendesk is expanding their Service Level Agreements to be compatible with more scenario's, but I would've loved to have seen a bit more customisability to the Group SLA feature.

Why can't we differ between tickets escalated to a team and owner by a team? How can we measure SLA's for departments working outside of Zendesk we reach via Teams, Slack or the Jira integration? Where's the support for reply-based SLA's for Messaging? I hope (and I'm sure) Zendesk will keep in improving this feature.

If you've got any feedback on my approach, I would love to hear how you handle SLA policies and which scenario's I haven't thought of! Leave a comment below, or feel free to send me an email with feedback!