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, seeUnderstanding 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). SeeViewing and understanding SLA targetsandUsing SLA policiesto learn more.
Why to use SLAs
基于服务水平确保提供支持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 postto learn more about how and why you should create SLAs.
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!
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 (seeViewing 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
- 虽然只有一个SLA可以适用于蜱虫et 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 ofconditionsthat a ticket must satisfy in order for the SLA policy to be applied
- Thetargettime for each desired metric and priority value
- 一个或多个metricsthat you choose to measure. SeeUnderstanding which SLA metrics you can measure.
- Whether targets will be measured inbusinessorcalendar hoursby priority value
- Agrouporgroupsassigned to the policy
- Thetargettime 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
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. If you'veactivated custom ticket statuses, then you can create a SLA policy with a condition based on a ticket status.
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.
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, 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 associated with the ticket.
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.
8 Comments
多个SLA策略可以应用在同一time? I created a 'next reply time' policy to apply to all tickets for all brands and I have other SLA policies that dictate 'Agent Work Time' based on the team assigned. I dragged the Next Reply Time to the top of the list to ensure that it applied first; however, now my other SLA policies that dictate 'Agent Work Time' are not applying correctly. The ticket activity only shows the 'Next Reply Time' SLA policy being applied.
Am I misunderstanding the following?
It seems like the other policies should apply unless the customer has replied to the ticket.
Thanks in advance!
In our Org we generally move the cases back and forth between teams. The group SLA seems to be resetting when the case is moved to the group again.
Group 1 = Group SLA starts (Eg: 15 mins).
Case moved to Group 2 after 10 mins.
Case moved again to Group 1 = The Group SLA runs again from 15 mins (And not from where it was left; 5 mins).
HiKaran Singh!
A group SLA starts when a group is assigned a ticket and ends when the ticket is reassigned or solved. Please seeDefining group SLAsfor more information.
Edit:To clarify a bit more, the group SLA always resets if a ticket gets assigned back to a group it was previously assigned to. Group SLA policies aren't cumulative.
Colleen Hall- any comment on my inquiry?
Since it was 10 days ago that I posted the question with no answer, I've decided to move away from that format, and now I have individual SLA policies that all have standard next-reply time values.
Does the quoted text mean *only* "The first policy whose conditions are satisfied by the ticket is applied to the ticket?" Thereby, subsequent policies whose conditions are satisfied are ignored?
HiStephen Lee,
I apologize for the delay in my response!
Yes, the quoted text means that the first SLA policy whose conditions are satisfied is applied to the ticket and subsequent policies are ignored. Only one SLA policy can apply to a ticket at a time. You can create a single SLA policy with all the metrics (such as "Next reply time" and "Agent work time") that you want to measure. Please see theOrdering SLA policiesandUnderstanding which metrics you can measurearticles for more information. I hope that helps!
Good day,
Would like to ask if SLA count is being reset if we assign ticket to another group? Regardless if SLA policy is changed or not?
Example scenario:
Ticket created yesterday at 12noon and was assigned to me using SLA policy no 2 (90 mins SLA)
Upon checking, ticket needs to be endorsed to another group. I assigned to group A today with SLA policy 3 (3 days SLA)
Is the ticket SLA will be reset to zero upon assigning to group A or continuous count of SLA, meaning my assistance time from yesterday until today will be counted already on Group A's 3- day SLA?
Thank you in advance
It looks like the SLA counter is not reset, regardless if the SLA policy is changed or not. If another SLA policy applies to the ticket after changing the group, the counter looks after the whole ticket cycle. Applied to your example, the time of your assistance until you changed the group is counted as well. I hope this helps!
This is well noted and thank you Cristian
Pleasesign into leave a comment.