Defining and using SLA policies (Professional and Enterprise) Follow

professional enterprise plans

A Service Level Agreement, or SLA, is an agreed upon measure of the average 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.

SLA policies have a set structure. Each SLA policy has:
  • 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. For example, 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.

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.
  • 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.
  • 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.
Note: Pausable update is a new feature, rolling out to all customers over a number of days, so it may not be available in your account just yet. We appreciate your patience, and aim to finish this rollout by January 20th.

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; or starts when a pending ticket is changed to a non-pending status with either no comment or a private comment from an agent.
Note: 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.

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.

Note: 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. If this is not set, you can use a trigger to set this to a default value, such as Normal, when the ticket is created. For details, see Streamlining workflow with ticket updates and triggers.

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

  1. Click the Admin icon () in the sidebar, then select Business Rules > Service Level Agreements.
  2. Click Add policy.
  3. Enter a name in the Policy Name field.
  4. Optionally, enter a description in the Description field.
  5. 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.

  6. 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.

  7. For each priority, select either Calendar hours or Business hours for Hours of operation.
  8. 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.
To edit an existing SLA policy
  1. Click the Admin icon () in the sidebar, then select Business Rules > Service Level Agreements.
  2. Click on the SLA policy you want to edit.
  3. 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

  1. Click the Admin icon () in the sidebar, then selecting Business Rules > Service Level Agreements.
  2. Hover your mouse over the left of the SLA policy name you want to reorder until the grabber is highlighted.


  3. 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

  1. Click the Views icon () in the sidebar, then select a view.
  2. Click the View options menu in the upper right.

  3. Click Edit.
  4. Scroll down to the Formatting options section.
  5. Under Columns not included in table, click Next SLA breach.
  6. Drag Next SLA breach into the Columns included in table column.
  7. 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.


  8. 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.

Note: If you are on Enterprise and have multiple schedules, the conditions Hours since last SLA breach and Hours until next SLA breach are based on the schedule that is applied to the ticket (see Applying your schedules to tickets).

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?

Let's say you have five tickets:
  • 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.

