A service level agreement, or SLA, is a policy you define that specifies and measures the response and resolution times that your support team delivers to your customers.
On Enterprise plans, you can also define group SLAs. Group SLAs are separate policies between your internal teams that define a target ownership time for a group.
This article describes the building blocks that make up SLAs, how your support team and customers can benefit from them, and explains when they apply to tickets.
About SLAs
You can define SLA policies that specify the response and resolution times that your support team aims to deliver to your customers based on ticket priority. For example, you could set targets for and measure:
- How long it takes an agent to initially respond to an urgent support request
- The amount of time a customer waited for their issue to be fully resolved
- How much time an agent should spend on a ticket
SLAs are automatically applied to tickets when the specified conditions are met and begin to measure the defined response and resolution times. To learn more, see Understanding how SLAs policies are applied to tickets.
When a ticket fails to meet SLA targets, Zendesk highlights this so that you can promptly identify and address problems. For example, not meeting SLA targets consistently during certain times of the day may mean you need more agents available then.
SLA information is visible in tickets and views. You can also create business rules that take action based on SLAs (for example, to get attention on a ticket before the SLA is breached). See Viewing and understanding SLA targets and Using SLA policies to learn more.
Why to use SLAs
Providing support based on service levels ensures that you're delivering measured and predictable service. It also provides greater visibility when problems arise.
Some of the benefits of SLAs include:
- Setting clear objectives for your support team. SLA policy information is visible in tickets and views, which can help your agents know which tickets to prioritize.
- Providing a consistent experience for customers. When your agents regularly meet your SLA targets, customers can expect their issues to be resolved in a timely manner.
- Identifying problems quickly and solving them efficiently. You’ll be able to see when you’re not meeting your SLA targets and take action.
Read this Zendesk blog post to learn more about how and why you should create SLAs.
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!
About group SLAs (Enterprise only)
On Enterprise plans, you can also define group SLAs. Group SLAs are separate policies between your internal teams and define a target ownership time for a group. They are also commonly known as Operational Level Agreements (OLAs) and are used in workflows that involve multiple teams solving tickets.
Group SLAs are automatically applied to tickets when a specified group is assigned a ticket. The defined ownership time begins to be measured when the group is assigned a ticket and ends when the ticket is reassigned.
For example, you can set a target for your sales team that normal priority tickets assigned to their group are addressed within eight hours.
Like SLAs, you can also set additional conditions in your group SLA policies. For example, say your finance group handles two types of tickets — refunds and expenses. You may want to have shorter SLA targets for refunds and longer targets for expenses. You could set a condition based on these types of tickets’ forms in the group SLA policy so that the right policy is applied to the right tickets.
Additionally, group SLA information is visible in tickets and views (see Viewing and understanding SLA targets).
The image below illustrates how SLAs measure the response and resolution time between your company and customers, while group SLAs measure the ownership time between your internal teams.
Why to use group SLAs
Group SLAs help create accountability between your internal teams by defining and measuring how long tickets are assigned to a specific group.
Benefits of group SLAs include:
- Improving internal processes. You can track how your internal teams uphold and achieve the overall SLA of a ticket.
- Setting targets for resolution by team. You can create a group SLA for each of your teams and see which teams are meeting their objectives.
- Identifying gaps and problems. Group SLAs can help you get insight into performance and training opportunities for every team that is assigned a ticket.
Differences between SLAs and group SLAs
- While only one SLA can apply to a ticket at a time, SLAs and group SLAs are separate policies. This means that an SLA and group SLA policy can apply to the same ticket at the same time.
- You can define SLA service targets for six different measurements: first reply time, next reply time, periodic update time, request wait time, agent work time, and total resolution time. There is only one measurement for a group SLA service target: group ownership time.
- Group SLAs are available only on Enterprise plans.
Structure of SLA policies
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. See Understanding which SLA metrics you can measure.
- Whether targets will be measured in business or calendar hours by priority value
(Enterprise only) Group SLA policies also have a set structure. Each group SLA policy has:
- A set of conditions that a ticket must satisfy in order for the group SLA policy
to be applied, including the group or groups assigned to the policy.
If you don’t specify a group, then group ownership time is measured on all tickets whenever a ticket is assigned to any group.
- The target time and priority value
- The metric you measure, Group ownership time
- Whether the targets will be measured in business hours or calendar hours by priority value
About SLA 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. If you've activated custom ticket statuses, then you can create a SLA policy with a condition based on a ticket status.
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.
Understanding how SLA policies are applied to tickets
When a ticket is created or updated, it runs through all the triggers set up in your Zendesk instance. After the triggers have been applied, that ticket goes through the SLA system.
Starting at the top of your list of policies and moving down, the conditions on that policy are compared to the ticket. The first policy whose conditions are satisfied by the ticket is applied to the ticket. The same process occurs for your list of group SLAs.
SLAs and group SLAs are separate policies. Both an SLA policy and group SLA policy can be applied to a ticket at the same time.
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 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.
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.