Defining and using SLA policies – Blink Digital

Suite Growth, Professional, Enterprise, and Enterprise Plus professional and enterprise plans

Quick Look: Admin Center > Objects and rules > Business rules > Service level agreements

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.

SLA policies have a set structure. Each SLA policy has:

A set ofconditionsthat a ticket must satisfy in order for the SLA policy to be applied
Thetargettime for each desired metric and priority value
One or moremetricsthat you choose to measure
Whether targets will be measured inbusinessorcalendar hoursby priority value

Related articles

Fine tuning:Learn how you can make the most out of your SLAs withSam Chandler's Fine tuning: Succeeding with SLAs – why, when, and how!

Tip:Read this Zendesk blog postto learn how and why you should create service-level agreements.

This article contains the following sections:

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, seeOrdering SLA policies. To review which policies have been applied to a ticket and in what order, seeViewing 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 after a ticket update that affects the SLA, such as a priority or schedule change.

When you merge an older ticket with an SLA into a new ticket, the older ticket’s SLA state is frozen, whether achieved or missed. The newer ticket proceeds with its own SLA. The merge action appears as an internal update on the newer ticket, which doesn’t meet or change any SLAs.

Tickets set to Solved immediately fulfill all active SLA targets.

If you apply or change an SLA target that is already breached, the breach will be recorded at the time of the update. SLAs do not back-date breach events.

Understanding what SLA metrics you can measure

You can define SLA service targets for six different metrics: first reply time, next reply time, periodic update time, pausable update, requester wait time, and agent work time. The first four metrics measure reply time, while the second two measure resolution time.

Important:Do not confuse SLA reply time with the native Zendesk reply time metric. For more information, seeZendesk SLAs and first reply time.

Reply time metrics

Note:Reply time SLA policies aren’t supported for chat or messaging tickets.

The following metrics measure reply time:

First reply timeis the time between ticket creation and the first public comment from an agent, displayed in minutes. Some qualifications include:

First comment author	First comment visibility	SLA first reply time behavior
End user	Public	The SLA first reply time target starts at their comment and runs until the next public agent comment. This is the most common workflow and typical behavior.
End user	Private	The SLA first reply time target does not start until the first public comment by an end user after the ticket is made public. This means the first reply can start after a public agent comment. Once it starts, the first reply time target runs from the public end-user comment to the next public agent comment after the end user.
Agent or admin	Public	The SLA first reply time target is immediately satisfied. It does not activate or record an achievement.
Agent or admin	Private	The SLA first reply time target does not start until the first public comment by an end user after the ticket is made public. This means the first reply can start after a public agent comment. It still runs until the next public agent comment after the end user.
Light agent	Private	The SLA first reply time target starts at their comment and runs through the next public agent comment.

Note:SLA first reply time targets for side conversation tickets have additional considerations. For details, seeDefining OLA policies using internal SLAs and child ticket side conversations.

Next reply timeis the time between the oldest unanswered customer comment and the next public comment from an agent, displayed in minutes.
Periodic update timeis 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 updateis 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.

TheFirst reply timeandNext reply timemetrics typically use an end-user comment as starting point, and a public agent response as an end point. The following graphic shows how these metrics fit in with the lifecycle of a ticket.

ThePeriodic update timeuses 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.

ThePausable updatemetric 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. If an agent adds a public comment and marks the ticket as Pending in the same event, the metric will not be applied to the ticket until the ticket is first submitted in a New, Open, or On-hold status with a public comment. The metric will apply once the ticket is set to Pending. 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.

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 timeis the combined total time spent in the New, Open, and On-hold statuses. The SLA will pause on Pending.
Agent work timeis the combined total time spent in the New and Open statuses. The SLA will pause on Pending and On-hold.

Note that while you can choose multiple resolution time metrics, it is considered 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.

Reopening tickets effect on an SLA

If a ticket is reopened, the following metrics are impacted. The reply time and update targets activate new targets, and the work time and wait time targets reactivate.

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.

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, seeCreating triggers for automatic ticket updates and notifications.

Conditionsfor SLA policies are similar to the conditions you use to set up triggers. Like conditions for triggers, they have bothAllandAnyconditions, 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. For more information about using custom ticket fields, seeUsing custom ticket fields in business rules and views.

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

Note:The minimum target time you can set is one minute.

To set up an SLA policy

InAdmin Center, clickObjects and rulesin the sidebar, then selectBusiness rules > Service level agreements.
ClickAdd policy.
Enter a name in thePolicy Namefield.
Optionally, enter a description in theDescriptionfield.
In theConditionssection, select the conditions for this policy. Start typing the condition to autocomplete or select an option from the drop-down menu.
In theTargetssection, 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 forHours of operation.
ClickSave.
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.

To edit an existing SLA policy

InAdmin Center, clickObjects and rulesin the sidebar, then selectBusiness rules > Service level agreements.
Click on the SLA policy you want to edit.
Edit the policy as necessary and clickSave.

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, seeUnderstanding how SLA policies are applied to tickets. To review which policies have been applied to a ticket and in what order, seeViewing 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

InAdmin Center, clickObjects and rulesin the sidebar, then selectBusiness 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 theNext SLA breachcolumn. TheNext SLA breachcolumn displays the calendar time left before the next target on any given ticket will be breached.

For details about the different SLA statuses, seeUnderstanding SLA target statuses. For details about understanding how target status appears in this column, seeSeeing 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 theViewsicon () in the sidebar, then select a view.
Click the View options menu in the upper right.
ClickEdit.
Scroll down to theFormatting optionssection.
UnderColumns not included in table, clickNext SLA breach.
DragNext SLA breachinto theColumns included in tablecolumn.
To make sure the tickets whose targets are most breached or are closest to breaching will get attention first, selectOrder by>Next SLA breachinAscendingorder.
ClickSubmit.

Using SLA breaches in automations

You can set up automations based on SLA breach status using two conditions,Hours since last SLA breachandHours until next SLA breach. For information about creating automations, seeStreamlining workflows with time-based events and automations.

Note:If you have set up multiple schedules, the conditionsHours since last SLA breachandHours until next SLA breachare based on the schedule that is applied to the ticket (seeApplying 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 (seeMetrics and attributes for Zendesk SupportandExplore recipe: Reviewing SLA performance), or use the pre-built reporting dashboard (seeAnalyzing your Support activity).

It is important to note that the pre-built reports are based on a perinstancebasis 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.

Deleting SLA policies

You can delete an SLA policy if it is no longer needed.

To delete an SLA policy

InAdmin Center, clickObjects and rulesin the sidebar, then selectBusiness rules > Service level agreements.
Locate the SLA policy you want to delete.
Click the options menu () beside the SLA policy title.
SelectDelete, then confirm the selection.