A Service Level Agreement, or SLA, is an agreed upon measure of the response and resolution times that your support team delivers to your customers. Providing support based on service levels ensures that you're delivering measured and predictable service. It also provides greater visibility when problems arise.
You can define SLA service targets in Zendesk Support so that you and your agents can monitor your service level performance and meet your service level goals. Zendesk Support highlights tickets that fail to meet service level targets so that you can promptly identify and address problems.
- A set of conditions that a ticket must satisfy in order for the SLA policy to be applied
- The target time for each desired metric and priority value
- One or more metrics that you choose to measure
- Whether targets will be measured in business or calendar hours by priority value
For more information about viewing SLAs as an agent, see Viewing and understanding SLA policies.
To learn about setting up multiple versions of policies, see Versioning your SLA policies.
Fine tuning: Learn how you can make the most out of your SLAs with Sam Chandler's Fine tuning: succeeding with SLAs--why, when, and how!
Understanding how SLA policies are applied to tickets
When a ticket is created or updated, it runs through all of your normal triggers you’ve already set up in your Zendesk Support instance. After the triggers have been applied, we run that ticket through the SLA system.
Starting at the top of your list of policies and moving down, we compare the conditions on that policy to the ticket. The first policy we find whose conditions are satisfied by the ticket is applied to the ticket. For details about how policies are ordered, see Ordering SLA policies. To review which policies have been applied to a ticket and in what order, see Viewing which SLA policies have been applied to a ticket
In most cases when a ticket is updated, the ticket will match the exact same policy that’s already applied and nothing will change. If your ticket has changed in priority but you haven’t modified your SLA policies since that ticket was last updated, the targets on the ticket will be updated to reflect the priority.
There are, of course, some exceptions. If you’ve created a new, more restrictive policy since that ticket was last updated, it’s possible that the ticket will receive that new policy that didn’t exist before. Or, alternatively, you may have updated the targets for the policy that’s already been applied. In both of those cases, the ticket will receive the new information.
When you merge an older ticket with an SLA into a new ticket, the older ticket’s SLA state is frozen, whether achieved or missed. The newer ticket proceeds with its own SLA. The merge action appears as an internal update on the newer ticket, which doesn’t meet or change any SLAs
Tickets set to Solved immediately fulfill all active SLA targets.
Understanding what metrics you can measure
You can define SLA service targets for five different metrics: first reply time, next reply time, periodic update time, requester wait time, and agent work time. The first three metrics measure reply time, while the second two measure resolution time.
Reply time metrics
The following metrics measure reply time:
- First reply time is the time between ticket creation and the first public comment from an agent, displayed in minutes. Some qualifications include:
Requester Ticket comment Result The requester is an end user. The ticket is created with a public end-user comment. The SLA first reply time target starts at their comment and runs through the next public agent comment. This is the most common workflow and typical behavior. The ticket is created with a public agent comment. The SLA first reply time target is immediately satisfied. It does not activate or record an achievement. The ticket is created with a private comment. See Creating a private ticket for an end-user. The SLA first reply time target starts at the first public comment by an end-user after the ticket is made public. This means the first reply can start after a public agent comment. It still runs until the next public agent comment after the end-user. The requester is a light agent. The ticket is created with a public agent comment. The SLA first reply time target is immediately satisfied. It does not activate or record an achievement. The ticket is created with a private comment by the agent requester. The SLA first reply time target starts at ticket creation. It still must be fulfilled with a public agent comment after that. The ticket is created with a private comment by a different agent: The SLA first reply time target does not activate. - Next reply time is the time between the oldest unanswered customer comment and the next public comment from an agent, displayed in minutes.
- Periodic update time is the time between each public comment from agents, displayed in minutes. The SLA is still active on Pending. If a user reopens a ticket, the periodic update time will not start until an agent makes another comment.
- Pausable update is the time between each public comment from agents when the tickets is in the New, Open, and On-hold statuses, pausing when the ticket is put into Pending.
The First reply time and Next reply time metrics typically use an end-user comment as starting point, and a public agent response as an end point. The following graphic shows how these metrics fit in with the lifecycle of a ticket.
The Periodic update time uses the agent's public comment as a starting point and resets after each published comment. For example if you have a periodic update time of 30 minutes, your agent will need to add a new public comment every 30 minutes.
The Pausable update metric uses the agent's public comment on a new or existing ticket as a starting point, only if that ticket is not in the pending status. If a ticket is contains a public comment and is marked as pending in the same event, the metric will not be applied to the ticket until the ticket is first submitted in an open status and set back to pending. Once a comment is present, the metric pauses in the pending status and resumes in a non-pending status with either no comment or a private comment from an agent.
Resolution time metrics
The following metrics measure resolution time:
- Requester wait time is the combined total time spent in the New, Open, and On-hold statuses. The SLA will pause on Pending.
- Agent work time is the combined total time spent in the New and Open statuses. The SLA will pause on Pending and On-hold.
Note that you should only choose one resolution time metric.
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.
Reopening tickets
- First Reply Time, Next Reply Time: If a ticket is reopened with an end user comment and all conditions are met, the relevant Reply Time metric is restarted.
- Periodic Update, Pausable Update: If a ticket is reopened with an end user comment, nothing will happen. If a ticket is reopened with an agent comment, the relevant Update metric is restarted.
- Agent Work Time, Requester Wait Time: There metrics activate only with the appropriate ticket status, including if the ticket is reopened.
Setting up SLA policies
To set up SLA policies, you combine the metrics described above with conditions and targets.
Conditions for SLA policies are similar to the conditions you use to set up triggers. Like conditions for triggers, they have both All and Any conditions, and the conditions can be based on ticket fields, user fields, or organization fields. However, there are fewer options than in triggers. For example, you can't create a condition based on the ticket’s status or priority, because those pieces of information are already built into the SLA policy model. For more information about using custom ticket fields, see Using custom ticket fields in business rules and views.
A target is the goal within which a particular time-based metric should fall. If, for example, you want all urgent tickets in a given policy to have a first reply time that is less than or equal to 15 minutes, you would set a target of 15 minutes. You can define individual targets for each combination of metric and priority per policy. You can also set hours of operation, whether in Business or Calendar hours, for each priority and policy.
To set up an SLA policy
- Click the Admin icon (
) in the sidebar, then select Business Rules > Service Level Agreements.
- Click Add policy.
- Enter a name in the Policy Name field.
- Optionally, enter a description in the Description field.
- In the Conditions section, select the conditions for this policy. Start typing the condition to autocomplete or select an option from the drop-down menu.
- In the Targets section, enter a time target for each metric and ticket priority. You can enter hours, minutes, or both. Remember that you should use only one of the two resolution time metrics.
- For each priority, select either Calendar hours or Business hours for Hours of operation.
- Click Save.
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.
- Click the Admin icon (
) in the sidebar, then select Business Rules > Service Level Agreements.
- Click on the SLA policy you want to edit.
- Edit the policy as necessary and click Save.
Ordering SLA policies
It's possible to create logically overlapping policies, but at any given time a single ticket can only have one policy applied to it. When you have multiple policies that match a ticket, we’ll use the order of the policies to break any ties. For details about how the order of policies affects tickets, see Understanding how SLA policies are applied to tickets. To review which policies have been applied to a ticket and in what order, see Viewing which SLA policies have been applied to a ticket
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.
To order your SLA policies
- Click the Admin icon (
) in the sidebar, then selecting Business Rules > Service Level Agreements.
- Hover your mouse over the left of the SLA policy name you want to reorder until the grabber is highlighted.
- Click and drag the policy to the new position.
Adding SLAs to views
Similar to ticket statuses, SLA targets have different statuses on a ticket. Agents can see these statuses in tickets or in views in the Next SLA breach column. The Next SLA breach column displays the calendar time left before the next target on any given ticket will be breached.
For details about the different SLA statuses, see Understanding SLA target statuses. For details about understanding how target status appears in this column, see Seeing SLA statuses in views.
Currently, there's no way to send notifications to agents based on SLA breaches.
To add SLAs to a view
- Click the Views icon (
) in the sidebar, then select a view.
- Click the View options menu in the upper right.
- Click Edit.
- Scroll down to the Formatting options section.
- Under Columns not included in table, click Next SLA breach.
- Drag Next SLA breach into the Columns included in table column.
- To make sure the tickets whose targets are most breached or are closest to breaching will get attention first, select Order by > Next SLA breach in Ascending order.
- Click Submit.
Using SLA breaches in automations
You can set up automations based on SLA breach status using two conditions, Hours since last SLA breach and Hours until next SLA breach. For information about creating automations, see Streamlining workflows with time-based events and automations.
Currently, you can't create triggers based on SLA breach status.
Reporting on SLAs
You can now view how well you are meeting your SLA policies with the SLA reporting dashboard. This dashboard gives you relevant information for each SLA metric you measure. The reports enable you to pinpoint areas where you might need to increase efficiency or staffing based on weekly and hourly information.
You can either build new custom SLA reports (see the Insights object reference and Insights metrics reference), or use the pre-built reporting dashboard (see SLA reporting dashboard overview).
It is important to note that the pre-built reports are based on a per instance basis rather than a per ticket basis. Most of your SLA metrics (First Reply Time, Requester Wait Time, Agent Work Time) are measured once per ticket. However, the metrics Next Reply Time and Periodic Update Time are used to measure the amount of time between comments. So, these metric could potentially be calculated multiple times.
For example, suppose you answered your customers' comments within the target time once, but breached the target three times after. Each of those achievements and breaches are calculated as separate instances.
Now how would this work if you are trying to calculate your Next Reply Time achieved percentage?
- Ticket A: 1 breach, 3 achievements (4 instances)
- Ticket B: 1 breach, 5 achievements (6 instances)
- Ticket C: 0 breaches, 3 achievements (3 instances)
- Ticket D: 3 breaches, 1 achievement (4 instances)
- Ticket E: 0 breaches, 3 achievements (3 instances)
Overall, there are 20 instances of Next Reply Time measured across five tickets. Your % Achieved is calculated by taking the number of achieved instances over the total number of instances. In this case your achieved percentage would be 75%.
% Achievement=15 achieved instances/20 measured instances=75%
The SLA metric instance attribute is also important when you build your own custom reports. If you want to view individual instances, you need to slice your report by this attribute. You can find this attribute underneath How>Ticket SLAs.
Deleting SLA policies
You can delete an SLA policy if it is no longer needed.
To delete an SLA policy
- Click the Admin icon (
) in the sidebar, then select Business Rules > Service Level Agreements.
- Locate the SLA policy you want to delete.
- Click the options menu (
) beside the SLA policy title.
- Select Delete, then confirm the selection.
190 Comments
Hi Nicole,
Yes of course.
Great, I'll reach out in a ticket. Look for a message from me shortly.
Since the order of the SLA policies matter to ensure they get applied to the correct ticket how can we reorder the Policies without deleting them and redefining.
I am in the process of improving our implementation of SLAs. I am adding policies to existing ones and modifying processes.. I have a need to make one of the new policies first in line. So far I have found no way of doing this without deleting ALL the Policies and starting again. Am I right or am I missing something?
We're having issues when a ticket is created by an Agent, the timer is not starting, even though a Periodic Update should now be applied.
Hi - How can we set up Service Level Agreements on tickets based on ticket creation time as opposed to first public end user time?
Our tickets are created via an API/integration with our own site - so the ticket comes to us with Internal Comment only, and not a direct public comment from End User
We need to track First Reply/Next Reply time based on when ticket is created, but this seems to not be possible with the standard set up. There seems to be a metric that tracks exactly this, but seems it's logic is not available to customers to use?
Hello,
How does SLAs work with reassigned tickets?
Say Agent 01 reassigns a ticket to Agent 02 in a different department having an SLA of let's say Agent Work Time of 2 hours.
I see that someone asked a similar question in the comment section and it was never addressed. I would appreciate if someone could explain this to me. Thanks.
Our support process relies heavily on light agents. Most of our tickets are created by light agents as requester. First Reply Time works fine. But Next Reply Time seems only to work with end user comments.
Is there a workaround for this? This implementation kinda looks half baked, as one metric works, but the other doesn't.
Hi,
I have a question about Agent Work time and using this in a SLA policy.
Our basic SLA policy is First Reply Time and Next Reply Time --> 24 calendar hours (7 days a week)
Besides that, we use status Pending for tickets, and this can last up to 3 weeks.
We also use status On Hold, and this can last up to 1 week.
How do i configure the policy so that Pending and On Hold tickets don't breach SLA?
Kristel,
SLA is not based on Status but on Public Comments so you will always run the risk of breaching SLA regardless of the Status of the ticket.
The way you are set up right now, you will not breach SLA unless the last Public comment is from the customer. If you add any other metric you still will breach SLA if the last public comment is from the customer.
Let's say you add Agent Work Time for a 3 week Period. Then you place the ticket in Pending. The SLA for Agent Work Time will Pause. However, if the customer decides to send you an email for some reason (even to say thanks) then the Next Reply Time will kick in. And, you will breach if you don't respond within your limit. There is no way around it unless you program your own stops via trigger.
Thanks Susan, that clears things up!
What kind of trigger do you mean, can you tell me more about this?
Kristel,
Using triggers to manipulate SLAs is akin to writing your own mini SLA system. I had to do that for my team because what Zendesk offers was not completely adequate for us and we were running into issues where my agents were jumping through hoops to try to accommodate.
I am not sure how large an organization you have. If you have a small organization there is an easier way to do this without having to use triggers:
1. The easiest way for you to manipulate the SLA is to play with Priority. Use Low priority for "no SLA" . So when you set your ticket ON-HOLD or Pending tell your agents to change Priority to Low. Then the SLA will go away.
2. If that is a concern because customers will see it and they will complain. You can do the same thing by creating a custom field. Call it whatever you want. Let's say SLA OFF. Then your agents will mark this Checkbox when they want the SLA OFF. In your policy you will check for this field to be off. So, when it is on the policy doesn't apply. When it is off it does.
If you have a large organization with a complex process like I do where you would need manager approval to do something like this and you do not want people to manipulate SLA willy-nilly then it gets a lot more complicated than this.
I had to write something rather complex with a combination of triggers/automations/macros and custom fields. I can take that offline if you need to.
Hi Susan, thank you for taking the time to clarify! This is very usefull and can actually work very well for our team.
We will try this out and if i have more questions i will kindly take on your offer and sent you a message.
Hey All,
Is there any way to ignore tickets in the "New" status? I only want the SLA's to be active when the agent is actually working on the ticket. We work with a tiered system where agents get assigned tickets, and a "New" ticket may sit until an agent has the bandwidth to take the ticket and work on it. So, tracking tickets in the new status make our SLA's tough to reach in some cases.
Thanks,
Jason
Could you just ignore First Reply Time and focus on Next Reply Time?
Hey James Green,
Would that not still track the time from the when the ticket is first submitted and in the new status since it is the time between the oldest, unanswered customer comment and the next agent comment? Or am I misunderstanding the definition of "Next Reply Time"?
Thanks,
Jason
I notice that the First Reply time SLA is not activated for tickets our agents create or API generated tickets (API account is an agent).
Reading above, I see for agent generated tickets, that "SLA first time target is immediately satisfied. It does not activate or record an achievement. Is there any known work around to capture First Reply Time. Maybe this is now 2nd Reply time. I don't want to turn on 2nd reply time SLA as its on every subsequent reply
Hey Jason Fouchier
My understanding was that Next Reply Time is only counted from subsequent end user comments, not the first comment. So if your agent answers or even solves the ticket with their first reply, the first reply time could be large, but there would be no next reply time at all unless/until the end user writes back.
I could be wrong! I'd better let someone from Zendesk chime in :)
Aidan,
First reply only applies when the end user opens the ticket. This means that the user either opened the ticket via email or online. When an agent opens the ticket (or API opens the ticket) the system assumes that someone has already talked to the user and that conversation resulted in this ticket being created. Therefore, all comments created from then on will be set to either Next Reply Time or Periodic (or Pausable) Updates if you have those set up.
I hope this helps.
@Jason,
While status is not part of the criteria for SLAs what you may be able to do is set a trigger to add a tag for all tickets at creation time. Something like:
Ticket is Created
Status is New
then
ADD Tag status_new
Then in your policy check if ticket Contains none of the following: status_new and that way your policy will not apply to your tickets in new status.
You will also need a trigger to remove the status_new tag when the ticket changes status out of new. Something like:
ticket is updated
tags contains at least one of the following status_new
status is greater than New
then
Remove Tags status_new
This should work
=====================================
On First Reply Time - This only apply when the ticket is first opened by the customer
subsequent replies from the customer will get Next Reply Time. This is assuming you have timing for these in your policy.
If you do not want to bother with First Reply Time, just don't use it in your policy and then you will not have to worry.
But, remember, if you ONLY use First Reply Time then ALL answers from the customer will get First Reply Time regardless.
I hope this helps
Hey @Susan Maher and James Green,
Thanks for the tips and advice, I will give them a try and see what happens. Thanks again.
Jason
Thank you Susan. Did i get a very local response from Ireland !
Aidan,
No, I am in the US. :)
There is Irish ancestry there with that name :) Thanks again
Hi,
I would like to base our SLAs on two metrics: First and Next reply time.
1. Is First reply time SLA counted correctly also for tickets with no public comment? E.g. tickets for missed chats with internal note only?
While reassigning tickets to another department, our agents update customer on what is going on. In such case none of the two above SLA is applied anymore. Periodic update time seems to be a solution here.
2. When agents reply to customers and no more action seems to be required on our side, they submit tickets as pending. Since periodic update SLA doesn't pause then, would such tickets count as breaching SLA in Zendesk Support SLA Explore dashboard?
3. If customer replies, would such ticket possibly have SLA breached since the time has passed since the last update on our side?
Thank you for your help.
Mateusz S
1. Is First reply time SLA counted correctly also for tickets with no public comment? E.g. tickets for missed chats with internal note only?
ANSWER: SLAs work on Public Comments ONLY. First Reply applies after the First Public Comment from the End user. It only applies Once during the life of the ticket.
While reassigning tickets to another department, our agents update customer on what is going on. In such case none of the two above SLA is applied anymore. Periodic update time seems to be a solution here.
ANSWER: Periodic Updates like all SLAs also work on Public Comments. A ticket with no Public Comments will have no SLA Policy applied
2. When agents reply to customers and no more action seems to be required on our side, they submit tickets as pending. Since periodic update SLA doesn't pause then, would such tickets count as breaching SLA in Zendesk Support SLA Explore dashboard?
ANSWER: SLA is breached only if you have a policy that has values in that metric. If you do not measure a particular metric then there is no breach. If your ticket has a banner in it and it shows Green then you have a "no breach" situation. If you have a "Red Banner" you have a breach and it will be counted for sure. The banner will tell you which metric breached.
3. If customer replies, would such ticket possibly have SLA breached since the time has passed since the last update on our side?
ANSWER: SLAs breach when we do not respond to the customer. They do not breach because the customer responds to us. If the ticket had already breach, then the timer will not be reset, the ticket will remain in a breach condition. However, if the ticket had not breached, then the timer will be reset to Next Reply Time.
When you think of SLAs think about a conversation. You have 3 different situations:
1. You have a conversation with a customer. Customer contacts you, you respond, customer responds, etc. This is where you worry about reply time (first and next)
2. Next case is when customer contacts you with an issue that requires research. You have work to do that will take time. So here is the scenario: customer contacts you, you respond to customer that this will take time and that you will let them know when you have an update. Time passes by and you need to keep the customer informed so they know you are still working on their issue. SLA in this case will deal with Periodic Updates.
3. Last case is when customer contacts you, you respond with a solution but the customer wants to test and be sure your solution is valid. Customer asks you to please do not close the issue. You place the ticket in pending. Time goes by and the customer doesn't call back. You want to follow up to ensure your solution works. SLA in this case deals with Pausable Updates.
You do not have to work with all of these values in your policies. As a matter of fact you may choose to work with only one value. You need to design your SLA philosophy and then implement. I hope this helps
Thank you Susan Maher, this is very helpful.
Ideally, I would like to work with only one policy, however, this is very important for us that all the tickets haves SLAs applies. Otherwise, tickets are left at the end of the queue and not picked-up by agents.
I'm left now with tickets that have no public comment (as tickets for missed chats). Do all SLAs work on public comments only? Would Agent or Requester wait time help here maybe?
Mateusz,
You can set up a Policy that checks for tickets that have not Public comments and set the Agent Work Time and the Requester Work times. This will work You can manage these tickets that way.
These metrics do not work on Public comments. Of course you could mic the metrics on the same policies but it may become confusing. Again, your issue is not simple, you are going to have to design your SLA process and then study how to implement it.
Mateusz
Sorry for the typos. I was a crazy day at work today and I had some issues with my own SLAs as well. I have to add some more logic for my enhancements. But back to your case, I would like to clarify something on my previous statement. The Agent Work Time and Requester Work Times do not reset the same way as the Reply times so be careful if you decide to use them. Entering Private comments will not reset these times. You will have to combine these with Pausable Updates and Periodic Updates. As I tried to say before you have a complicated case here.
It seems to me that there are a lot of paying customers here that need to calculate First Reply Time on something other than a Public comment from an End User - those creating tickets on behalf of end users via their own systems integrations, missed chats etc etc.
I'm wondering if someone from Zendesk could share an update on the status of this feature request? It's been added to your request list and up-voted for several years. There seems to be a lot of customers needing to do manual work-arounds or in-house solutions for what should be an obvious and easy feature
Hi there !
I read that the Next reply metric begins with the oldest unanswered customer's comment.
Does the term "customer" mean any end user, not necessarily the requester ?
That is, CCs added by the requester or by an agent, as well as other person sharing the ticket in case of shared organization ?
Please sign in to leave a comment.