Your biggest customer calls your VP because responses to their support tickets have been taking way too long. Suddenly, you’re in a conference room explaining why critical issues sat in the queue for hours while your team worked on less urgent requests. Sound familiar?
This scenario plays out in support teams everywhere, but it’s completely avoidable with the right Zendesk SLA setup.
SLAs — aka Service Level Agreements — aren’t just corporate bureaucracy; they’re your safety net for ensuring the right tickets get attention at the right time.
In this guide, I’ll walk you through everything you need to master Zendesk SLA features.
You’ll learn how to create policies that prioritize what matters most, track the metrics that actually matter, and set up automations to catch problems before they escalate to the C-suite.
Whether you’re migrating from another platform or building your first SLA framework, you’ll walk away with practical tools to make sure you’re taking care of customers (and to prevent those uncomfortable executive meetings).
What Is a Service Level Agreement (SLA)?
If you’ve been in customer support for a while, you’ve definitely heard “SLA” thrown around before. But what’s it actually mean?
A service level agreement is your team’s commitment to specific response and resolution timeframes for customer support requests. Think of it as a promise with a timer attached.
Some teams, usually in the enterprise space, might make explicit promises to their customers about how quickly they will receive a response to a support email.
That’s an SLA, and sometimes they can even come with penalties, where if you don’t deliver on your SLAs, your customer gets a discount.
In other organizations, SLAs are less formal. They often operate more as internal targets for how long it should take to resolve a customer’s request.
While there may not be penalties for not meeting those targets, they’re vital for optimizing your team and consistently improving your customer support experience.
The Importance of SLAs in Zendesk
Here’s the thing about customer support without SLAs: you’re basically flying blind.
Sure, you might feel like your team is doing great work, but without concrete measurements, you’re missing half the story. That gut feeling that “we’re pretty responsive” doesn’t hold up when your biggest client is frustrated about wait times.
Zendesk SLA policies give measurable goals, and Zendesk’s built in functionality also means it’s really easy to track how you’re performing against those goals.
Whether you’re thinking about your customer experience or an individual agent’s performance, you have clear metrics that show exactly where you stand.
SLAs can also transform how your team operates day-to-day. No more vague instructions like “handle tickets as quickly as possible.”
With SLAs in place, your agents know exactly what’s expected: respond to urgent tickets within 2 hours, resolve billing questions within 24 hours, and so on. That kind of clarity helps everyone prioritize their work more effectively.
Zendesk SLAs also bring benefits for your leadership team. You can spot patterns before they become problems: which tickets are being handled well? Where are bottlenecks? Where do you need to staff up? Answers to questions like these make it far easier to allocate resources, adjust staffing, or identify training needs.
Lastly, and most importantly, SLAs also give your customers predictability. When customers know they’ll hear back within 4 hours, they stop sending follow-up emails after 2 hours. When you commit to and deliver on SLAs, your customers learn to trust that their request isn’t lost or missing.
Understanding the Types of Customer Service Zendesk SLAs
There are two types of SLA policies in Zendesk that can be combined or used independently, depending on your support organization’s specific needs.
SLAs
These are the core SLA policies you configure in Zendesk. They define the expectations for how quickly agents should respond and resolve tickets. These SLAs apply broadly, and you can create multiple policies tailored to different priorities, channels (chat vs. email), or ticket types.
A general SLA policy could state that all “High Priority” tickets must receive a first reply within 1 hour and be fully resolved within 24 hours.
Group SLAs
Group SLAs allow you to apply SLA rules specifically to certain agent groups or departments, rather than across the whole organization. You might have a Technical Support team who work on the hardest escalated issues, or a VIP support team that has stricter SLAs.
You can use Group SLAs to set policies that reflect the differences in their work.
SLAs targets and conditions
All SLAs are made of these two critical ingredients: targets and conditions.
You define the specific metrics (targets) you want to measure and the rules (conditions) under which the SLAs apply. It’s important to understand both the metrics you’re measuring and the rules you’d want that to apply to going into building your SLAs.
Targets are the measurable goal your SLA policy is tracking such as: first reply time, next reply time, resolution time and periodic or pausable updates (more on all this below) A policy might track several targets or just one, depending on the needs of your organizations.
Conditions make up the criteria or rules that decide when this specific SLA applies.
Zendesk offers a wide range of conditions for you to choose from including ticket priority (urgent, high, normal, low), channels (email, chat, phone, etc.) and even details like the organization or requester (allowing you to focus policies on VIPs or other segments of your customer base.
Conditions allow you to apply the right SLA policies to the correct scenarios. You might want to target a first-response time for 10 minutes for chat, where customer expectations are high, but target a 1 hour response for emails.
How to Set up SLA Policies in Zendesk
Now that we’ve got an understanding of the elements that go into the SLA, we can start to put it into practice in Zendesk.
The first real step is to determine what kind of policy you’re building. In my example, I’m going to build SLA policies for my email tickets for all customers.
We don’t provide different levels of service based on customer type at this time, but we do have different expectations based on channels.
Fortunately Zendesk makes it easy for admins to quickly create and manage policies in-app, even though there’s a great deal of flexibility in configuring them.
Here’s how to do it:
- First navigate to your Zendesk Admin Center.
- From there click Objects and rules to expand the menu.
- Underneath Business rules find and click SLA policies.
- Click Create policy.
- Choose and enter a Policy Name on this screen.
- Optionally, you can enter a Description that helps identify the purpose of the policy (we’re setting one here that describes who these policies apply to).
- After, click Next.
- Select the Conditions for the policy.
- We’ll dive more into conditions in a bit, but this example shows a policy that applies only to “Email” tickets
- After you’ve selected your conditions, click Next.
- On the next page choose your SLA metrics.
- Here’s an example of adding “First reply time.” By default Zendesk lets you define these by the urgency of your ticket. If that’s not a feature you use or simply now how you’d like to do this you can set these all the same
- Click Add when you’ve defined each metric.
- Add more targets as needed by clicking Add target and repeating the process.
- When you’re satisfied with the targets click Save Policy and you’re all done!
- You can revisit these saved policies to edit in the future or to clone for building similar ones at any time!
Applying SLAs Policies to Tickets
When a ticket is created or updated, it’s run through all of the automation triggers you’ve defined. After that, it’s run through your SLA policies. Similar to Zendesk triggers, the system checks your SLA policies in order from top to bottom and applies only the first policy that matches.
Zendesk applies group SLAs in the same manner separately, meaning you can have both a group and standard policy apply on one ticket. That means it’s important both to target your SLA policy conditions well and to order your policies by importance.
Ticket updates don’t usually affect SLA tracking, with the main exception being priority changes. When a ticket’s priority is updated, the corresponding SLA targets for that new priority will apply on the next update.
Another important exception is ticket merges: when two tickets are merged, the SLA on the older ticket is frozen, and only the surviving (newer) ticket continues to track against its SLA.
Applying Zendesk SLAs to Views
Now that you’ve set your SLA policies you might want to apply these to the practical work of prioritizing your queues. One way to do that is to add SLA countdowns to the individual views your team uses when accomplishing their work.
- Navigate to Admin Center > Objects and rules > Views.
- Edit or create a view.
- Add columns such as “Next SLA breach” or “SLA metric” to track SLA countdowns.
- Use these views to monitor tickets approaching or exceeding SLA deadlines.
It’s important to make sure your team knows what to do with these countdowns and that they’re making an effort to prioritize tickets whose deadlines are approaching!
How to Use SLA Breaches in Automations
You can take tracking SLAs to the next level by incorporating them into your Zendesk automations. For instance, you can trigger automations before a breach happens so that your team takes quick action and you don’t actually breach the SLA.
Zendesk offers two triggers for your automations that incorporate SLAs:
- Hours until next SLA breach (for preventing breaches).
- Hours since last SLA breach (for catching up on breached tickets).
After choosing your triggers you can determine the follow up actions that fit the needs of the workflow you’re designing.
Some common workflows are:
- If a VIP customer’s ticket is 30 minutes from breaching the first reply time target, notify the priority support Slack channel, and reassign it to a senior agent.
- If an email ticket breaches the next reply time target, increase the priority of the ticket to ensure it gets assigned out faster.
- If a long running ticket breaches the periodic update target, add a note to the ticket tagging the assigned agent to remind them to provide an update.
SLA Target Statuses
In my years of using Zendesk for tracking SLAs, I think the number one source of confusion for people has been how SLAs interact with ticket statuses.
As a refresher, tickets in Zendesk have a status. The status indicates where in the journey of resolution that ticket currently is. All statuses, including custom statuses, fall into one of these default buckets: New, Open, Pending and On-hold.
The ‘clock’ on your SLAs, like requester wait time below, do not run all the time. Instead they’re tied to specific ticket statuses.
For Requester wait time, Zendesk doesn’t ‘count’ the time in the Pending status — the time when the ball is in the requester’s court. If you’re waiting on a reply from the requester, they aren’t waiting…so the SLAs pauses during that status.
Similarly, Agent work time is an SLA designed to track when your agents are actively working on an issue.
Since agents aren’t supposed to be working on tickets when they’re Pending (waiting on the customer) or On-hold (waiting on someone else), the SLA clock pauses during those two statuses.
While it can be hard to understand conceptually, Zendesk makes it easier by visibly showing which ticket statuses count toward each SLA during the setup process.
Use Advanced Settings to Customize Zendesk SLAs
Zendesk includes advanced SLA settings to unlock more customization.
These options typically pertain to when a target is activated and when it is fulfilled. For example, by default the next reply time target is activated only when an end user adds a new reply.
You might require a nuanced workflow that tracks internal customers who use “light agent” seats in the same way you do external customers, so you could enable the option to activate the SLA from when light agents add internal notes.
These advanced settings are typically designed for accommodating complex workflow needs. It’s good to know they’re here, but in my experience, 90% of organizations won’t really need to use them.
SLA Metrics to Measure in Zendesk
Zendesk SLA metrics offer a number of ways to understand your customer interactions that can be grouped in three broad categories: responsiveness, resolution and update.
These metrics are essential to extracting the most value out of your SLA policies and a core understanding of them is the foundation to doing that.
You’ll find a definition of each of these different metrics and how you can use them to track outcomes in your organization.
First reply time (FRT)
What is it
The FRT is calculated as the time from when a customer first submits a ticket until the first public agent reply. This excludes any non-public responses (comments in Zendesk) and does not consider any subsequent replies by the customer.
Why does it matter
FRT is one of the most important metrics for support teams that allows you to understand how quickly you’re providing initial help to your customers.
A blistering 90% of customers report an “immediate” response is essential or very important when they have a customer service question. If your team isn’t quickly acknowledging your customer’s requests you might be damaging that relationship.
To help teams improve First Response Time and stay within Zendesk SLAs, Swifteq’s Agent Co-writer offers an AI-powered reply assistant directly inside Zendesk that enables agents to acknowledge tickets faster, even during peak volume.
By generating clear responses from short prompts, auto-summarizing lengthy ticket histories, and suggesting relevant Help Center content, it cuts the time spent drafting and reading before an initial reply.
Its multilingual translation and customizable tone further streamline communication, ensuring agents can deliver a prompt, accurate first response without compromising quality, making it a practical tool for support teams aiming to consistently meet (and exceed) SLA targets for rapid acknowledgment.
Next reply time (NRT)
What is it
Next reply time or NRT measures the gap between when a customer leaves any message and when your team replies again. Think of it as the clock that measures how quickly you’re getting back to people once they follow up.
Why does it matter
While FRT focuses on the immediate answer, NRT tracks a longer term ability to satisfy your customer’s need for responsiveness. It is common for these targets to be less aggressive but it doesn’t mean they aren’t as important.
Customers should be kept in the loop of your progress and this metric makes sure you’re doing that over the whole lifecycle of a ticket.
Total resolution time (TRT)
What is it
TRT is the total time from when a ticket is created until it’s marked as solved. It measures the full lifecycle of the issue, regardless of how many replies go back and forth along the way or what status the ticket is in.
Why does it matter
This is the ultimate measure of how quickly your team can close the loop with customers. Long resolution times can frustrate customers, even if you’re replying often. Tracking TRT ensures your team isn’t just responsive, you’re also driving problems to a finish.
Requester wait time (RWT)
What is it
RWT is the amount of time a customer spends waiting for a response from your team – the time a ticket spends in the New, Open and On-hold status. It pauses whenever you’re waiting on them (like if you’ve asked for more info) and resumes once the ball is back in your court.
Why does it matter
From the customer’s perspective, this is the most visible SLA metric. It’s literally how long they’re left hanging. Keeping RWT low helps reduce frustration and shows that your team values their time.
Agent work time (AWT)
What is it
AWT measures the total time agents actively spend working on a ticket. That’s the time a ticket is spent in the New or Open status, but not the time spent in On-hold or Pending. That’s the time spent writing replies, investigating issues, and updating the case. It excludes periods where the ticket is idle or waiting for the customer.
Why does it matter
This metric highlights the actual workload behind resolving issues. It can help you spot tickets that are consuming too much agent effort or uncover process inefficiencies that slow your team down. It’s also important for helping forecasting staffing and hiring needs!
Periodic update
What is it
Periodic update is a metric that tracks the time between public updates from your team. It is reset each time a new message is sent to your customer. This is meant to ensure that your customers are getting regular updates even when an issue isn’t resolved.
Why does it matter
Nobody likes to be ignored. Silence is one of the worst experiences for a customer. Tracking periodic updates ensures your team is providing the assurance that their issue is still being worked on, even if you don’t have a final answer yet. It’s a simple way to build trust and transparency.
Pausable update
What is it
Pausable update tracks the time between each public agent reply while a ticket is sitting in New, Open, or On-hold status.
Why does it matter
Not every delay is in your team’s control. Pausable updates make sure agents aren’t unfairly penalized for waiting on customers, while still keeping accountability once the conversation continues.
Best Practices for Zendesk SLAs
Now that you thoroughly understand Zendesk SLAs, I want to offer some best practices for making the most of them. My guidance is drawn from my years of making mistakes, working on, building and leading support teams with some bright folks.
I’ve learned a lot of these lessons the hard way, so I hope it helps you avoid making some of my mistakes.
Build simple policies first, then refine
As an automation aficionado, I had grand plans for building out a perfect SLA system when I first moved into a role that let me. The reality of what I built didn’t live up to those expectations, and I was spending more time debugging triggers and conditions than I was helping customers.
The best approach to SLAs is to start small and keep it simple. Implement a minimum viable policy (get it?) and then add to it later.
Track and develop an understanding of your team’s FRT and TRT before diving into more nuanced metrics like periodic or pausable updates.
Don’t split your attention until you’ve mastered the basics.
Track your SLAs in Zendesk Explore using the preconfigured SLA dashboard
Having an SLA policy is a great first step, but if no one is tracking the outcomes it just becomes another number to forget.
Zendesk offers a simple and clear pre-built SLA dashboard that you should get familiar with. Check it weekly and share the results with your team or wider organization.
Keep a close eye on the policies to spot trends, frictions or gaps where your metric goals aren’t in alignment with reality.
Set your business hours in Zendesk.
If your team isn’t available for 24/7 support, your SLA policies should reflect that. It isn’t fair (or helpful!) to judge yourself for not getting back to a customer if they wrote in when you’re closed. Zendesk makes it easy to avoid this by connecting the business hours you set into the tool directly into SLA policies.
Pair your SLA data with a robust Quality Assurance program.
Domino’s Pizza famously offered an SLA you probably know: your pizza in 30 minutes or less or it’s free.
This was extremely popular with their customers but it turned out to be a (dangerous) problem for Domino’s. Drivers’ performance was majorly influenced by their on time deliveries.
Fearful of losing their jobs, drivers began to rush recklessly to arrive on time. Accidents started piling up (and so did the lawsuits), ultimately causing Domino’s to admit defeat and change the terms of the policy.
Why all this pizza talk in a customer support blog? Not because I’m hungry (though I am), but because SLAs inherently incentivize behaviors and we should acknowledge and plan for it.
While your team probably isn’t going to end up running red lights to reset a password, they will naturally feel the pressure of an SLA timer and left unsupported might err towards sending a less than perfect reply to beat the buzzer or brush off a customer’s new line of questions to make sure they come in beneath the resolution target.
You can prevent these wrong incentives with a strong QA process that encourages and rewards teammates giving great support and highlights areas of improvement. This isn’t about punishing anyone – it’s about providing a balance to our natural tendencies.
If you find your team is struggling to balance achieving your SLAs at the level of quality you expect, you might have to investigate whether those are the right targets after all!
Review and adjust your SLAs regularly.
You might find your team is suddenly breezing through their SLAs after your developers release an internal tool that cuts troubleshooting time in half.
Or perhaps a hotly demanded new feature to your core product has added many new layers of tricky complexity, slowing your team’s investigations to a snail’s pace.
Change will happen. You have to make sure your SLA policies do too.
Set quarterly reminders to review your policies and interrogate whether they’re still right for your business objective.
Making the Most of Zendesk SLA Policies
Well crafted and thoughtful Zendesk SLAs aren’t just timers ticking away in the background, counting down until someone’s in trouble. They’re a tool that helps you codify and deliver on your promises of great customer support, creating guardrails that keep your team on track.
If you set them up your SLAs well, track them over time, and adjust them as needed, you’ll find them to be an invaluable tool for your support organization.
Improve your support team’s efficiency and make their lives even easier with Swifteq’s suite of Automation, Help Center and Agent-Assist Zendesk® apps. Start your 14-day free trial today or ask for demo.
Written by Thomas Hils
Thomas is a 10+ year veteran of the customer support space, helping high-growth startups scale magical experiences. You can connect with him on LinkedIn.
