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.
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 ?
I believe that the clearer answer is a public comment entered by an end user.
Ok, thanks Susan.
When an end user enters a comment, does the ticket status automatically becomes open (from pending or on-hold) ?
Yes, the ticket will go back to open. Regards, Susan
Thank you Susan !
I am using the pausable update metric and I would like to have it paused while the dev team is working on the issue (for a bug fix or a new feature implementation), after having given the time estimate to the requester. I’m tempted to put the status to pending, but if the requester or CC goes to the portal, the ticket would look like we are awaiting the requester’s reply. What if I add a condition to my SLA policy like ”type is not task”, and set the type to task or add a tag, then reset things once the dev team has finished ? Would that pause the SLA clock ?
What would be the best practice ?
If you add a condition to your policy such as checking if Type is Task and then setting the ticket to Task, the Policy will then will apply only to tickets that are not Tasks. This will stop the SLA all together until you change the ticket back to Problem or Question.
This will certainly accomplish what you need to do. However, you need to consider the following:
1. If the ticket takes a long time to resolve (I do not know the nature of your business so I apologize if my assumptions are wrong), it is possible the ticket will be forgotten and the customer will not get any updates for a long period of time
2. If during the time the ticket is in development being fixed the customer writes back to request status, there is a chance the ticket could be missed at least for a while.
Having said that, if you already have processes in place to avoid these, the solution above is correct. Good luck. Susan
Thanks for your reply Susan.
I must confess that I don’t see any big risk in stopping the SLA while the issue is in development, and we consider not necessary to give periodic updates in this case (since there’s not much to communicate).
Besides, we could set a separate SLA for the update metric and add the condition only to this set of SLA so that other metrics wouldn’t stop. ?
Am I missing something ?
Anyway, I would love to learn how Zendesk and other companies deal with this.
Sounds like you have it covered so it should work Again, I do not know your processes. I believe it should work. it is a great solution. I believe a cleaner solution than what I actually implemented.
Would be nice if you can test a SLA Policie
You have a couple of ways of testing SLA policies. One way is to use a Sandbox System. I set up all my work in the Sandbox first and test there before implementing in production.
However, that is a paid option. So, if your organization doesn't have a Sandbox System then you can control the SLA policy via tags or a custom field that you can test for. This way the SLA will only be in effect for those tickets that contain that tag or Custom field set.
Once you create your policy you can then create test tickets, notifications, etc based on that criteria and test that way.
I hope this helps.
Wondering if there are any updates on previous feature requests for a first reply-time SLA that behaves like the first reply-time metric? We have a few use cases for tracking, via SLA, how long an agent has to make the first public comment on a ticket that only has one internal comment.
I found links to some other community guide posts asking for the same thing, but got an access denied error on all 3 pages so I'm assuming they've been deleted by the original posters or moved somewhere else.
How do you do a "Resolution time" SLA? Our SLA require that a ticket be resolved in X amount of business days depending on the importance of the ticket. Urgent must be resolved in 1 business day.
You may want to consider using Agent Work Time.
Otherwise it will get complicated.
What is considered part of calendar hours? Are weekends and holidays excluded or are those only excluded in business hours?
We want to set our business hours to 8am - 5pm, Monday - Friday.
Our first reply time metric is within 24hrs. Tickets submitted on Friday should not breach SLA on Saturday, but on Monday if not responded within 24hrs from Friday time.
I have the SLA set to 24 calendar hours for first reply time metric.
SLA can be defined as Calendar hours or business hours. Calendar hours means that SLA assumes that you are going to respond 24x7 and therefore SLA will breach on any day of the week whenever the SLA reaches the time you allotted for the response.
In order to use Business hours you need to set a schedule. To set a schedule you need to go to Settings and click on Schedules.. You then can add your Schedule with the hours you indicate above (M-F 8-5) You also can add Holidays to the schedule.
Once you define the schedule, you may change your policies to calculate the SLAs in business hours rather than calendar hours. SLAs then will breach on weekdays rather than outside your business hours. I hope this helps.
Thanks Susan. Yes, I have that all set up. I was hoping that calendar hours didn't take in to account weekends and holidays.
Changing it to business hours for the SLA would result in a much longer timeframe (24 business hours) that isn't exactly what we are held to.
While the system only give you those two choices, you can get creative. You have the ability to define your schedule however you desire. Therefore, if you would like to have SLAs breach anytime during the week but skip weekends, then define the schedule accordingly. Additionally, you may have more than one schedule.
However, once you have more than one schedule, life gets more complicated because you will have to create triggers to set the schedule according to the correct criteria. It will depend on your use case.
Unfortunately, the way SLA is set up "out of the box" is rather simplistic and doesn't allow for much creativity.
We have a rather complicated scenario, but I had to do a lot of work.
How do we track the next reply time if there is no metric on zendesk explore to track this?
If you're referring to the SLA dataset, then you should be able to report on the status of Next reply time SLA targets in Explore. But, if what you're looking for is to build a granular report to show the duration between each agent replies within a ticket, then I'm afraid that's not possible with the native metrics and attributes currently available in the SLA dataset, and any other datasets in Explore. Sorry about this limitation, Rylan.
Thanks for your reply but there isn't really a metric for the Next reply time on Explore. If there is please let me know which metric I need to use to create a report for this?
You can try using the metric SLA tickets (in the Support: SLAs dataset) and then filter or slice your report by the attribute SLA metric. You can set your report to display only the SLA tickets with the target Next reply time.
From there, you can further slice your data by SLA metric status (Active or Inactive), SLA target status (Achieved or Breached), etc. You may refer to this article to see all the metric and attributes available for SLA data: SLAs dataset.
Is there a way to track SLA's after a ticket is escalated (assigned to a particular group)? We escalate complaints after solving some incidents, and we want to be able to set SLAs (first reply and resolution time) for those tickets from the moment the escalation happens.
Thanks for sharing this. Is it possible to get the actual value for the Next Reply like how we have for the First Reply Time rather than just knowing where it was achieved or breached?
You can track the SLA's ticket by using the SLA attribute Ticket group along with the SLA policy name. Regarding setting the SLA after the ticket is escalated is not possible as the SLA counts the interaction with the requester (most of the time customers). If you want to have a new first reply and resolution time metrics applied, a new ticket will need to be created for the new team.
Since the Next reply time is the time between the oldest unanswered customer comment and the next public comment from an agent, displayed in minutes., you can use the attribute Requester wait time (min/hrs/days). That will measure the number of minutes a ticket spends in the New, Open, and On-hold statuses. This number is only measured after a ticket status is changed from New/Open/On-hold/Pending/Solved/Closed.
Is it true that you cannot apply SLAs to tickets created via the API. Is there a workaround for this?
Tickets created via the API will have the SLA policies evaluated the same as any other ticket. So there should be no workaround needed.
An SLA policy can have a 'channel' condition so that it only applies to tickets created via the API or never applies to tickets created via the API or relates to another channel. That may be causing the confusion.
One thing to note about API created tickets, if the initial comment is a private note (which is fairly typical) then reply time metrics will not be evaluated.
is there any way we can avoid breaching requester wait time SLA in case a requester reopens a ticket by making another comment? For example, if a ticket has initially been created a few weeks ago and resolved. If the customer makes another comment, the ticket would breach the requester wait time metric instantly (as the ticket creation time is relevant for this metrics). Do you maybe have an idea?
Patrick Rieger, it might be that you're not setting your tickets to Closed, rather leaving them in Solved status?
If you do set the automation to close tickets after a certain period of time, even if customers reply to the same email, a new ticket would be created instead of re-opening the same one. This would solve your issue.
Hope this helps.
Please sign in to leave a comment.