Getting started with Service Level Agreements can be tricky. To get a walkthrough of how-to setup your SLA targets and other best practices check out:

Webinar recording - Leveraging Service Level Agreements to drive team performance

Don't have time to watch the recording? Check out the summary of the presentation in this community post. 

Value of Service Level Agreements

• SLAs help you provide a consistent experience to your customers. You’ll be able to keep your agents on their toes with various workflows to remind them to get back to your customers in a timely manner.

• SLAs help you identify problems quickly and solve them efficiently. You’ll be able to easily see when you are not meeting your SLAs and take actions accordingly. Maybe you need more agents during a specific time of the day. Or perhaps you are doing so well with meeting your SLAs you want to share those with your customers about the high level of support they are receiving.

• Leverage SLAs to segment your customers so that they receive a tailored experience. Give your VIP customers the white glove treatment by having your agents stay on top of their tickets.

Also, did you know that implementing SLAs has shown to make response times much faster. 

Overcoming the fear of SLAs

Many customers are afraid of SLAs because they believe that they will be strictly held to those standards. What happens if we don’t meet the SLAs? Will we start losing customers? Can we be sued?

This is where we start to get ahead of ourselves.

In a typical Service Level Agreement, two parties meet and sign a contract that specifies what each company is being held to and what the consequences, if any, would be of not honoring the SLA. That definitely sounds very scary. 

What I want to clarify right from the beginning is that the SLAs in Zendesk are not a binding contract with your customers. Sure, you could create a contract separately and then setup your SLAs to meet that contract - however the SLAs on their own are really just for you and your team.

The SLAs in Zendesk are completely internal, until you decide to share them publicly. That means that you could never share your SLA information publicly, but still have your internal team reap the rewards.

Service Level Agreements will help you streamline your support and help in making your agents efficient. You'll be able to build workflows with automations to notify your agents or managers about tickets that have an SLA that is about to breach, or one that has already breached. Your customers will feel heard as they receive a consistent support experience which will lead to higher CSAT as you scale. 

Service Level Agreements in Zendesk

Navigating to SLAs

1. In Admin Center, click Objects and rules > Business rules > Service level agreements.
2. On the Service Level Agreements page, click Add policy.

Parts of an SLA

Policy name - enter a name for the policy

Description - enter an optional description for the policy

Conditions - add conditions to determine when the SLA policy should apply.

• The setup for conditions is similar to that of triggers and automations. Add conditions for ticket properties such as Group, Assignee, Ticket Form, Tags, and more.

• It is important to pay attention to the conditions within the SLA. The more stringent the conditions in the SLA, the higher it should be in the list of SLAs. This is because SLAs are checked from the top down on tickets and once an SLA policy is applied, the rest of the SLA policies are not checked. So, you want to make sure that your more general SLA policy is at the bottom of the list.

• The most general SLA policy you can create is one with no conditions in it, which will apply to all tickets in your account.

Targets - for each metric, set a time target for each ticket priority

•  Ticket priorities - for any SLA policy to be applied to a ticket you need to make sure you set the system ticket priority field.

• Hours of operation - decide whether you want your SLA policy to only apply during business hours or if it should apply to calendar hours

• Metrics - the various measures for the SLA policy. Another way to think about it is to enter the max time you expect your agents to take for the particular metric.

Breaking down the metrics

Reply time metrics help you understand how your team is performing in regards to responding to your customers and keeping them informed while the agent resolves their issue. These include the following:

• First reply time
• Next reply time
• Periodic update
• Pausable update

Resolution time metrics use the status of a ticket to determine the amount of time that was spent on the ticket. These include the following:

• Requester wait time
• Agent work time

Let's break these down further to broaden our understanding of when to use the various metrics.

First reply time

The time between ticket creation and the first public comment from an agent, displayed in minutes.

• You want to use this metric to specify how much time it should take your agents to get back to your customer

• First reply time is important because it can vary based on the channel you are supporting. Typically, customers expect a response between 8-24 hours for email. For social media however, they expect the response to be within 20 minutes before they are disengaged. 

In the above example the first reply time would be the combination of segments A + B. This is because the first reply time clock starts the moment the customer submits the ticket and stops once an agent makes a public reply to the customer.

Let's look at another example of first reply time.

For this ticket an agent creates the ticket with an internal note. The first reply time is a combination of the segments C + D + E.

This is because the first reply time clock starts from the moment the customer comments in the ticket and stops when the agent makes a public reply. This one is a bit of a trick question because it's for the case where the agent creates the ticket instead of the customer submitting the ticket.

Another thing to keep in mind is that first reply time is not calculated on tickets if the agent creates the ticket with a public comment. 

Next reply time

Next reply time is the time between the oldest unanswered customer comment and the next public comment from an agent.

• So, this metric sets the amount of time you want it to take for you agents to get back to your customers. Think of it as a continuation of first reply time for every customer update on the ticket.

• When using this metric, you are thinking along the lines of how long should customers have to wait to hear back from my agent.

• This will help you keep your support experience consistent as well because your customers will get responses in a timely fashion.

In the above example the next reply time would be the segment E. Keep in mind that the next reply time clock starts at the oldest customer comment and stops at a public agent comment. 

Let's look at another example of next reply time.

