Any support organization can claim it’s committed to providing great customer service. But what does that mean? After all, one company might define a great service level by how quickly it resolves issues, while another might choose to eschew fast service for personal, upsell-driven support. And even once the definition of quality support is defined, how can that support organization ensure it’s actually meeting that standard?

Service level agreements (SLAs) aren’t exactly the most exciting concept. Essentially, they’re written agreements, typically part of a larger contract, that formally specifies a specific standard that must be met by support. An SLA really just boils down to ensuring a baseline level of quality for your customers.

Setting a service level objective

As stated above, every support organization will want to set a support SLA that is specific to the goals of that company. For example:

These types of goals are service-based, and are meant to broadly apply to all customers. However, it’s also possible to set a customer-based service level objective, including:

  • One touch resolutions for VIP customers.
  • Response times for support requests made publicly via social media.
  • Prioritizing customers from a region with a recently opened store or office.

The key factor is aligning SLAs to larger company goals and priorities.

Support SLA workflow

While some companies might have “unofficial” service level agreements, an SLA isn’t an SLA if it isn’t worked into the organization’s workflow. Otherwise, it just becomes a thing everyone will try to stick to, but will be impossible to track. Here are three examples of ways to seamlessly incorporate them:

  1. Organize all clients with relevant service levels and automatically route them through the appropriate support workflow.
  2. Set up triggers to alert the team when an SLA is due and automatically escalate priority tickets to the top of queue.
  3. Set triggers for when an SLA is violated, setting off a series of triggers that let the team and managers know, subsequently allowing you to create a report to keep track of your monthly progress.

Dealing with a breach

Now that you’ve chosen which metrics to include in your support SLA, and have made that SLA a part of your workflow, you need to be ready for when things don’t work out. Don’t worry, it happens to almost every support organization and will likely happen to yours. The most important thing is to prepare for this eventuality.

Start by building a process for dealing with SLA breaches. First, set up an automatic alert, sent to a supervisor, for when SLAs are not met—another reason SLAs should be built into your workflow. This will help that supervisor immediately assess the severity of the situation and decide how to deal with it.

Next, support leaders should have a pre-written game plan for acting on the different types of breaches. Is a single agent not able to meet an SLA around working on tickets for a maximum time before that ticket is escalated? That agent might require more training. Is ticket deflection too low? It might be time to revisit the self-service strategy.

Or is this something larger? Maybe an SLA focused on hold times isn’t being met because of an enormous surge in calls at the same time. This could point to a major problem, such as unscheduled downtime.

Once you’ve enacted workflows and a breach game plan, it’s also good to regularly audit your workflows and business rules to make sure they’re still valid.

Next steps

Maintaining high quality support is the most obvious benefit of SLAs. However, they’re also invaluable data sources that can be studied and acted on for continual improvement. Using key performance indicators (KPIs) in your SLA workflow will identify specific components of your support offerings that need some work.

But how do you determine which KPIs matter to your organization? No single metric can answer all questions for all companies. Just like workflows and SLAs themselves, it should be based on what your organization values. Below are some metrics that are helpful to monitor as they pertain to SLAs:

  • Full resolution time: how long it takes for the issue to be resolved once the ticket is opened.
  • One touch resolution: the number of tickets that are resolved by the first responding agent, within the first interaction.
  • First response time: how long it took to initially respond once the ticket was created.
  • Hold time: usually associated with phone and chat support, how long customers wait in the queue before an agent can assist them.
  • Customer satisfaction (csat): a measure of how satisfied customers are with individual support interactions.

The specific service level agreements and KPIs used to measure them can be used to guide how you measure agent performance. Doing so will get your team on board with expectations. Once you’ve determined your priority metrics, make sure your agents know so they can work accordingly.

Your agents’ KPIs should align with your organization’s SLAs or any other goals. For example, you might not want to measure your agents on the number of requests they take in a defined timeframe if your company’s KPIs include resolution time or CSAT goals. An agent who is attempting to maintain that defined timeframe goal by getting through as many requests as possible might be incurring 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.