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
Risetime
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?
0
Lolu
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
3
ZZ Graeme Carmichael
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.
0
Lolu
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.
2
Scott Allison
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.
2
Zbyněk Čepera
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,
0
Scott Allison
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.
0
Kristin Bouveng
I can't find a metric in the SLA dataset for Next Reply Time.
How do I report on this?
0
Scott Allison
Kristin Bouveng First select any of the SLA metrics, then you can apply a filter for next reply time. For example:
1
CJ Johnson
What happens to historical reporting on an SLA if you delete a policy?
1
Justin H
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!
1
Terry Knox
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?
0
Justin H
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!
0
Terry Knox
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.
0
Justin H
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.
0
Terry Knox
Thanks!
0
Martin Cubitt
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
1
Brett Bowser
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 :)
1
Scott Allison
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/
0
Sacbe Alfonsina Ibarra E
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.
1
Scott Allison
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.
0
Mark Szymanski
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.
0
Beto
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!
1
Mobyfox Customer support
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,
Many thanks!
0
Scott Allison
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.
-1
Ronald
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.
0
Dane
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.
-1
Bobby Koch
Is it possible to remove a ticket from an SLA policy once it has been set?
For example:
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!
0
Dainne Kiara Lucena-Laxamana
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?
0
Vivek Thakore
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.
0