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
For more information about viewing SLAs as an agent, see Viewing and understanding SLA policies.
To learn about setting up multiple versions of policies, see Versioning your SLA policies.
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.
SLA stops when the ticket is solved.
Understanding what metrics you can measure
You can define SLA service targets for five different metrics: first reply time, next reply time, periodic update time, requester wait time, and agent work time. The first three 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. The first reply time metric is not applied to tickets created by agents, unless the ticket is created through a private comment (as described in Creating a private ticket for an end-user). If a ticket is created with a private comment, the SLA first reply time target will not start until the ticket gets a first public comment from an end-user.
- 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.
First reply time and next reply time metrics always use an end-user comment as starting point and a public agent response as an end point. The following graphic shows how the first- and next reply time 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. 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 you should only choose one resolution time metric.
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.
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.
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
- Click the Admin icon (
) 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.
- Click the Admin icon (
) 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
- Click the Admin icon (
) in the sidebar, then selecting 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 the Insights object reference and Insights metrics reference), or use the pre-built reporting dashboard (see SLA reporting dashboard overview).
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.
143 Comments
Craig - I've had conversations with Erin about this as well - ideally, we would be able to have a custom SLA that lets us determine which status's it runs in, but until then, something that doesn't run in pending or on-hold would solve most of our problems.
thank you!
Craig - thanks!
I implemented the following...
This seems to be working fine
Hi Erin,
Is the reporting dashboard available within the format/ screenshot you has illustrated within an earlier post? It looked slick as an 'at a glance' view and exactly what I am looking for.
We have setup our ticket SLAs and breach alarms, however, are really struggling with setting up the associated Dashboard view to see how we are trending against our initial and follow-up response target times - as a number and percentage reflection. Is there an intuitive 'How To' document that guides clients upon the dashboard setup and views?
Not sure if anyone else has had any similar challenges and successfully resolved them?
@Vinay: Ah, that's an old mockup of what the Insights dashboard might have looked like. We have an article which explains how to get started on that, I hope it's helpful.
Jeff - Tried your suggestion, but I have problems with it. I use Next response, and First Response SLA's, and your method conflicts with it, instantly sending my slaps into failure. This didn't happen in the past before the periodic sla change zendesk made.. Guess I'm back to waiting for a solution from zen!
Brian - hmmm I do not understand why there would be a conflict?
We also use First, Next and Periodic SLA's.
When/If the ticket re-opens due to Requester response the SLA is reactivated via Trigger (tag removed) and the ticket is then subject to the Next response SLA.
When/If the ticket re-opens due to a trigger then the Periodic SLA is immediately expired. However we have an Automation to close our non-Urgent Pending Tickets after 5-days of no response so most Auto Close.
Have there been recent changes to the SLA metrics?
Our team has been using "Agent work time" to track how soon a ticket gets a call back after being moved into a "Open" status (with other relevant tags). It used to be that the time until next SLA breech would start at the moment that the ticket was put into Open. Now we're finding that the time is calculated from when the ticket was created (ie since it was New), but this is not how we set things up, and it's causing some reporting problems for us.
Was the "Agent work time" metric changed? Is there any other metric we could use to accomplish our goal?
Jennifer,
There haven't been any recent changes to the Agent Work Time metric. Please submit a ticket with examples of the issue you're experiencing, and we'll investigate.
Craig - what is the update on the new Metric you mentioned on October 03, 2016 15:55 for Periodic Update?
Gadi,
It's been built for a couple of months now, but unfortunately, it's been tied up by a third-party integration issue. We have people actively working to get that resolved, so it should hopefully be made available in the next couple weeks or so.
This is promising.. I'm having a hard time however, apparently nothing has breached my SLA. I know I have tickets that are breached.
Here is the rule I have set for testing this.
All new tickets that come in go to our Unsolved Group and are automatically marked URGENT
The SLA condition is
Ticket Status is Unsolved
Target
FRT - Urgent - 3h, High -4h, Norm - 5h, Low -6h
I have tickets in the system that have not been responded to in over this threshold, but the SLA is not breached?
any insight?
Hello Brian - just a possibility, but do you have any other SLAs set? A ticket can only work on one SLA, so the first one in the list that it meets the conditions for is the one it will be measured by. I got caught on that once.
Having a bit of trouble with SLAs on certain edge tickets.
There are cases where one of our frontline agents might send a public reply to a customer, thus meeting the SLA, but then they need to reassign the ticket to another internal team to carry out some action. When it hits that other team's view, it shows up without an SLA so it is moved toward the back of the list.
Wondering if there is a way to optimize our workflow so as not to miss these tickets (right now, I know there's no way to get the SLA re-applied as there was no follow-up comment from the customer).
@Zac, take a look at the Periodic update or the new Pausable udpate SLA metrics.
If an agent needs to assign a ticket to another team/agent after informing the ticket requester about that with a public reply, using any of those metrics the agent would only need to submit the ticket as Open, instead of Pending or Solved, when answering to the customer to keep the next goal SLA counter active and then assign to the proper team/agent without updating the ticket status.
Hope this helps!
Have a question. We are running into a issue where a couple of our SLA's are voiding each other out based on the order the SLA is set under the configuration and i dont know why. Basically i have 2 SLA's setup. 1 is our First Reply Time and the other is our Next Reply Time. Both have the same conditions but the Next Reply Time looks for existing tags. If i change the order of the SLA "Next Reply Time" to the top of the list it works, but then the "First Reply Time" SLA wont. If i move the "First Reply Time" SLA down in the order it does not trigger. Does anyone know why this would be occurring? Have i done something wrong? Or can we only have 1 SLA for both First Reply Time and Next Reply Time?
Tim,
Only one SLA policy can be associated with a ticket at a time. If you want both First Reply Time and Next Reply Time to be tracked on the same ticket, those targets must be configured as part of the same policy.
Thanks Craig for the explanation. Thats too bad it works like that.
Is it possible to set an SLA timer based on the time since a specific event?
I'm looking to set an SLA that tickets escalated between service tiers.
I want to start a timer from the time the ticket is escalated by an L1 agent, that dictates how long the L2 agent has until they must reply.
I can't seem to find anything that lets you start an SLA timer based on a specific event, such as a tag being added to a ticket.
Any suggestions?
Hey Mike!
It is not possible to set an SLA timer based on a specific event. However, as you've pointed out, if you want to you can use a ticket tag as a condition for your SLAs. If that tag was not present prior to that update then you would essentially be causing the SLA be applied based on that event. If this tag is being added when your agents escalate their ticket then this should meet the conditions you are looking for the SLA to be applied to.
I would caution however, that there are not any SLA Targets that would fulfill your criteria here in stating there is just an SLA for the next L2 agent reply. The only option I can foresee being used for that is Periodic Update which would continue applying the SLA requirement for every update. First reply time would not be applicable for a ticket of this nature.
Has "hours of operation" been removed from the Targets? I do not have this option when I make SLA's
Hi Daniel
First you need to enable business hours in order to see it when setting up SLA's.
Click the Admin icon on the side bar >> Settings >> Schedule >> Enable.
You will then see the option when setting up SLA's as showing on the image below:
Hi,
Is it possible to set conditions based on the ticket's requester's custom user fields, instead of just ticket fields? For example, our Single Sign-On payload includes some fields like Billing Cycle and Account Type.
I want different SLA policies for different account types, e.g. First-Reply Time should be X for Business users, Y for Pro users, and Z for Free users.
As a workaround, I also pass Billing Cycle and Account Type as tags during SSO and keep them in sync using automations. I suppose I could ALSO have custom ticket fields and set up some triggers, but that seems a bit overkill.
Side question: If user's tags change (whether manually by an agent or automatically from an automation or a new SSO payload), do the existing inherited ticket tags also change?
Thanks,
James
Hey James!
Yes, custom user fields can be found in the SLA conditions drop-downs when configuring your SLAs. Configuration options in these drop-downs are grouped so you should find a Requester section after your Tickets section.
User tags are only passed on ticket creation so an update after the creation event will not retroactively affect existing tickets.
Thanks James,
I see the Role field under Requester, but no other user fields - default nor custom.
SLA screen:
User screen:
Hey James!
My apologies, it does appear you're not seeing that option in your account. I'll go ahead and bring you into a ticket at this point so we can further troubleshoot this. Also, I'm not sure if your User UID is accessible or useable elsewhere but I would not generally recommend posting that publicly! If you wanted to edit your comment I believe it would be best to remove that.
Please keep an eye out for an email from me with the ticket I'm creating to work with you on this - thanks!
Thanks! User UIDs are publicly accessible on our site and APIs, so no worries there.
Hey. I have a very easy question for anyone on this thread. Is it possible to set SLA's even if we are not using the priority field on our ticket forms?
Dan
You must set a priority to use SLAs. If you are not using the priority field, you can use a trigger to set all tickets to a default value.
Hey Dan!
In order for an SLA policy to be applied to a ticket it will require that the ticket's priority is set.
Also, for anyone who had followed along with James' question about custom user and organization fields in SLA policies: Only custom org/user fields that have defined values such as drop-down, checkbox, and date fields can be utilized in SLA conditions.
Graeme/James. Thanks for the quick answers. It's much appreciated.
Please sign in to leave a comment.