A service level agreement, or SLA policy, is an agreed upon measure of the response and resolution times that your support team delivers to your customers.
For example, you can define an agreement where you respond to urgent tickets in 10 minutes and resolve them within 2 hours. Messaging customers may want to define an SLA where the first reply time has a 30 second target.
Setting up SLA policies
Each SLA policy has a set structure consisting of conditions that a ticket must meet and the metrics you choose to measure. See Best practices for using metrics together.
To set up an SLA policy
- In Admin Center, click
Objects and rules in the sidebar, then select Business rules > Service level agreements.
- Click Create policy.
- Enter a Policy Name.
- Optionally, enter a Description, then click Next.
- Select the Conditions for the policy.
Start typing the condition to autocomplete or select an option from the drop-down menu.
- Click Next.
The options to define Reply metrics, Update metrics, and Resolution metrics appear. Note that you don't need to set a target for every metric when setting up an SLA policy.
- Click Add target for the SLA metrics you want to define, then select a target from the menu.
- Enter a time target for each ticket priority. Note: The minimum target time you can set is 15 seconds. You can enter hours, minutes, or seconds.
- Optionally, select either calendar hours or business hours for Hours of operation for each priority.
- Click Add.
The metrics you defined are added to your policy.
- Continue to add additional metrics by clicking Add target, then selecting a
target from the menu. Or click Save policy to finish.
If you have existing SLAs, the newest SLA is added to the bottom of the list. The order of your SLA policies determines how they are applied to tickets.
To make your policies most effective, you should roughly order your policies with the most restrictive policies at the top, and your least restrictive policies at the bottom (see Ordering SLA policies).
Community tip! Mat Cropper shows how to set up SLAs so the correct policy is always applied in Running triggers, automations, and reporting based on ticket SLAs. And Mark Powell shows how to set up SLAs for time zones in Using SLAs with different time zones, contracts, and business hours.
Understanding which SLA metrics you can measure
You can define SLA service targets for seven different metrics, which include reply time, update time, and resolution time metrics. All metrics have standard criteria that control how the metrics are activated and fulfill their targets. Metrics' standard criteria can't be changed.
The First reply time, Next reply time, and Periodic update time metrics have advanced settings that allow you to select additional criteria for how these metrics activate and fulfill their targets. See Customizing your SLAs with advanced settings.
Before defining any SLAs, make sure you understand how SLA policies are applied to tickets.
Reply time metrics
Reply time metrics help you understand how your team is performing in regards to responding to your customers.
Reply time SLA policies apply to all ticket, chat, and messaging conversations. Note that if reply time SLAs for chat conversations aren't turned on, then only public replies count towards the reply time SLAs. See Activating reply-time SLAs for live chat.
First reply time
First reply time is the time between ticket creation and the first public comment from an agent (or autoreply). Use this metric to specify how much time it should take your agents to get back to your customers.
The first reply time target starts when a customer submits the ticket and stops once an agent makes a public reply to the customer. This is the most common workflow and typical behavior. In the example below, the first reply time is a combination of segments A and B:
If an agent creates a ticket on behalf of a customer with an internal note, the first reply time target starts when the customer makes a public comment and ends when the agent makes a public reply. See the example below, where the first reply time is a combination of the segments C, D, and E:
- The first reply time is not calculated on tickets if the agent creates the ticket with a public comment. This is because the SLA first reply time target is immediately satisfied. It does not activate or record an achievement.
- If a light agent makes the first comment on a ticket with an internal note, the SLA first reply time target starts at their comment and runs through the next public agent comment.
- SLA first reply time targets for side conversation tickets have additional considerations. See Defining OLA policies using internal SLAs and child ticket side conversations.
Next reply time
Next reply time is the time between the oldest unanswered customer comment and the next public comment from an agent (or autoreply). Use this metric to set the amount of time it takes for your team to get back to your customers.
The next reply time target starts at the oldest unanswered customer comment and stops when an agent makes a public comment. In the example below, the next reply time is shown in segment E.
The following example demonstrates the next reply time as a combination of segments C, D, and E:
Update time metrics
Update time metrics help you set how frequently you’ll keep your customers informed while their issue is being resolved.
Periodic update
Periodic update measures the time between each public comment from agents. Think of this as how often you want your customers to be provided updates from your team.
This metric uses the agent’s public comment as a starting point and resets after each public comment an agent makes. In the example below, periodic update is a combination of segments C, D, E:
Pausable update
Use the pausable update metric as an expectation of how long agents will spend on a ticket. In the example below, the pausable update is the combination of the segments B, D, and E:
The Pausable update metric applies when an agent makes the first public comment on a ticket with a New, Open, or On-hold ticket status. It pauses when the ticket is changed to the Pending status. It resumes when the status is changed to Open or On-hold with either a public comment or an internal note. Pausable update targets will not start until there is a public comment from an agent (or autoreply) and the ticket is not in a Pending state.
If an agent adds a public comment and marks the ticket as Pending in the same event, the metric will not be applied to the ticket until the ticket is first submitted in a New, Open, or On-hold status with a public comment. The metric will apply once the ticket is set to Pending.
Resolution time metrics
The resolution time metrics use the ticket status (or status category if custom ticket statuses activated) to determine the amount of time that was spent on the ticket.
Note that while you can choose multiple resolution time metrics, it is considered a best practice to limit your selection to one to avoid confusion.
Resolution metrics always use the status of the ticket for starting, pausing, and stopping, as opposed to comments. The following graphic shows how the resolution time metrics fit in with the lifecycle of a ticket:
Requester wait time
The requester wait time is the combined total time spent in the New, Open, and On-hold ticket statuses.
Requester wait time starts when the ticket is created and stops once the ticket is solved. It pauses when the ticket has a Pending status.
In the example below, the requester wait time is the combination of segments A, B, D, and E.
When you set this metric, consider the amount of time it should take your team to fully resolve the issue.
Agent work time
Agent work time is the combined total time spent in the New and Open ticket statuses.
This metric pauses when the ticket has an On-hold or Pending status.
In the example below the agent work time is a combination of segments A, B, and E.
When you set this metric, consider how much time an agent should spend on a ticket.
Total resolution time
Total resolution time is the total amount of time it should take to resolve a ticket, including time in a Pending status. It measures the entire lifecycle of a ticket, from when it's created until when it's solved. It doesn't pause on any ticket status changes, except for when the ticket is changed to the Solved status.
Note that if a ticket is solved and then reopened, the time spent in the Solved ticket status is treated as a pause and doesn't count towards the target. See Reopening tickets effect on an SLA.
Best practices for using metrics together
You don’t need to set a target for every metric in an SLA policy. The example below illustrates all the metrics and how they overlap:
- First reply time is straightforward and a good starting point if you’re not sure of which metrics you want to hold your team accountable to.
- Pick only one resolution time metric: Requester wait time, Agent work time, or Total resolution time.
- It is possible to have both next reply time and periodic update time metrics active. Your target status will display the metric closest to becoming breached.
Reopening tickets effect on an SLA
- First reply time, Next reply time: If a ticket is reopened with a public end-user comment and all conditions are met, the relevant Reply Time metrics activate new targets.
- Periodic update, Pausable update: If a ticket is reopened with an end-user comment, nothing will happen. If a ticket is reopened with a public comment from an agent (or autoreply), the relevant Update metrics activate new targets.
- Agent work time: This metric reactivates the same target with the same amount of time elapsed/remaining, and it treats the time in Solved status like a pause. If the ticket goes to Pending/On-hold status, it will remain paused until the ticket goes to Open status.
- Requester wait time: This metric reactivates the same target with the same amount of time elapsed/remaining, and it treats the time in Solved status like a pause. If the ticket goes to Pending status, it will remain paused until the ticket goes to Open/On-hold status.
- Total resolution time: This metric reactivates and continues to count from the ticket creation time. Any time spent in the Solved status is treated as a pause and isn't counted towards the target.
122 comments
Noly Maron Unson
Hope this email finds you well.
Dainne is currently out of the office and I will temporarily provide the response for the time being.
SLAs are computed on a per-ticket basis and merging a ticket with another ticket even if they have the same SLA policy applied to them will not combine the time they have for their target.
Let me know if you need anything else.
0
Anna Valdez
Hi, where exactly can I set the SLA to business or calendar hours? Thanks