The next reply time here is a combination of the segments C + D + E. Again, just reiterating that next reply time starts at oldest unanswered customer comment and continues until a public agent reply is on the ticket.

Periodic update 

Periodic update measures the time between each public comment from agents.

• Think of this as how often you want your customers to be provided updates from your team.

• The most common scenario is using periodic update with VIP clients who require that you provide them updates every 30 60 or 90 minutes. If you want to send customers an update every x minutes, then you want to set up periodic update.

In the above example the periodic update would be the combination of segments C + D + E. Periodic update is pretty simple, it’s just the time between each public agent reply.

Pausable update

Pausable update is the time between each public comment from agents when the ticket is in a new, open or on-hold status. The pausable update will pause when the ticket is in a pending status.

• Think of pausable update as the time you expect agents to spend on a ticket. It’s considering all the time that the agent would be spending working on the ticket and takes out the time where the agent would be waiting to hear back from the customer.
• Another way of thinking about this is pausable update is the amount of time the customer has had to wait to get their issue resolved.

Pausable update adds another layer here where the ticket status is important. 

In the above example the pausable update is the combination of the segments B + D + E. The pausable update will pause when the ticket is in a pending status and continue to count while it is in a new, open, and on-hold status. 

Another key point to keep in mind here is that pausable update uses a public agent reply as its starting point. 

Let's look at another example for pausable update.

The pausable update here is still the combination of segments B + D + E. The key point here is that the pausable update will pause when the ticket is set to pending, regardless of the agent making a comment on the ticket. 

Requester wait time

The metric requester wait time measures the total time a ticket spends in new, open and on-hold status.

• Think of this as the time a customer should wait for their issue to be fully resolved.

• When you are setting the requester wait time you want to think of the amount of time it should take the team to fully resolve the issue.

In the above example the requester wait time is the combination of segments A + B + D + E. This metric is pretty simple as it starts when the ticket is created and stops once the ticket is solved, only pausing when the ticket is in the pending status.  

Agent work time

Agent work time is the total time spent in the New and Open status.

• Here you are thinking about how much time an agent should spend on the ticket.
• The key point to keep in mind is that agent work time does not consider the on-hold status. This is because tickets that are in an on-hold status are being worked on by a third-party vendor.

In the above example the agent work time is the combination of segments A + B + E. Again, this is very similar to requester wait time except that it does not consider the on-hold status.

Using the metrics together in an SLA policy

In the above example you can see how the metrics work together. 

First reply time is pretty simple and I recommend that you all start by creating your first SLA for first reply time. This is a great starting point if you are unsure which metrics you want to hold your team to.

For the rest of the metrics you can see there is quite a bit of overlap. What I’m trying to get across here is that it doesn’t make sense for you to apply all the targets in an SLA policy.

• When it comes to Requester Wait Time and Agent work Time - you really should just pick one.

• Next reply time and periodic time can be active on a ticket at the same. In that instance the target that is the closest to being breached will be displayed for agents.

Once you have your conditions setup, choose the relevant metrics that you want to measure keeping in mind what we just went over.

Tips for setting up your SLAs 

Now let’s go over some tips when working with SLAs.

Ticket priority - earlier we had talked about the importance of setting the ticket priority on a ticket. You can automate this process by applying a low priority to all tickets via a trigger when the ticket is created. From there you can apply other triggers to increase the priority or your agents can update the priority of the ticket as they work on the ticket.

 SLAs in views - to make SLAs easily visible to your agents, you will want to add the column Next SLA breach to your views. This lets the agent know how much time they have left to meet the service level agreement. The timer will display in green while there is time left to meet the SLA. Once the SLA has been breached, the time will turn red.

• Seeing SLA statuses in views

Automations and SLAs - create an automation that notifies the assignee on the ticket or a group of managers when SLAs breach. Furthermore, leverage an automation to remind your agents an hour or more before an SLA breaches. Use the following conditions in your automation:

• Hours since last SLA breach
• Hours until next SLA breach

Currently you cannot create triggers based on SLA breach status. For information about creating automations, see About automations and how they work.

SLAs with schedules - when creating SLAs with business hours, you need to make sure that the schedule is properly setup. You can apply the appropriate schedule to a ticket by leveraging triggers. This is a great way to segment SLAs for teams that have different schedules or are in different regions. Additionally, this will allow you to get granular with your reporting on SLAs.

Reporting with SLAs - in Explore, you can access a prebuilt dashboard that allows you to monitor your SLA performance. The dashboard allows you to filter the reports in a variety of ways. The reporting can help you understand areas of improvement for you teams and highlight areas in which your team shines. For more information, see SLA reporting dashboard tab in Explore.

Bringing the conversation "full circle"

We’ve covered quite a bit about SLAs so far. I’m hoping you were able to find ways in which you can leverage SLAs for your team. A great place to start is by creating your first SLA policy and keeping it simple.

• On your first policy, give your team some leeway to see how they are handling the SLAs. This will make it so that you don’t overwhelm them. From there you can refine the SLA policy to push your team.

• With an SLA setup you can start monitoring your team's performance and find areas of improvement.

• Finally make sure to celebrate your team's wins. If they have a month where they meet all the SLAs, celebrate it. This is a great way to motivate your team towards a group goal. If you have great numbers with meeting SLAs, share that publicly to promote your awesome support team.

Additional resources

• SLA resources