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
Sabra
Hey Beth! I know it's been a while since you posted, but the behavior your agent was seeing does sound odd! I think this would require a deeper look into your account and with that agent, so if they are still experiencing this please reach out to our Support team so we can assist further!
Hello Whitney! There are three possible ways to create a side conversation at this time: email, Slack, and ticket. If you are creating side conversations with the ticket option, you can set up SLAs/OLAs following the example in this article: Defining OLA policies using internal SLAs and child ticket side conversations. Since the other two methods of side conversations create threads that aren't actually tickets, we can't determine which SLA policy the conversation would meet and thus can't capture SLA information. That being said, we are always looking for ways to improve our system, so I would highly recommend posting your feedback and use case to our General Product Feedback topic!
0
Holly
Super excited for the "total resolution time." However, is there any way to get the SLA to pause when the ticket is on hold?
1
Zsa Trias
Hello Holly,
Unfortunately, there's no way to pause the SLA for "Total Resolution Time" metric on any status change. As mentioned in its definition, "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."
1
Priscila Santos
Hi,
When we receive a ticket the SLA is 8 business hours, but the system is adding the Periodic Update to SLA and it is increasing the time for agents to give the first reply.
Do you know why it is happening?
Thanks.
Priscila.
1
Noly Maron Unson
Hi Priscila,
I've gone ahead and created a ticket on your behalf to investigate your issue further. Please check your email.
Thank you.
1
Sarah Seiwert
Is "periodic updates" a measurable metric? I can't seem to find it anywhere on Explore to add to my reports.
1
Bobby Koch
Sarah Seiwert yes - it is in the SLA dataset though, won't show up in tickets, updates history, knowledge, etc., You will probably want to measure it in % achieved
1
Andrei Kamarouski
Hey, this is the formula for the metric like this.
2
Sarah Seiwert
This doesn't seem to be working for me. It's telling me that I have syntax errors. Besides changing days to hrs), what else am I missing. I'm a coding novice, so please be kind to me, community!
0
Andrei Kamarouski
Sarah Seiwerts, from the screenshot I see that the attribute and metric are not recognized, Most likely you are trying to add this metric not in the SLA dataset, but in another one. Could you double-check it and create it in the report from the SLAs dataset?
0
Beth
Hi Team,
I am wondering why tickets from our web form and web widget comes in without an SLA and Group.
All suggestions on how we can fix this is very much appreciated!
Regards,
Maribeth
1
Arianne Batiles
Hi Beth,
I've created a ticket for you so we can further investigate. Please check your inbox for updates.
0
Sarah Seiwert
Is it necessary to have a pausable and periodic update SLA on the same defined policy? They sound so similar and perhaps there's some redundancy there that I can choose one or the other based on what I want to have happen for my tickets?
0
Audrey Ann Cipriano
Hi Sarah Seiwert
It is not necessary to have both the pausable and periodic update SLA on the same policy, The main difference of those targets is the pausable update gives you the option to pause the SLA when the ticket is set to Pending status. Hope this helps! :)
0
Lucero Jimenez
Hi everyone
We're only using the Next Reply Time to measure how long we're taking to reply to our customers. However, we need a way to stop the SLA whenever a customer replies with something like "Thank you" which does not require any other interaction from our side, or when the customer is having a conversation with a third party before they need our input. Is there a way to pause it? We tried the Hold Status, but the time just keeps on running
1
Dainne Kiara Lucena-Laxamana
Hi Lucero!
Unfortunately by design, all end-user responses would reopen a ticket. You can create a Trigger instead to re-close tickets & utilizing the Trigger condition called “Ticket: Comment text”. For reference you can check out Trigger conditions and actions reference
0
Hannah Lucid
Hello, not sure if it was mentioned before (there is 22 pages of comments and I won't be able to go through each comment. Thank you for your patience!!) but it would be great if SLA's could be based on specific schedules. We have a specific schedule for our Treasury team's wires process since they do not process wires after 2 PM. Their SLA's for Wires, however, go off of the regular business (default) schedule.
0
Amy Dee
Hi Hannah!
Schedules are applied to tickets, not SLA policies (or other business rules). For the SLA policy, you just choose between calendar and business hours for each target. If you choose business hours, the SLA will use the schedule associated with the ticket.
Professional accounts only have one schedule, so there isn't much flexibility with business hours. Enterprise accounts can have multiple schedules, though, and they're controlled with business rules. That would allow you to create corresponding schedules and SLA policies for tickets in certain workflows.
We have more information about schedules here: Setting your schedule with business hours and holidays.
I hope this helps!
0
Legacy Mutual Mortgage
ZD - let's say we have a Next Reply Time SLA of 30 minutes. End user says “Thank you”, and we solve the ticket without replying with a public comment because it's not necessary to reply to that. If the ticket is solved, does that pause or cancel or meet the SLA, or is that not considered as meeting the SLA?
0
Amy Dee
Hi there!
Solving a ticket also fulfills all active SLA targets. This includes reply and update targets, which typically require a public comment. In your example, solving the ticket would fulfill the next reply time target, even if the agent didn't publicly respond to “Thank you.”
I hope this helps!
0
Fajar Cahyadi
Hi, I am trying to follow the steps described in this article to define SLA, but under “Business rules”, I only see Triggers and Automations, and I dont see Service Level Agreements. Is it because my Zendesk plan doesnt support it? is there other alternative to setup SLA?
0
Ivan Miquiabas
Most probably, but can you send a screenshot of what you can see under click
SLA policy currently supports:
0
Fajar Cahyadi
Hi Ivan Miquiabas ,
Here is the screenshot. I only see Triggers and Automations under Business rules. Is there another way to setup SLA?
0
Ollie Laver
Does the “next time reply” timer still run if we don't reply to the customers latest correspondance but pend a ticket straight away?
0
Micky Clutario
Hi,
I’m looking to establish SLA policies tailored to distinct support groups. Our first-line and third-line support teams require varying reply and resolution times. Currently, I can only assign policies based on the ‘Priority’ ticket field, with ‘High’ or ‘Normal’ as the options.
I'm having difficulty integrating custom fields into the SLA policy. We have custom fields named P1 through P4, yet they don’t seem to be applicable within an SLA policy framework. Is there a way to make this work?
I aim to devise an SLA policy that caters to a particular brand and accommodates different support team groups, utilising our P1 to P4 ticket values as performance indicators.
0
Micky Clutario
Hi,
I am currently configuring separate SLA policies on Zendesk for our first and third line support. I would like to clarify that our first-line agents will exclusively handle normal priority tickets. Since their responsibility is limited to normal priority tickets, any high-priority cases must be escalated to the third line. As a best practice, I propose leaving the reply and resolution metrics 0 under the high-priority column for our first-line agents.
Is it best practice to set up an SLA policy for 1st line support for high priority as zero for reply and resolution metrics?
Please advise.
I would appreciate speaking directly with a Zendesk agent to discuss this matter further. This way, I can provide more input on our SLA policy.
Thank you for your attention.
0
Micky Clutario
Hi,
How do I get in contact with Zendesk support directly? The get help button does not work on my account. It doesn't load when selecting “Get Help” in the admin area. Please advise.
0
Micky Clutario
I would like to activate the SLA policy for third line support high-priority first-time replies. For example, when the first line receives an incident that is later escalated to high priority (P1) after further investigation, I want to ensure that the high-priority first-time reply works correctly when assigning the ticket to third-line support.
However, currently, it does not function as expected. Instead, it activates the high-priority resolution time.
Please provide your advice on this matter.
0
Jay Saclot
Hey Mickey,
I've generated a support ticket on your behalf. Please check your email for related notifications.
0
Lucy Husband
If we are on Support Essential and do not have the ability to set up SLA does this mean our reporting is based on being available 24/7 and does not take into account weekends and out of hours?
0