0
Dainne Kiara Lucena-Laxamana
Hi Anna Valdez,
Do you already have operating hours set up on your end? The option to choose calendar/business hours only pops up if you already have a Support schedule active on the account.
0
Dave Symonds
Where/how is the time to solve SLA calculated?
0
Dave Symonds
Also how do you bypass certain target metrics - do you set them to 0?
0
HS
How do SLAs work on Talk tickets? We need to apply SLAs to our phone calls to make sure we're meeting our contractual obligations, measured in seconds (not hours or minutes). Is this possible?
0
Inon Rousso
Hi,
Is there a way to exclude specific agent from the SLA policy? currently Im working with 1 "support SLA" for the support team and we dont want that our sales eng' will be calculated.
0
Kristin Bouveng
Inon Rousso Yes you can exclude specific agents or groups within an SLA policy, by adding the condition "Assignee"/"Group" - Is Not - [Select in dropdown]
0
Nara
0
Dave Symonds
Thanks Nara - so Solve and Resolution are the same thing
0
Paul
I have a question about the timers. They are acting weird.
A SLA policy is set up like below.
So the first reply time should be 8 hours (for all status):
But when we receive a ticket (which is using the above policy if i check the events of it) it is showing the first reply as 24H and also the solve time as 24H. But nowhere the 24H rule/time is set or used....
How is this possible or how does zendesk came to this 24H timer?
Or what am i missing here?
0
Scott Allison
@Paul . Please take a look at this article which explains about targets and how they're displayed along with business hours: https://support.zendesk.com/hc/en-us/articles/4408883657114-Why-do-I-see-differences-in-SLA-target-hours-
If that isn't it, I recommend you reach out to our support team for help.
1
Paul
@scott: thx got it working now. The timer is also counting the hours outside the business hours. So i didn't expected a higher number. But it makes sense now :)
1
Joshua G
How are SLAs attributed to ticket groups?
For example, if our Tier 1 team has breached an SLA, and then escalates it to our BIlling Team for further action. If our Billing Team then solves the ticket, is the initial breach attributed to our Billing Team on Explore?
0
Terry Knox
Joshua G - The SLA dataset only has the concept of the final/current ticket assignee, so all breaches will be attributed to them. To my knowledge, there's no way to track breach events to specific groups/agents unless those groups/agents handle the ticket from beginning to end. It's a bit rubbish.
There's a feedback thread, here.
1
Hussain
Hello Lisa,
Can you tell if I have custom Priority updated in Fields.
Then I am not able to create SLA's, do I need to use the default Priority which is present in Zendesk????????????
Please can you answer
0
Heather Rommel
Hi Hussain,
I'm not sure who Lisa is, but yes you would need to use the default priority in the SLA conditions.
0
Aarti Lakhani
We currently have some bespoke SLAs for customers where we only offer SLA times for Urgent and High priority tickets. When creating an SLA for them, what happens if the Normal and Low times are left blank? Does it ignore tickets with those priority levels?
Thanks,
Aarti
0
Amy Dee
Hi Aarti!
An SLA will only apply if you specify a target for that metric and priority. You can certainly add targets for Urgent and High priority but leave Normal and Low blank. If you do that, SLAs will only apply on Urgent and High priority tickets.
This can impact your workflows in several ways. The most obvious is the SLA badge: Urgent/High tickets will have a badge, while Normal/Low tickets will not. Also, views that sort by SLA breach will put tickets without SLAs at the end of the list, and Explore reports in the SLA dataset will only include tickets that had active targets.
I hope this helps!
2
Aarti Lakhani
Thank you, Amy! That helps a lot
0
Aarti Lakhani
Hello,
I have another SLA question. My organization currently has an old SLA that applies to a subset of all organizations (about 40 organizations are on this old SLA). What is the best way to set this up?
When I look at the Conditions page, I can't use the ALL of these conditions options it can only be one.
For the ANY of these conditions options, I want the SLA to apply if it is (Form is Bugs OR Questions) AND organization is (Org1 OR Org2 OR...). How can I set up an OR AND grouping?
Thanks,
Aarti
0
Amy Dee
Hi Aarti!
At this time, our business rules don't support multiple sets of "OR" conditions within the same rule. You wouldn't be able to capture that level of detail within a single set of SLA conditions.
Instead, I recommend incorporating tags and/or triggers. You could apply a tag to the organizations on your list. That way, all tickets created in those organizations would have the tag. Then you can reference the tag in your SLA policy, with no extra "OR" logic required. This also makes it easier to add and remove organizations over time, since you only need to update the organization's tag and not all your business rules.
For other condition clusters, you could tag them using triggers. The details depend on your use case and SLA needs. This approach gives you a lot of flexibility and granular control, since you can combine the tags in your SLA conditions (and other rules). It's easy to get carried away, though, so be sure to take good notes as you set it up.
If you have questions about specific configurations in your account, please reach out to our support team. That will allow us to review you situation in more detail.
I hope this helps!
0
Aarti Lakhani
Thank you for your response. I've chosen to add a drop down field to the organization and using that for categorization. The field is SLA Type with values of Old SLA, Negotiated and Standard. I will add a value to each organization and create SLAs using this. Do you see anything that could be wrong using this method?
Regards,
Aarti
0
Boris
I don't see the Hours of Operation fields under targets at all when I try to add a new SLA. Is there a reason for that and how can I add the fields?
0
Gabriel Manlapig
If Hours of Operation isn't available, it could be that you have not yet set up a business hours in your Zendesk account. If that's the case, Hours of Operation will default at calendar hours.
To create business hours to your account, you can check on this article: Setting a schedule for your Zendesk.
I hope this helps. Thank you!
0
Beth
Hi,
What would cause an SLA to have a negative SLA from another Agent User's view even though the ticket hasn't been breached yet? We have an issue with only one Agent User where she sees all SLAs in negative red. For example, one ticket has 3h left for the SLA, but she sees is as -12h.
Thanks for your help in advance!
— Maribeth
0
Heather Rommel
Beth,
I'm wondering: Is the agent looking at the exact same view with the exact same tickets? Can you have the Agent refresh their screen? Maybe log in/log out?
When they open the ticket and hover over the SLA counter, does it show the same as for other agents?
0
Alberto Peña Baez
Buen comentario
0
Beth
Hi Heather,
Only one agent user sees the SLA differently. Everyone sees the same ticket with 3h SLA, but this agent sees is at -12h in red. We fixed it temporarily by letting her log out and log in again, but the fix will only be for a few minutes. Help please!
Thanks!
0
Whitney
The SLA of next reply time does not work for side conversation. Is there any way to improve it?
0