This Fine Tuning session is all about SLAs (aka Service Level Agreements). We'll cover:
- What is an SLA?
- The Business Rule Puzzle
- 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.
See all the Fine Tuning series discussions .
Part 1, 8 am: What is an SLA?
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 One 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.
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:
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
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.
Deciding which SLA metrics to use
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
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.
- Ex 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)
- Ex Two Train new agents by setting goals for how long they should spend with each ticket ( Metrics used: Agent Work Time)
SLA to monitor overall resolution times
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.
- Ex 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)
- Ex 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)
SLA policy for Social Media channel*
*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.
Super psyched to get started with your own SLA policies but still need a little more inspiration? Check out some of the great ways your fellow Zendesk users have used the SLA feature:
- Using Enhanced SLAs by Mat Cropper
- Running triggers, automations & reporting based on ticket SLA by Mat Cropper
- How to Set Up Multiple SLAs with Different Business Hours by Tlo
- What SLA metrics does your Organization use when establishing SLA policies?
- Share some examples of innovative ways you’ve used Zendesk’s SLA feature
Part 2, 11 am: The Biz Rule Puzzle
An SLA does not a workflow make
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.
In Section Two of today’s Fine Tuning Series, we’re going to talk about how you can work SLAs into your larger workflow.
Finding a path to your SLA priorities
An SLA is not a standalone 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 Section One, 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 portal and we want to monitor their resolution times.”
- “We want to make sure our 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.
Recommendations on creating a workflow in Zendesk
- 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.
Example of a Workflow that incorporates SLA policies
Scenario: A company wants to add a clause to a customer’s contract guaranteeing that site outages will be resolved within 1 hour.
What are we trying to do?
- Automatically prioritize outage tickets
- Keep agents aware of the time they have left to solve it
- Notify the customer when the issue has been resolved
- Alert supervisors if the SLA has been breached
1) Custom Fields
- [Enterprise] Create a ticket form called “Outage” and include/create fields for all relevant information
- * [Professional] * Create a drop down ticket field on your web form called “Reason for Contact” and include “Outage” as an option
- [Enterprise] Ticket form is “Outage”; Organization is [the customer]
- * [Professional] * “Reason for Contact” is “Outage”; Organization is [the customer]
Perform these actions:
Requester Wait Time
- Urgent = 1hour
- High, Normal, Low = 24 hours (or whatever your resolution time goal is)
Clone default “Notify Requester of Received Request” and call it “Notify [the customer] of Outage Report”
Leave default Conditions and add the following:
- [Enterprise] Ticket Form is “Outage”; Organization is [the customer]*
- [Professional] “Reason for Contact” is “Outage”; Organization is [the customer]*
*You’ll need to modify the default notice to exclude the conditions above so that two notices don’t fire off
Perform these actions:
- Ticket Priority is Urgent
- Notifications: Email User is Requester (Tailor the message to the customer and mention the guaranteed resolution time)
- Notifications: Email Group is [your team that handles outages]
- Ticket Status is Less than Solved
- [Enterprise] Ticket Form is “Outage” or [Professional] “Reason for Contact” is “Outage”
- Organization is [the customer]
Perform these actions:
- Add “SLAbreach” tag
- Notifications: Email User is [the Group supervisor]
SLA Breaches View ( See “B is for Breach” below )
- Ticket status is “Less than Solved”
- Ticket tags contain “SLAbreach”
- Ticket status is “Less than Solved”
- [Enterprise] Ticket Form is “Outage” or** [Professional] **“Reason for Contact” is “Outage”
- Ticket status is Solved
- Ticket Type is Problem
- Ticket Comment: Let the customer know the outage has been resolved and how they can contact you if the problem persists
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 in Zendesk 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! Users on the Enterprise Plan 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.
- What business rules or other Zendesk features do you use with your SLAs?
- What concepts do you keep in mind when creating workflows around SLAs?
Part 3, 2 pm: So you’ve got SLAs. Great. Now what?
SLAs and Insights
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.
In Section 3 of this Fine Tuning Series, we're going to discuss the actions you should take after you establish your SLA polices.
The final step to your SLA puzzle is to implement Insights reports. While SLA reporting in Insights is scheduled to be available by the end of the month, there is still a lot of data originating from your SLA targets that can be analyzed within Insights right now. Some SLA contracts include customer checkpoints to follow up with the service provider and make sure they’re holding up their end of the deal.
Insights can assist you with this in multiple 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.
- Who says you have to wait for your customer to reach out to you? Take it a step further and proactively send them dashboard reports that you can schedule from within Insights. It shows your confidence in your ability to deliver results, but it also helps build their confidence and trust in your abilities ** Check out this KB article for more information on sharing your Insights reports **
Insights 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
- Resolution Time aka Turn Around Time (TAT)
- 1Touch Resolution aka First Call Resolution (FCR)
- First Response Time aka Average Speed to Answer (ASA)
- Time waiting for support
- Requests solved by Self-Service (Knowledge Base)
- CSAT/NPS* → 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 Insights 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.
- What metrics are most important in regards to your SLAs?
- How do you foster an SLA relationship outside of the contractual obligation?
Please sign in to leave a comment.