Fine Tuning: Succeeding with SLAs--why, when, and how!

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.

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:

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.

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

Service-Based Structure

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

Customer-Based Structure

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:

Conversation Starters

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.

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

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]

4) Automations

Conditions:

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]

5) Views

SLA Breaches View (
See “B is for Breach” below
)

Ticket status is “Less than Solved”

Ticket tags contain “SLAbreach”

Outages View

Ticket status is “Less than Solved”

[Enterprise]
Ticket Form is “Outage” or** [Professional] **“Reason for
Contact” is “Outage”

6) Macros

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 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.

Conversation Starters

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.

Meaningful Metrics

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

Agent Training

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.

Conversation Starters

What metrics are most important in regards to your SLAs?

How do you foster an SLA relationship outside of the contractual obligation?

Hi Sam! Thank you for your first post regarding SLAs in Zendesk. I want to share our experience using this feature to see how others are dealing with this in their teams.

What SLA metrics does your Organization use when establishing SLA policies?

Our SLA is that next and first reply should be under 24hs. Our main concern is that our customers aren't left without a reply for a full day. When establishing SLA policies in Zendesk, we created a workaround for tickets submitted by an agent on behalf of a requester, triggering a tag that activates an exclusive Full Resolution policy for those cases, that is later removed when the ticket changes status (so that the general Next Reply SLA policy will be applied in the future).

We did this as we wanted all tickets to have this active and visible, so we could sort the tickets by the label ("Reply in 3hs", "Reply in -2d", and so on), so that the "most breached" are shown at the top, but as some tickets are still open but the agent has replied something to the customer (maybe something like "Let me check that and I'll write you back"), the label is hidden and the ticket drops to the bottom of the view. How are other dealing with sorting tickets and these policies? Are they useful for them? How?

Other thing we wonder over here is how are others using the Full Resolution policy. We don't have any standard for how long a ticket should last until it's solved for good (we are in the Travel industry). How can you create that metric? What happens if the client keeps having new questions or updates, and reopening the ticket? I imagine this must be frustrating for the agents, but I'd love to hear other people's experience with this metric.

Instead of focusing on how to get customers to stop reopening tickets, you might want to examine why they’re reopening tickets. Generally, if a customer keeps replying to a ticket after it’s closed it means that their issue hasn’t been fully resolved. Are these customers reopening tickets and asking new questions or are their questions related to their initial reason for reaching out?

Look into a some recent tickets that have been reopened and analyze the comments after the 1st resolution time:

Are these new questions or related to the original request? Are there particular agents that have more reopens than others? If so, are the agents with higher reopens fully answering the question on their 1st response or could they have been more thorough in their answer?

Are your customers’ follow up questions related to issues that could have been avoided if proactive information had been given in the agent’s first response?

If the answer is yes in either scenario above, you might think about employing macros with canned responses to situations that frequently arise. It will help reduce your agents’ resolution time and reduce your ticket reopens

@Sam and @Sol: Not SLA related, but following on from what Sam says here.. One of the things we do is having a required 'topic' field on each ticket. The agent must select one of the topics in order to Solve a ticket. We then run analytics on reopens and negative CSAT responses against those topics to understand areas where agents have particular development needs, or we perform badly because of process problems. It takes a second to complete, but provides a wealth of useful information after the event.

Just whilst we're talking about reopens, we do have a specific set of SLAs that are for that channel specifically ("Closed Ticket"). That way, if an issue is reopened as a follow up ticket our customer gets a very speedy response.

As we all know, speedy responses do happy customers make, and if they're reopening an issue, chances are we did something to make them unhappy already. I don't want to fuel that negative feeling by making them wait longer.

I setup some SLA's about a month ago and was surprised how easy it was to setup. The only issue I ran into was that we were not populating the 'Priority' field so I had to go and update all my triggers to automatically populate that field. I loved that I could setup SLA's per group as one of our metrics that we track is the first response time which is different per group. Another great feature was being able to define Business Hours vs Calendars Hours. I know there is alot more to play around with but this was a great improvement over the old SLA setup.

Hi @Sam and @Matt, thank you for your feedback and tips. I see your point, and of course, you should see why the tickets get reopened after being solved, but regarding SLAs, what I wondered was how can you create a time metric around this. Maybe our case is different from other's. For example, when you are trying to sell something, at least we can't put together a metric to say what the full resolution time should be, as there is so much back and forward with a client. We are concerned our agents would be frustrated by being out of time as those cases can't be easily standardized.

Maybe in other industries it does make sense and wanted to know how this is used to see if this is something we could implement.

@Sol - One thing to note is that when you are talking back and forth with your client make sure to put the ticket in a 'Pending' or 'On-Hold' status as that will pause your SLA so the SLA is only counting time while its in your agents hands.

Yes, of course, but still you could go over the full resolution time. Maybe we are too permissive with our 24hs SLA for next reply? Because with that rule, I guess our full resolution SLA should be "24hs x average interactions needed"? Is this how others are crafting that metric? Or is it a lot less?

No clue here, I'm just asking for tips, but I don't want to hijack the post either!

@Sol - You're not hijacking anything. You've got great questions and I hope you keep them coming :)

I went back to your original post to get a better idea of your goals and workflow. In addition to monitoring your agents' reply times, it looks like you're utilizing the Zendesk SLA feature to put your most pressing features at the top of your queues. Instead of adding an SLA target to monitor reply time, have you thought about reconfiguring your View instead? You can reorder your Views by a plethora of options including "last update" and "last update by assignee."

Not sure if that would solve everything but I thought I'd offer that option!

Yes, regarding the views, we had them ordered by last update, but we got excited about SLAs labels and wanted to use them instead as they are so graphic and we hoped they would be a useful tool for sorting. We also wanted to stop using "last update" as we were running an automation to insert tags when tickets breached the SLA policy so we could put together reports about this, but that automation "unsorted" what we needed initially.

So we got to a point where:

We have the views sorted by the label, risking tickets will be lost by not having the counter active, BUT we could report on the ones that did.

OR we could have the views sorted by "last update", have the labels active or inactive depending on what the agent did (and they could or not make sense with the "last update" order), and not having reports about this.

Slightly off topic: Sam, have you thought about turning this fine tuning into a video? The tips you're giving in the posts are excellent, and it seems really well suited to a talk with some nice graphics ;)