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
- 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, 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 five different measurements: first reply time, next reply time, periodic update time, request wait time, and agent work 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
- 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
- A group or groups assigned to the policy
- 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
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.
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.
0 Comments
Please sign in to leave a comment.