Should I use SLAs in SaaS customer support?

Should I use SLAs in SaaS customer support?

Here is a tough question for managers of customer support of SaaS and conventional software companies: Should you use SLAs?

To tackle this controversial topic, we will try to build the answer in parts:

SLAs vs. OLAs

There are a few interpretations of these elements, but the most common understanding is that a Service Level Agreement (SLA) is used between a service provider and a customer, while an Operational Level Agreement (OLA) is used between two or more functions or departments of the same organization, where one is providing specific services to the other.

OLAs are also used as inputs for SLAs, describing the relationship between internal departments of an organization providing services to a customer. In either case, there are no monetary transactions between both parties under an OLA. SLAs, on the other hand, govern how services will be provided to a customer and how they will be paid for. 

Components of an SLA

SLAs are primarily designed and built out of these critical components: 

  • The service catalog, which lists the services that will be provided to the customer.
  • The obligations of each party as they relate to these services.
  • The metrics by which each item of the service catalog will be measured.
  • The goals established for each metric (the “service levels”).
  • Penalties to be applied in case the agreed upon service levels are not met.
  • Optionally and ideally, bonuses to be received in case the service levels are exceeded by specific measures.

These key components are used to ensure a clear understanding of the services to be provided, what will be considered a satisfactory level of performance, and how a better or a worse performance will be financially rewarded or penalized.  

Is it an SLA?

Before answering the question “Should I have an SLA in place?” one should ask themselves, “Am I talking about an SLA?”

This second question may be answered through a quick analysis of the components of an SLA that we’ve just discussed. Are they present in this discussion? Or am I just talking to customers who want to know my current metrics for the services provided? Or perhaps my customer just wants a verbal commitment that my services will remain at certain levels?

One may think that once “target levels are established,” one has established a service level agreement. While that may be semantically correct, it doesn’t actually yield the desired results—just as speed limits on roads wouldn’t have their desired effect if there were no speeding tickets.

An SLA, as any kind of agreement, should not only establish what has been agreed upon—services and levels—but also what happens when the agreement isn’t met. This will be the required enforcement to ensure both parties put in the necessary effort to comply with their agreement.

Monthly subscriptions and maintenance fees

SaaS companies usually charge recurring subscription fees. Similarly, conventional packaged software companies charge recurring maintenance and support fees. Even in tiered-support environments, in both cases, those are fixed fees—no matter how many support tickets the customer creates or how long the service provider takes to address them, the recurring fee remains the same.

These recurring fees usually leave no room for service penalties or bonuses for high performance. In fact, adding penalties or bonuses also adds an undesired level of complexity for fee structures. Without penalties or bonuses, customers are automatically bound to receive a flat service level for the flat fee they pay. 

Undesired results of “SLAs” in flat-fee customer services

Most customer support that’s included in recurring fees for software companies (SaaS included) has to do with answering customer questions, dealing with product defects, or addressing incidents that are causing the customer problems.

In most cases, answering questions or addressing an incident related to the misuse of a product are straightforward, quick tasks. It’s the problems related to the software or the processing environment that represent most of the tricky tickets. These not only demand more time and effort but also—and most importantly—affect multiple customers.

There are undesirable results from SLAs in operations where one action, such as fixing a bug, impacts multiple customers. The most important one is that agents tend to prioritize issues that are not relevant to the customer base as a whole because of SLAs established with individual customers. As metrics drive behavior, support agents and software engineers may focus on putting out fires for individual customers while unknowingly hurting their whole customer base.

Should I use SLAs then?

The market today has an intrinsic understanding that SLAs give the customer a tool to enforce the agreed upon service levels. If any document states those levels but does not provide any enforcement, benefit, or penalty mechanisms, these statements will likely be useful only for the sake of argument.

A software company will always try to provide good customer services, as everyone knows how important that is for customer satisfaction and retention. If those services are in a good standing, you want to show them off. If they are not, it’s because your company is facing some difficulty—software stability, infrastructure, lack of knowledgeable people, etc. These issues are both time-consuming and hard to fix. In these challenging situations, you don’t want to give your customers a vague document that—while not providing them the power to penalize you—still gives them leverage to complain or harass you, either directly or on social networks.

If your goal is just to present a “reference level of services,” then that’s what you should call it. Naming it an SLA will create false expectations about what you will and won’t do.

We have faced situations in numerous companies where a customer asks for an SLA, or even demands one. The given reasons range from “it’s my company’s policy to have an SLA” to a simple “I want to have an SLA,” or even an implicit “I don’t trust you.” Every time we have been able to get through this kind of demand by using one of these two approaches: 

  • Show the customer that an SLA is not necessary, since your service levels are as high or higher than what they desire. Show the customer your internal numbers if required. Once they see the numbers and are satisfied with them, they often are no longer concerned about an SLA.
  • If the customer insists, tell them you will need some extra management effort to address the SLA and the required setup and periodic reporting, so you are open to provide them with the requested SLA at an additional cost. In most situations, they will give up their requests. In some rare cases, they will agree to the extra charge—but then you will have some extra money to offset the additional work and disturbance of your standard customer support processes.

So, in short, SLAs under a recurring flat-fee usually yield far more negative results than positive, even if they’re only used for some customers. As a rule of thumb, not having SLAs—if possible—is better. If you have a particularly large customer with deep pockets banging on the table about it, charge for it, or look at it as an extra cost for a sizeable recurring fee you are getting. Treat exceptions as exceptions, and try to stay away from SLAs and their additional costs when you’re getting fixed recurring fees. Leave SLAs to billable, variable services.

Agree with the above? Have a different opinion? Have a particular issue with it and would like to exchange some ideas? Lived through an interesting experience? Please leave a comment! We’ll be happy to learn or share more information and insights about the topic.

Leave your comment