This Fine Tuning session is all about SLAs (aka Service Level Agreements).
- Part 1: What is an SLA?
- Part 2: The Business Rule Puzzle
- Part 3: So you've got SLAs. Great. Now what?
Before joining Zendesk as a Customer Success Consultant, Sam Chandler was a Zendesk Administrator and has utilized the platform to do everything from building out Customer Service departments to processing purchase orders. She's a former user group leader for the Atlanta area, and has presented on customer service topics in various webinars and in-person events.
To find more Fine Tuning articles, see Fine tuning resources.
Part 1: What is an SLA?
In Part 1 of this Fine Tuning, we'll define what SLAs are and talk about why you should care.
Service Level Agreements ...That nebulous idea once only embraced by telecom operators of the 1980s has now been adopted by any organization looking to differentiate themselves through service. But what exactly is a Service Level Agreement and what purpose does it serve in the greater realm of Customer Support? It’s an idea that’s constantly changing and evolving, but it’s a building block that’s working its way into so many other aspects of the broader customer experience.
Why should you care?
Incorporating SLAs into your workflow can help you streamline your ultimate #custserv goals. Why you ask? Because what gets measured gets done. A recent study of IT users covered by response-time SLAs reported an average response time 200 times faster than their non-SLA counterparts. Moreover, simply establishing SLAs can change perceptions for the better. The study also found that most customers with SLAs believe their service providers are meeting the terms of those agreements.
In Section 1 of today’s Fine Tuning Series we’re going to discuss some of the types of SLAs and how you can fit them into your own support ecosystem.
Defining the Term
A Service Level Agreement (aka - SLA) can officially be defined as part of a service contract where a service is formally specified and particular aspects of the service are agreed upon between the service provider and the service user. Unofficially, however, an SLA really just boils down to ensuring a standardized service experience for your end-users.
Zendesk helps you establish SLAs by defining service targets, allowing you to monitor values associated with your service goals and ultimately to reach those goals. Creating an SLA policy in your portal adds visibility to tickets that fail to meet service level targets so you can quickly address them.
What are SLA policies?
Zendesk 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
- Whether targets will be measured in business or calendar hours by priority value
To determine how to best incorporate SLA policies into your customer service, Let’s take a moment to explore a couple of the major types of SLA structures:
- Customer-Based: an agreement with an individual customer or group
Example: A telecom company writing in a guaranteed uptime as a clause in a customer’s contract
- Service-Based: an agreement for all customers using a particular service or product
Example: A pizza place promising free pizza to customers whose orders are not delivered within 30 minutes
The types listed above can be used independently or combined to create any number of service models - it’s all up to your organization and how you decide to guarantee service to your customers.
How to use Zendesk SLA policies in your organization
One of the greatest strengths of Zendesk’s SLA feature is its adaptability. Whether your Support Portal is a piece of your company’s larger SLA puzzle or if it makes up the entire thing, it’s easy to create targets based on the types listed above, to help meet your organization’s broader KPIs, or even a combination of the two.
Zendesk SLA policies are built upon four metrics: First Reply Time, Next Reply Time, Requester Wait Time, and Agent Work Time.
The first two metrics are based on reply time, while the latter two are based on resolution time. While only one resolution based metric can be used at a time, the reply time metrics can be used simultaneously. So how do you connect the dots to create a policy that works for you? Below are some examples of service and customer based SLA structures that take advantage of the metrics available to you in the Zendesk SLA feature:
Examples of Possible SLA Structures
- Service-Based Structure, SLA to monitor overall resolution times
This is a great way to get your feet wet with service level agreements. Before you go all in with a structured contract guaranteeing service to a specific customer, you could hone your teams’ skills by establishing service standards for all tickets.Not only will this will help ease your support agents into the pressure of meeting service standards but it will also increase overall efficiency for all your customers.
Example one: Set a company goal for initial reply or resolution times and apply an SLA to all tickets ( Metrics used: First Reply; Requester Wait Time)
Example two: Train new agents by setting goals for how long they should spend with each ticket ( Metrics used: Agent Work Time)
- Customer-Based Structure, SLA policy for Social Media channel*
There are several ways to build a customer-based SLA with Zendesk. You could set up one SLA per customer that included different standards for each. You could also group customers based on specific traits. In addition to the ability to honor SLA contracts you’ve set up with individual customers, the SLA feature also allows you to focus on specific Priority Values.
Example one: Proactively address an SLA contract with a customer by setting a policy to let you know when open tickets from their Organization need a little love ( Metrics used: Next Reply Time, Requester Wait Time)
Example two: Optimize your social media support presence by establishing an SLA to monitor response times for people who submit tickets through a Twitter or Facebook channel ( Metrics used: First Reply Time, Requester Wait Time)
*Please note: In the interest of saving space, I’ve listed 2 of the social media channels that Zendesk offers. To achieve optimal results, however, I would recommend including all possible Facebook and/or Twitter options in your “ANY” conditions.
Part 2: The Biz Rule Puzzle
In Part 2, we’re going to talk about how you can work SLAs into your larger workflow.
A single SLA policy does not make a complete workflow
Now that you have a better understanding of what SLAs are, it’s time to put them to work. It’s important to remember, however, that SLAs are not the end all be all solution that will fix every issue you might be experiencing. A Service Level Agreement is just a contract; a relationship with your customer is built on trust and proactive care is still necessary.
Finding a path to your SLA priorities
An SLA is not a stand-alone feature that you can set and forget. If you think of your workflow as a puzzle, SLAs are just one piece along with triggers, macros, automations, and all the other Zendesk features. Fortunately your Zendesk portal is adaptable to a variety of workflow designs. It’s about finding the path that works best for you.
With any workflow, I always recommend starting simple and building on as needed. You should begin by picking one Priority Value and designing around it. Like I mentioned in Part 1, the value you deem as your priority is dependent upon what’s most important to your organization. Before you know it you’ll have multiple workflows that emerge organically - some workflows perhaps intertwining while others stay completely separate.
Examples of Priority Values
- “We just set up paid service levels where we guarantee our customers certain response times.”
- “We just added a new department to our Zendesk and we want to monitor resolution times.”
- “We want to ensure tickets submitted from Twitter are addressed within a certain time frame.”
Sam’s Recommendation for designing a workflow
Below is a chart of the order in which I generally create a Zendesk workflow. Please keep in mind that, like most things in life, this order will always vary by your project and intentions.
One thing to note while you’re creating your SLA workflows in particular is that Zendesk SLA policies work in conjunction with the “Priority” ticket field. This is different that the “Priority Value” you’re using to drive your workflow. In order to create SLA policies in Zendesk you’ll need to utilize the “Priority” ticket field in your ticket form for this feature to work properly.
Some notes on creating a workflow in Support:
- I tend to think of custom fields as the seeds from which your workflow grows. It’s rare that I don’t have to add at least one custom field to a ticket form, user, or organization to be used in the other business rules I create for the workflow.
- Did you know that you can control the formatting of the columns in each view? When creating a custom view for your SLA targets, make sure to include the “Next SLA Breach” column. You can also export your views as a CSV file, so you definitely want to make sure that you display the columns relevant to this view (and in a relevant order).
- Macros are one of my favorite Zendesk features; they’re like the cherry on the sundae of a great workflow. I like to use macros to help keep everyone on the same page - especially when introducing a new workflow. If I can create a macro that performs multiple functions at once it saves my agents from having to remember all of those steps, thus reducing errors. Added bonus: using macros to create a library of canned responses for agents to use when talking customers through issues also helps unify your messaging and ultimately your brand.
For a great example of a workflow that includes SLA policies, see Workflow recipes: Manage outages using SLA policies.
B is for Breach
Even though your team is awesome and will probably seamlessly incorporate your new SLAs into their workflow, it’s important to create a process for those times when you’ll inevitably experience an SLA breach.
This process should include a workflow to alert either an agent or supervisor of the breach at the least, but you should also think about setting up a process for identifying and coaching agents who are consistently missing their SLA goals.
- Create an automation to notify supervisors and/or agents of SLA breaches.
- Create a custom view for SLA breaches.
- Create an automation that tags SLA breaches.
You can create a report or view based on the number of each agent’s breaches so you can coach the later.
Auditing your Workflows
It’s also good practice to periodically audit your workflows and business rules to make sure they’re still valid - especially when you’re dealing with contracted SLAs!
On Enterprise plans you can utilize the Property Analysis for Rules function to assist in the audit process. Users on all plans, however, can audit their Business Rules by running through them every once in a while to make sure they’re still relevant.
Part 3: So you’ve got SLAs. Great. Now what?
In Part 3 of this Fine Tuning, we're going to discuss the actions you should take after you establish your SLA polices.
SLAs and reports
You can set up the most beautifully constructed SLA workflows the world has ever seen, but they don’t mean much unless you’re taking the necessary steps to analyze your data and ensure you’re meeting your goals.
The final step to your SLA puzzle is to use pre-built Explore reports, if you have access to Explore reporting. To view Explore pre-built SLA reports, see Overview of the Zendesk Support dashboard. Additionally, you can use Explore to create your own custom reports.
Some SLA contracts include customer checkpoints to follow up with the service provider and make sure they are holding up their end of the deal.
Zendesk reports can assist you with this in these ways:
- By keeping up with your own stats, you’ll be able to diffuse any hiccups as you near your customer checkpoint meeting by proactively fixing any issues before it’s too late. Additionally, having your own data to support your standings can come in handy if your customer ever comes to you with complaints.
- By proactively sending dashboard reports you'll show your confidence in your ability to deliver results. Currently, you can share Explore reports with others in your organization. A future update will let you send these directly to anyone, including your customers. For more information, see Sharing dashboards.
Explore is an incredibly powerful reporting tool filled with just about any metric you could imagine. So how do you determine meaningful KPIs? There is no one “end all and be all” metric that will answer all questions for all people. Just like workflows and SLAs themselves, it’s based on what your organization values.
Below are some metrics that are helpful to monitor as they pertain to SLAs. I’ve also included the terminology that has been used in various support environments to describe the same metrics
|Explore metric||Common terminology|
|First resolution time or Full resolution time||Turn Around Time (TAT)|
|One-touch tickets||First Call Resolution (FCR)|
|First reply time||Average Speed to Answer (ASA)|
|Requester wait time|
|Various (see Metrics and attributes for Zendesk Support).||Because none of the other numbers matter if your customer still isn’t satisfied|
*Satisfaction ratings can also act as a check point before an official customer review
It’s also important to make sure your entire team is on board with your expectations. Once you’ve determined your priority metrics, make sure your agents know so they can work accordingly. Post metrics and reports in internal Knowledge Bases or maintain SLA dashboards in Explore or any place your team will have access. Many times we focus on making sure our senior leadership receives copies of reports but it can be healthy to make sure the entire team knows where you stand as an organization.
Most importantly, you should make sure your agents’ KPIs align with your SLAs or any other goals. For example, you might think twice about measuring your agents on the number of requests they take in a defined timeframe (Time Service Factor) if your company’s KPIs include Resolution Time or CSAT goals.
An agent who is trying to maintain their Time Service Factor goal by getting through as many requests as possible might be incurring more ticket touches or lower satisfaction scores by rushing through tickets without fully resolving customers’ issues. You also don’t want to focus entirely on one metric at the expense of others. First reply time is certainly important, but you don’t want your agents so focused on replying quickly on their initial touch that they ignore how long they’re taking on their subsequent touches.