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
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.
If you apply or change an SLA target that is already breached, the breach will be recorded at the time of the update. SLAs do not back-date breach events.
Understanding what SLA metrics you can measure
You can define SLA service targets for six different metrics: first reply time, next reply time, periodic update time, pausable update, requester wait time, and agent work time. The first four 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 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, and then 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 while you can choose multiple resolution time metrics, it is considered 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.
Reopening tickets effect on an SLA
- 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 metrics activate new targets.
- Periodic Update: If a ticket is reopened with an end user comment, nothing will happen. If a ticket is reopened, with or without an agent comment, the relevant Update metrics activate new targets.
- 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, the relevant Update metrics activate new targets.
- Agent Work Time, Requester Wait Time: These metrics reactivate 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
- In Admin Center, click
Objects and rules 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.
- In Admin Center, click
Objects and rules 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
- In Admin Center, click
Objects and rules in the sidebar, then select 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 Metrics and attributes for Zendesk Support and Explore recipe: Reviewing SLA performance), or use the pre-built reporting dashboard (see Analyzing your Support activity).
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
- In Admin Center, click
Objects and rules 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.
51 Comments
Hello,
I happen to log into my helpdesk over the weekend and noticed that a SLA was about to hit its limit, I initially ignored it assuming the countdown was paused as it was a Saturday and my schedule has the support desk "closed" on Saturday and Sunday. About 2 hours later I noticed that same ticket had -26m under its SLA, so I am confused why it's doing that. I have the SLA set to "Business Hours" and my schedule is set from 8:00AM - 8:00PM Monday through Friday. I have the SLA for this particular customer at the top of the list of SLA's and it is set to apply only to tickets where "Brand is Acme", which would apply to this ticket.
Am I not understanding how the SLA's timers work?
When are we going to have the option to create a trigger based on SLAs? We want to tag tickets and notify teams immediately an SLA is breached. We don't want to wait till a full hour when our support team operates in seconds
Jesuloluwa
I think it unlikely that we will get a trigger notification based on SLAs. Triggers are designed to fire when an agent or a user updates a ticket. As you noted, automations are based on time but only fire hourly.
For live monitoring of SLAs, Views sound like they better suit your needs. Here is an article on adding the SLA breach countdown to a view.
Hey Graeme,
Views will not suit our needs. Once an SLA is breached, we want to notify external channels like Slack to notify certain people that will take immediate action.
I think it's a basic feature really as I know other CRMs that offer this.
Lolu I'm the Product Manager here at Zendesk responsible for our SLA capabilities. We recently kicked off an ambitious project to enhance our feature set in this area and I'm pleased to say that we are planning to provide near real-time notifications for SLA breaches. Look out for more on this later this year, likely in Q3. Really appreciate your feedback. Thanks.
Hello,
I have a question. Does business hours mean that time will be paused for all SLAs?For example: I set the Pausable update to 24 hours. Will time be paused outside of business hours?
Thank you,
Zbyněk ČeperaYes, that's right. Calendar hours would continue to run the clock as normal, but if you select "Business Hours" then SLA measurement pauses.
I can't find a metric in the SLA dataset for Next Reply Time.
How do I report on this?
Kristin Bouveng First select any of the SLA metrics, then you can apply a filter for next reply time. For example:
What happens to historical reporting on an SLA if you delete a policy?
Hi CJ,
It looks like if you delete an SLA policy, the data for it in Explore will stay on all tickets the SLA policy was applied to. The only difference I am seeing after testing in my account is that you are unable to open the ticket links for tickets the SLA policy was applied to.
Hope this helps!
Completely baffled by the behaviour of SLA policies when tickets reopen - see bold text below:
What's the thinking here? Surely if a ticket reopens, the update SLA targets should appear again? Some action is expected from the agent in almost all cases, right? Am I missing something? Is there a workaround?
Hey Terry Knox!
The use case for these two SLA targets are for agent created tickets. If an agent makes a ticket proactively, then the first reply time and next reply time targets are not applied to the ticket, so these SLA targets hold the agent accountable for updates to your end users. In order to also include End User replies that reopen the ticket, you could add the Next Reply time target to your SLA policy so that a target is applied regardless of who reopens a ticket.
I hope this helps!
Justin H - Presumably I can "layer" on Next Reply Time in addition to the other options, to catch cases like this? I'd still want Periodic/Pausable Update to be policies used in almost all other cases.
Terry Knox
Yeah, that's right. The screenshot below is the test I did in my account, and after reopening the ticket with an end user comment, the NRT target was applied. When the agent replies, then the Periodic Update is applied.
Thanks!
Hi all,
I wanted to set up SLA Alerting at 25, 50, 75 and 95% progress using Automation. As if the limit of hourly automation was not enough of a problem, I then find out that the Automation condition 'Hours until next SLA Breach' will not be met if the ticket is status Pending. So if the ticket is open for 55 minutes every hour but by some coincidence is pending for the other 10 and when Automation runs, the ticket will breach with no warning whatsoever.
Does anyone have any suggestions or products to help manage SLA Alerting as clearly Zendesk is not up to the job.
Thanks
This is something our product managers are looking to improve so I'd recommend taking a look at the following announcement: An easier way to see upcoming SLA breaches
You'll want to take a look at this comment in particular.
Not sure if anyone else has a workaround but I did want to make you aware that we are listening to your feedback :)
Martin Cubitt Just to add to Brett's reply above, until Zendesk supports real-time alerting natively I'd recommend you check out one of our partners to provide this functionality: https://sweethawk.com/
Hi! When are you planning for SLA policies to support chat or messaging tickets? Those are extremely important channels for us your Latam customers. It's more common for us to use chat/messaging than calls/email.
Sacbe Alfonsina Ibarra E Thanks for the question! We do have plans to fully support SLAs in our Messaging product late this year. There are no plans to support it in Chat. For more details or updates you may wish to follow this other thread.
Please sign in to leave a comment.