Have more questions? Submit a request


  • 0

    Can we create a report that shows us the %age of time we met the SLA. For example. I have a SLA which says all sev1 needs to be replied within 1 hr.
    To find how are we doing with our response time on sev1 tickets can we create a report that would show that we are meeting the SLA X% of the times ?

  • 0

    Erin sorry I did not see your response above about the SLA dashboard. Is it something I can see on my account ? The screenshot looks very promising. I would be interested to test it.

  • 0

    Hi Ravi,

    It's not yet available as we're still working on it (that screenshot is just a mockup). That being said, you should hear from me in the new few weeks with an update. :)


  • 0

    I notice that the Schedules are not available for selection when creating an SLA. Is this planned for the future?

    We have different ticket "Business Hours" (hence Schedules) for different SLAs, and therefore need to tie the response times into the Schedules, rather than the standard Business Hours or Calendar Hours. Hence the requirement to use the Schedules in the SLA.

  • 0

    Hi Matt,

    If your SLAs are set to use business hours, they will use the schedule that is set on the ticket. Make sure you have triggers in place to set schedules on tickets, and the SLAs will work from there.


  • 0

    Ahh, got it. Thanks. I'll give it a try.

  • 0

    Finally started playing with this today, but struggling with the First Reply Time option. A large number of our tickets are logged on behalf of a customer (sometimes by agents located elsewhere), and we still need first reply to these within 2 hours. What I don't understand is why the SLA timers work differently to the First Reply Time metric ( - the metric works perfectly for us in treating the initial description as separate to a reply.

  • 0

    +1 for Ola's comment.

    We want to start sorting Open tickets based on the SLA policies, but we are afraid that the rule will leave out all the tickets where the agent has created it on behalf of the requester. Our policy is that all tickets must be replied in 24hs, and for all the other cases we are using the "Next reply time" metric.

    From what I understand, using the Resolution time metrics (either Requester wait time, nor Agent work time) won't be useful in the case of agent generated cases, as that metric is the sum of all the time a ticket sits in the Open and New state, and it would hurt all the other tickets, for example, where the "Next reply time" was just 1 hour short of being breached. In this example, the next time it opens again the agent would only have 1 hour to avoid missing the Resolution time metrics. How could we avoid this?

    As Ola is saying, the First Reply Time should be able to tell apart the cases where the description was submitted by the agent on behalf of the requester, and still count that SLA.

  • 0

    Hi Ola & Sol,

    We made the conscious decision to have the first reply time metric not include a first comment/description as made by an agent. For the majority of our customers, this is actually the desired behavior. However, I do understand it's not desired in your particular use cases. Unfortunately I don't have a workaround for you at this time, but will keep this in mind going forward.


  • 0

    Hi Erin! Thank you for your reply!
    I thought of a workaround that (I hope!) will accomplish what we need. Could you please review it and let me know if it makes sense? The basic idea is that we need to create a rule that excludes the tickets where the requester created the ticket, so that the SLA policy for agent-generated-tickets doesn't affect their metrics.

    Whenever a ticket is created by an agent in the Open state, a tag will be applied by a trigger, something like "agent_counter". We will then set up an SLA policy stating that all tickets created not by email and that have that "agent_counter" tag will have an SLA of 24hs for Agent work time. We will then set up another trigger so that if the ticket changes its status to Pending, it will delete the tag "agent_counter". This way, if the requester replies and opens the ticket again, the global SLA policy will be applied (24hs until next reply).

    Right? What do you think? I believe this could be a solution.
    Thanks in advance,

  • 0

    Thanks, Sol. Your idea has helped me think about it. In our case the trigger would have to remove the tag on public comment, as sometimes the comment is escalating.

    Erin, I can see why the decision was made for the SLAs, but it does seem weird having it inconsistent with the metric definition (which never counts the initial description as a reply). I think maybe it's because our setup has agents in different teams, but one team always has to reply within 2 hours regardless of source.

    Edited by Ola Timpson
  • 0

    Something I'd like to check - if a ticket is created by a Light Agent forwarding a customer email, will that affect the "first reply time" SLA? Ideally, stuff forwarded by Light Agents wouldn't count as having been responded to until a "real" agent replies.

  • 0

    @Sol - if you're main goal is simply for agents to be able to view the clock, I think this will work. If you want to be able to report on these things once we introduce Insights for SLAs, this approach will not work, unfortunately.

    @Ola - we actually have plans to go back through all ticket metrics and update them. This will include changing the first reply time to be consistent with SLAs.

    @Terry - If the Light Agent forwards the customer email and agent forwarding is turned on, the first comment will actually come from the original customer who emailed the Light Agent. So you're right—the first reply time counter will start and wait for an agent reply.

  • 0

    Thanks Erin - we do indeed have agent forwarding on.

  • 0

    Thanks Erin, if the metrics change to match then it gives me an excuse to update our processes to fit!

  • 0

    Hi I have a question of ow I can set up my SLAs.

    I have reply to customer in 2 hrs and fix in 4 so how would i set this up with the new SLA's as in which fields would you enter this data


    Edited by Mike Burns
  • 0

    Hi all,

    We've started rolling out SLA metrics (and a dashboard) to Insights - you should be reporting by the end of today! See my announcement for more information:

    Thanks for your patience on this one.


  • 0

    Really disappointed to see I can't define SLA policies based on an "empty value" for Organization - especially given you can do so for Triggers, Automations, Views and Insights metrics. :(

    Does this affect anyone else? I've made a feature request to reflect this:

  • 0

    I would like to create an sla for time between updates in the open status, is that possible? ie: I want my agents to update tickets every 6 hours if they are in open status, not dependent on who the last comment came from.

    So, we might respond to the customer and leave the ticket open stating " we are working on this issue and will update you shortly", and leave the status as open, resetting the timer to 6 hours. in 4 hours we provide an update of "we are almost done here and will update you once your problems is solved. The sla would again, reset to 6 hours.

    Is this possible?

  • 0

    Hi Brian,

    This isn't possible... yet. That being said, we're actually finishing up a brand new metric right now that we'll call "Periodic Update," and it will do exactly what you're looking for. I'll be sure to update you all once it's finished, tested, and rolled out!


  • 0

    Amazing. Do you have a rough eta you can give?

  • 0

    Not just yet, unfortunately. We still have a few last pieces to build out, so probably on the order of months. I'd love to get this out before the end of the year, and I think it's reasonable, but that is very much subject to change.

  • 0

    Hi Erin,

    I would like to send agents periodic SMS notifications if a ticket is within 3 hours of breaching SLA.

    Is it possible to use the REST API to retrieve information on Next SLA breach for a ticket? I understand this information is not available at the ticket level, but it is available in the view - is it exposed via the API?

    Failing that, is it possible to manually calculate 'Next SLA breach'?



  • 0

    Similar to Gary, we also want to be able to use triggers/automations to notify agents that we are nearing a breach of SLA respond within 1 hour on Urgent. We would at a minimum want to have agents notified at the 30 min mark. Without this we have no proactive action that helps us meet our SLA of responding in less than 1 hour. Is there a work around for this?

  • 0

    Hi all,

    No, there is no current workaround for this built into the product. We are, however, exploring options for more timely SLA notifications in the future. To Baber's point, though, there are a few API options you may want to know about.

    We have an incremental endpoint for SLA breach and fulfill events:

    We also have 2 different ticket side-loads available:

    • The slas sideload displays the next SLA breach for that ticket, along with what metric it corresponds to
    • The metric_events sideload is the same information available in the incremental endpoint, but for that single ticket

    Hope this helps!


  • 0


    Can I get SLA data at a ticket level through the API?
    Such as: time to next breach (inc. which policy), breaches that already occured, etc.


  • 0

    Hi Yoav,

    The incremental endpoint and the sideloads I mentioned in my last comment are your best bet to get that information. The slas sideload gives you the time to next breach for all metrics on that ticket, and the metric_events sideload will show you the history of ALL metrics on that ticket, including breaches.


  • 0

    Thanks Erin!

    I'd require both upcoming breaches and historical so the metric_events sideload sounds like something that could work.
    What's the difference between the sideload and the regular ticket_metric_events?


  • 0

    @Yoav - the sideload will restrict the events to that specific ticket, whereas the regular ticket_metric_events is an incremental endpoint that shows all events across all tickets.

  • 0

    Hi all,

    Just wanted to let you know we've just added a new metric called "Periodic Update." This allows you to set a time limit on how often you need to respond to a customer. For example, you may choose to update customers on high priority tickets every 4 hours, or even every 30 minutes. The metric begins after a first public reply, and the timer will reset itself after every public response to a ticket.

    Happy Thursday!

Please sign in to leave a comment.

Powered by Zendesk