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 aset structureconsisting of conditions that a ticket must meet and the metrics you choose to measure. Note that you don't need to set a target for every metric when setting up an SLA policy. SeeBest practices for using metrics together.
To set up an SLA policy
- InAdmin Center, click
Objects and rulesin the sidebar, then selectBusiness rules > Service level agreements. - ClickAdd policy.
- Enter aPolicy Name.
- Optionally, enter aDescription.
- Select theConditionsfor the policy.
Start typing the condition to autocomplete or select an option from the drop-down menu.
- In theReply targetssection, enter a time target for each metric and ticket priority.
See回复的时间metricsto learn more.
Note:The minimum target time you can set is one minute. You can enter hours, minutes, or both. - In the更新targetssection, enter a time target for each metric and ticket priority. It's recommended to use only one of the two update time metrics.
See更新time metricsto learn more.
- In theResolution targetssection, enter a time target for each metric and ticket priority. It's recommended to use only one of the resolution time metrics.
SeeResolution time metricsto learn more.
- If you'veset a schedule,select either calendar hours or business hours forHours of operationfor each priority.
- ClickSave.
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 areapplied 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 (seeOrdering SLA policies).
Community tip!Mat Cropper shows how to set up SLAs so the correct policy is always applied inRunning triggers, automations, and reporting based on ticket SLAs. And Mark Powell shows how to set up SLAs for time zones inUsing 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.
回复的时间metrics
回复的时间metrics help you understand how your team is performing in regards to responding to your customers.
回复的时间SLA policies aren’t currently supported for chat or messaging tickets.
第一个reply time
第一个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 isnotcalculated 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. SeeDefining 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 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:
更新time metrics
更新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.
Resolution time metrics
The resolution time metrics use the ticket status (or status category ifcustom 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.
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:
- 第一个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
- 第一个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.
- Total resolution time: This metric reactivates and continues to count from the ticket creation time.
95 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添加SLA违反倒计时一个视图.
嘿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.
LoluI'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 BouvengFirst 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?
嘿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,
我想建立SLA提醒在25,75和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:看到即将到来的SLA违反一个更简单的方法
你想看一看这个commentin 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 CubittJust 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 EThanks 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 thisother 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 whereBusiness rules > Service level agreements.is missing,
Please inform me as to why? A little new to setting up here,
Many thanks!
Mobyfox Customer supportThanks 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 checkSLA datasets.
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!
HiBobby 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.
Pleasesign in留下你的评论。