Last year I wrote an introduction on Zendesk Service Level Agreements and how to use them in views. Since SLAs are now also a key metric to be used in Omnichannel Routing, it's worth revisiting this topic and see what's been changed since the original article.

If you haven't read it yet, it's worth a look before diving into the new features.

My approach to setting up Zendesk SLA Policies and enabling Group Policies.

In this article we’ll explore the new Group SLA policies in Zendesk, lay out an approach to setup a scalable SLA policy across your instance and make sure agents take care of the right ticket first.

Internal NoteThomas Verschoren

Overview of the available metrics

When it comes to setting up SLAs in Zendesk, the basic premise has not really changed. You can measure different points in the lifecycle of a ticket, and you can choose to enable some, or all, of the metrics.

Each SLA policy contains three key elements.

• A name and description that clearly defines the SLA in your reporting. I recommend setting up two default SLA policies. One for your messaging based tickets, and another for traditional email based tickets. If needed, you can create additional, more strict, policies if certain customers or topics require it.
• The scope of the policy defines to which tickets the policy applies. As mentioned earlier, I prefer doing a scope for Messaging and Email based tickets, but you can add more policies with specific scopes like brand, user type or topic.
• Target Metrics are the actual core of your SLA setup, they define what time you want to measure and report on. Each metric can be defined for each of the four priorities: low, normal, high, urgent. You can define those metrics in Calendar or Business hours. Personally I prefer business hours since you can only control what you do while your team is working, but customers might count in calendar time (I submitted this on Friday and you replied on Monday, I've been waiting for 4 days!) so you might choose to do your setup based on Calendar hours.

New in Zendesk for a while now is a full reorganization of these metrics. Instead of one long list of metrics, you now have three distinct categories.

1. Reply Metrics, which measure how long a customer is waiting for a reply.
2. Update Metrics, which measure the time in between replies, making sure the customer is staying up to date with longer tickets.
3. Resolution Metrics, which measure time spent across the lifecycle of a ticket from creation till resolution.

Let's dive in!

Reply metrics

The first section of metrics are the once that are configured the most, and have the most impact on your customers.

• First reply time measures the time between the time a customer's ticket is created, and the first reply they get from an agent.
• Next reply time measures the time between each subsequent public agent comment to a customer reply.

Last year Messaging tickets couldn't have a first reply time, but since then this has been amended and the timer now stops when an agent clicks Send and replies to the conversation. Important here is that FRT only counts agent replies. Your AI Agent for messaging might be the fastest replier in the world, but has zero impact on your actual reply time metrics.

However, if you use an AI Agent for email like Ultimate, that reply does count as an Agent Reply. So your FRT might be impacted and report lower than the actual reply time. When using email AI agents I recommend looking at a combination of Next Reply Time and Comment counts to get insights on howe your agents perform.

Update metrics

Honestly, this is a metric I rarely use or configure. Most support tickets get to be short lived and can be resolved with 2-3 replies, especially if you've got a good self service bot deflecting the easy stuff, and collecting context for agents.

Since the update metrics expect agents to update tickets within a specific timeframe, even though no actual noteworthy stuff might have happened, this actually create more work for agents since they have to update to those tickets in order to stay within the configured time.

If your tickets are more complex tickets that do require a lot of internal investigation, like reaching out to suppliers and fabrication plants for root cause analyses, then these are useful though since customers might think you've forgotten about their ticket due to prolonged periods of silence.

There's two types of update metrics

• Periodic Updates set a limit on the time between each public comment from your agent across all statuses.
• Pausable Update is a subset of the periodic updates which excludes tickets that are in pending status. Since pending tickets imply that the customers is blocked until the customer replies, there's no point on measure the time until an agent updates the ticket during that time.

Resolution metrics

To wrap up there's the last section of metrics. These don't count reply times, but measure the total lifetime of a ticket from creation until resolution.

There's three metrics to measure.

• Total resolution time is the time measured from ticket creation until resolution. If a customer emails you on Monday, and the ticket gets solved by Friday, that time is ~5 days, or 40 working hours.
• Requester wait time measures the total lifetime of a ticket but excludes the time a ticket has been in the pending state. It gives you an idea on the total time the customer has to wait for the ticket to be resolved. For example, if you replied to your customer on Monday and they gave you feedback on Wednesday, your ticket was on hold for a day and your actual customer wait time was ~4 days.
• Agent Work Time is the final one of the available resolution metrics. This one measures only tickets in new and open status, ignoring time spend in pending or on hold. This last one is especially useful if you use on hold to block tickets that are escalated to external parties you can't control like a supplier or production plant. This metric can then measure only the time tickets are actually assigned to your agents and open for them to work on.

Group SLA

So far the metrics we've discussed apply to tickets assigned to your team and measure timings they control like reply times or resolution time.
Within a company you often need to pass tickets between teams. A support ticket about a server issue needs to be resolved by DevOps first before your support team can respond to the customer. First line might assign something to second line, or your support team needs approval from finance for a refund.

Once the ticket leaves the original group the respond time is out of their control, putting metrics like next reply time or full resolution time at risk of breaching.

With the Group SLA you can put a measurement on ownership for those kind of supportive departments in a company. You can for example require Finance to respond within a working day, or give DevOps two days to look into an issue and reassign it back to the original group with comments.

This is done with a Ownership Time which is scoped to a specific group (or groups) and starts when the ticket is assigned to the group, and stops when the ticket leaves the group (this metric resets on each reassignment).

Advanced First Reply Time

Traditionally the first reply time only fires when a ticket is created by an end-user. As noted above, once the ticket lands in Zendesk, the first reply time counter starts, measuring the time until an agent adds a public reply on the ticket.

With the arrival of Zendesk Messaging, and more complex features like Side Conversation child tickets, this line between end-user creates a ticket, and agents replies becomes a bit blurred.
Similarly, if an agent creates a ticket for a customer – a so called proactive ticket – the reply time actually is basically zero since there's no time between ticket creates and the end-user getting a reply from the agent. It's the same step.

Since this leads to gaps in reporting, Zendesk has now expanded the First Reply Time calculations to account for these new scenarios.

Aside from starting the FRT counter when an end-user creates a ticket, by default Zendesk will also start the counter when an agent forwards an end-user email to Zendesk, or when a new Child Ticket via Side conversation has been added.

Additionally, you can also enable a couple of additional scenarios to be applicable for the FRT metric. This is done via the Admin Center under the Advanced settings of the First Time Reply Metric

When a light agent forwards a customer email this creates a ticket with an optional internal comment. If enabled, the counter starts when the ticket arrives in Zendesk, until an agent replies publicly.

Similarly, when an agent creates a proactive ticket for a customer, we can now enable a FTR metric on this ticket. The counter starts when the ticket is created, and runs until the agent posts a second public reply. Quite useful for proactive tickets to alert a user off an unscheduled downtime , which then counts the time until the first status update is send to the customer.

And finally, the last advanced measurement you can enable is for scenarios where agents create a ticket for themselves. You can think for example of scenarios where an agent works in the IT team, and creates a ticket for the HR department in the same Zendesk instance to request time off. Since he's an agent and not an end-user, traditionally those tickets don't apply for a FTR metric. But since the ticket is created with him acting as an "end-user in his own Zendesk environment", you might want to count the FTR time so you can properly report on the work HR does,.

These three new scenarios can all be enabled in the new advanced settings, and might fix some gaps in your reporting!