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.
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 Structure of SLA policies).
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 Policy Name.
- Optionally, enter a Description.
- Select the Conditions for the 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. It's recommended to use only one of the two resolution time metrics.
Note: The minimum target time you can set is one minute.
- If you've set a schedule, select either calendar hours or business hours for Hours of operation for each priority.
- Click Save.
The SLA policy is created.
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 six different metrics, which include reply time and resolution time metrics.
Reply time metrics
Reply time metrics help you understand how your team is performing in regards to responding to your customers and keeping them informed while their issue is being resolved.
Reply time SLA policies aren’t currently supported for chat or messaging tickets.
First reply time
First reply time is the time between ticket creation and the first public comment from an agent. 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. 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 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:
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:
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 uses an agent's public comment on a new or existing ticket as a starting point. 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 no comment or an internal note.
Resolution time metrics
The resolution time metrics use the ticket status (or status category if custom ticket statuses are 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.
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 or Agent work 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, 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.
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
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.
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.
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?
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?
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.
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.
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.
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.
The article states "For SLA policies to work, tickets need to have a Priority value. If you do not set a Priority then none of your rules will be met." This makes sense because in the SLA policies, the targets are specific to each of the 4 priorities. However, when I view the event history of individual tickets without a priority, they've had SLA policies applied, at least some if not most or all of the time.
Is that statement incorrect or outdated? Does the handling default to Normal even if the field holds no value?
I intend to add a trigger (or modify existing ones) to cover this, but I'm really curious about what causes those w/o a priority to still have an SLA policy applied.
Hello Mark, thank you for your question!
It is true that the Events will show that the SLA has been "applied" but in truth, it is not being applied correctly if the ticket has no priority. The events show that a specific SLA has been assigned to the ticket, because the ticket meets the SLA's conditions. But until a priority is set, no timer or SLA badge will appear, meaning that no SLA clock is actually being counted yet.
It is best to always apply the priority, either manually or via a business rule as you mention. The fact that an SLA is seen in the events does not mean that actually being measured currently on the ticket, only that the conditions for that SLA have been met. But without a Priority, it will not work correctly.
I hope this was helpful!
Hello Customer care team!
I am following the steps to set start setting up SLA's but I don't seem to have it? Maybe my level of access?
Please see above where Business rules > Service level agreements. is missing,
Please inform me as to why? A little new to setting up here,
Mobyfox Customer support Thanks for the question! The first thing to check, is take a look at the top of this article which highlights which plan types includes SLAs. If you need more help feel free to reach out to our support which you can do by clicking on the chat icon bottom right on this page.
What happens with a breached SLA target when the submitter incorrectly labels a ticket which results it being routed to the wrong ticket group?
Example - A ticket breaches the first reply SLA when assigned to ticket "Group A" and then gets reassigned to ticket "Group B". Does that First Reply SLA breach now count against Group B or does it stay with Group A? Both Group A and Group B have a First Reply target in their SLA policies.
Or can the answer to this depend on how the specific SLA report is configured? I'm using the default Support- SLAs dataset and looking at the "SLAs" tab of the pre-built Explore dashboard. I'm not very familiar with the Support - SLAs dataset.
Unlike updates history, SLA dataset will just record the met/breached target. The group or assignee associated with it will always be the one showing in the Assignee field and not the group/assignee that was associated with it when it was met/breached.
For more information, please check SLA datasets.
Is it possible to remove a ticket from an SLA policy once it has been set?
Ticket comes in via chat, but needs to be escalated to a phone call. However, we would want it to jump to the top of the queue (we sort by SLA timer). I tried this in sandbox, to basically add a tag to remove it from one policy, and add it to another, but no luck!
Hi Bobby Koch
Did the tag get added to the ticket? Also, after adding the tag, it was still under the same SLA policy?
Could you provide a screenshot of the business rule you created for the tag & also the SLA?
Does the Requester Wait Time Metric also calculate the time from the merged tickets?
We had merged about 5 tickets into another high priority ticket and the requester wait time came out to be about 44 hours and we believe it might've calculated the time from the merged tickets as well.
Please sign in to leave a comment.