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.
141 Comments
Wow Erin, this is great. Love the additional functionality.
Kevin.
Is there any reason why the new SLA system does not have full resolution time?
Hey Andrew,
Yes! The vast majority of customers we've spoken with don't actually want to measure full resolution time, and that's the primary reason we haven't added it. Now that could change over time, and we will continue to evaluate which metrics are important to customers and add things as it becomes necessary. We don't, however, want to overly complicate what's already a fairly complicated feature by adding options that most customers don't find useful.
All the best,
Erin
Thanks Erin,
I think I can understand that. Measuring resolution time only doesn't give a very good picture of what is happening. I'll work with what we have for now :)
I am grateful for the new metric, for many customers I am sure this will be an essential missing feature now delivered. Where I am struggling is the auditing of all these metrics. Which has breached, 2 hours until which metric etc etc. Adding this one is just creating more blur in the SLA status.
I have created my own collection of triggers and automations to set and clear tags to try and create an history that I can then report on. But I cannot do this for all the metrics as often I cannot create unique conditions.
Hopefully it will not be too much longer before a solution to this really complex requirement is available. In the meantime though please keep feeding our insatiable appetites. Thanks
We have a situation I'm not sure is supported and I could use some help: We only want to monitor Periodic Update Interval (PUI) when a ticket is in 'Open' or 'New' status - ie, some of our tickets are on hold until an event happens, which may be weeks out, and are set 'On Hold' and we don't want to apply the policy there. Is there any plan to allow us to use 'ticket status' to apply to our SLA policies?
We were doing this successfully when we did Next Reply Time because the customer response always moves it back to Open from Pending and On Hold. We were excited to see Periodic Update, but were bummed when we realized it wouldn't work for us.
So - we don't want to track SLA breaches for On Hold or Pending, only Open and New? Additionally, we don't want the PUI clock running while in Pending or On Hold as we don't want it to immediately go into breach when we move it back to Open. Any chance of that?
Hi Michael,
Right now I believe Periodic Update will be automatically satisfied when the status is in Pending, but not in On Hold. We don't have any current plans to allow for more customized use of statuses in our SLA policies.
Best,
Erin
This is a huge disappointment. I dont need SLA's for on-hold tickets. On hold means we know it is waiting on something outside of our control, yet if we want to use periodic response, we are tied to updating those tickets. I feel like it is a serious design flaw of your periodic response SLA.
Hey Guys,
My apologies if this has been covered but im having trouble with seeing the SLA timer. The SLA is configured, and i can see that it is indeed being applied via the audit trail of the ticket....
Ive activated insights and there are no metrics at the minute displaying on the SLA tab.
All help is - as always - very appreciated.
thanks
J
Hey Jamie!
It can take some time for information to get synced into Insights, depending on your plan. Are you still not seeing those stats, or have they since shown up on your dashboard?
I have to agree with Alex and Brian amongst others here.
The On-hold status is a 3rd party status right?
How are we supposed to be accounted for that time in a service level agreement environment?
@olaf - On-hold has had it's controversy since it's inception. Personally I think it's important to remember the clients experience. From their perspective - in our case - they are still expecting a response from us. I would suggest that if you have regular processes that require waiting on a third party, you may want to exclude these from the SLA - maybe create a distinct SLA to cover these ones?
@AndrewJ - Well if On-hold was not meant for third party cases I would be more prone to agree. I can of course only speak for our company but we always communicate the reason for setting a ticket On-hold.
If by "create a distinct SLA" you mean to alter our customer agreement, that's a no go. It's a non issue if a 3rd party has a scheduled disruption but what I am talking about are outages that are unintentional and unplanned. Therefore after we've assessed the issue and find out a 3rd party is causing the error - we report to both parties and set the issue On-hold. (Note that we are still reporting to our customers on an hourly basis even though the issue is On-hold)
One way of making that more clear to our end-users would be to actually display the status for them - instead of what is shown today - "Open"
OK, we are probably a little different - our 3rd parties tend to be contractors or services that we use, and though they are not our employees or agents on our helpdesk - we still consider that the client is awaiting something from us, therefore for the client the ticket is still 'open'.
If the 3rd party you are dealing with is not responsible to you, would 'Pending' with an explanation to the client be more workable? Who will the 3rd party advise when their issue is resolved?
No I'd say we treat 3rd parties in, roughly, the same manner - just that when the work is not on us to perform, the On-hold fits nicely, which I assume is the reason for its existence?
The suggested workaround feels more like a step in the wrong direction.
If I'm out on my tricycle here I'm open for suggestions :) But if not 3rd party then what was On-hold intended for in the first place?
Was created with 3rd party in mind. However as you have noted - the ticket is still open as far as the client is concerned - on the premise that they are still awaiting a solution, whether it be from us or our contractor. The discussion around how 'on hold' should show for the client was pretty robust and inclusive.
We take 100% responsibility for actions of our contractors, therefore if I have an agreement to follow up after a certain period... I will do that even if the delay is with a 3rd party.
We only ever put a request on hold for a specified period, and it reopens after that.
Other than what we've already discussed - what might some possible solutions look like?
I'll try another angle instead.
According to the SLA targets, the "Agent work time" does take into account the On-hold status. What use could I have of that?
That's a good way to put it :)
I can understand it being shown in Customer wait time... but agent work time is a bit odd. That said... Agent Work Time doesnt give any indication of ... agent work time!
I can't see much difference in Customer Wait time and Agent work time. :shrugs:
@Nora Mullen - can you clarify what the point is here?
Agent work time pauses on both Pending and On-hold. If the ticket is in the on-hold status, we're assuming the agent isn't actively doing work because they're waiting on a third party.
Requester wait time only pauses on Pending. In other words, it's a much more accurate picture of what the customer is experiencing, since most likely they don't care if the ticket is with you or a third party... they're simply waiting.
Thanks Erin! Nice to see that - sounds as expected.
@Erin and Andrew,
I can settle @ agree to disagree.
We can't let 3rd party software or services count toward our SLA against our customers,
continuously report yes but not full resolution time, which I am sure you've gathered by now :)
I don't see us being unique in that matter either But, yes, we can work around it.
Thank you for the input.
@olaf - I'll just add one more comment - I do think the new SLA system is lacking in flexibility. Sometimes you just want to measure a specific thing and the option isn't there. Plus getting reports from these is laborious at best.
Hi all,
Just wanted to let you know about a change that went out yesterday for the periodic update metric. We heard from a lot of you that essentially fulfilling this metric automatically during the pending status was highly undesirable, as you wanted to keep your customers updated periodically, regardless of whether you were waiting on additional information from the customer.
Now, the periodic update metric will not fulfill when the status is changed to pending.
Recap on the newly expected behavior: When an agent makes an initial public comment, an instance of periodic update will begin. When an agent makes a subsequent public comment, that instance will be fulfilled, and a new instance of periodic update will begin with a new clock. This will repeat, regardless of status, until the ticket is put into a Solved status.
Let me know if you have any questions!
Best,
Erin
This is extremely unfortunate Erin, and yet again reduces how I can use Zendesk. In the past, Zendesk would recommend to use automations on pending tickets, instead of forcing agents to do manual up dates. This change has forced me to disable periodic slas for my agents and costumers. This is becoming a deal breaker for me, and I'd like to know if there are any options for my organization to revert to the old functionality. I noticed the change yesterday, when my slas began breaching, hurting my reporting numbers. Changing functionality without notice in the middle of the day is an extremely poor practice.
Please let me know if I have any other options besides evaluating new providers
Also - the new logic doesn't make sense by your own account here:
Erin Boyle May 09, 2016 19:05Agent work time pauses on both Pending and On-hold. If the ticket is in the on-hold status, we're assuming the agent isn't actively doing work because they're waiting on a third party.
Erin, are there any chances of reconsidering the periodic update metric behavior update?
As you may understand, changing this without any previous notice has broken consistent workflows for some of us.
Please count us in if there's an option to go back to the previous metric behavior or to opt in for a replacement.
Also, we would appreciate if you, or anyone in the thread, could share a workaround to fulfill the SLA of a ticket when this is submitted as Pending but keeping it active when the ticket is submitted as Open.
This can be applied, for example, when you want to start counting towards SLA only after a reply from the ticket requester and also when you want to keep the SLA active after escalating a ticket to another support tier after letting the requester know that using a public comment.
Thanks in advance for your suggestions!
Erin, +1 on issues with the new functionality for periodic update.
The SLA for next response effectively disappears from the "open" tickets, if our agents made a public reply to say they are looking into something or working on an item.
If we had the old functionality for periodic update or some kind of clever workaround with tags?
Any suggestion would do.
Hi
After having a long conversation with your Tier 2 Agent I realized that there are two behaviors related to business hours which make no sense to me.
The first thing is that if somebody works on a ticket out of business hours, the counters keep working. I am not sure if this is actually happening, but shouldn't all the SLAs be stopped when it comes to "out of business hours"? That is the idea of an SLA, an agreement with the customer within your time frame, which is why we have calendar and business hours.
This is specially wrong, in my opinion, in the case of the Periodic Update. The rule, as explained by your colleague, is that no matter the status of a ticket, no matter if it is set to business or calendar hours, this metric will always continue.
This leads me to two questions:
-What is the use of a metric in business hours if it continues beyond business hours when I have no service available. How can I update an user out of working time?
- Why the metric keeps on running when the ticket is Pending? I have an agreement (SLA) with my customer about keeping him updated when the ticket is on my side. What sense does it make to update a ticket pending from the customer? If the issue is related to press or remind the customer to his part, this is not part of the agreement, and even less on my side. Why should I lose an SLA because a customer takes a long time to answer the issue that HE is having?.
This is also applied to other metrics which continue running after business hours. You may refer to my ticket for further information. I could publish it here if you want since it does not contain internal information.
Regards
Erin and Zendesk team - our main problem is now once an agent has replied publicly but still needs time to work on a response. Since I had to disable periodic update (because it effectively cancels my ability to automatically follow up on a ticket) , there is now no way to track this ticket in terms of SLA and it is driven to the bottom of the view (which is set to look at next SLA breach).
Any ideas how to get out of this situation?
Erin - is there a workaround to bypass the new logic for the Periodic Update Metric when tickets are Set to Pending?
We use the Periodic Update metric to let Agents to prioritize tickets they are responsible for - Open Tickets
However if a ticket is set to Pending the responsibility is on the Requester and should not be subject to the SLA.
Could we use a Trigger to move Pending tickets into a different SLA Policy which does not use a Periodic update (maybe adding a trigger when set to Pending)?
Then another Trigger to move the Ticket back into the Original SLA?
Jeff and others,
Thank you for letting us know about your use cases around the Periodic Update metric.
I have some good news.
We're in the process of adding a new SLA metric that will not run when the ticket is in the Pending state.
We'll be sure to let you know once it's available for use. Stay tuned!
Please sign in to leave a comment.