Like any legal document, a service-level agreement (SLA) can be complex and confusing. Software as a Service (SaaS) SLAs are no exception. To further complicate matters, SaaS SLAs are written with the provider’s best interests in mind – not the customer’s needs. Therefore, it behooves businesses to know what they can expect to see in a SaaS SLA before evaluating providers.
“There are basic items that are always covered by an SLA,” says Bernard Golden, CEO,
HyperStratus. However, there are some items that may or may not be included in an SLA, depending on the service provider, he says. “Service-level agreement means availability, but when people use the term SLA, it has a broader application. It addresses more than technology. It includes things like notifications in terms of any kind of a security breach, availability of data upon contract termination, what the conditions are under which a contract can be terminated. The phrase SLA often gets overloaded with a number of terms that may or may not be what you expect,” says Golden.
The following items, if not covered specifically in an SLA, should definitely be covered within the larger contract, which, according to Golden, “is the controlling commitment.”
Availability of SLAs
More resources on SaaS SLAs
Availability is expressed as three, four or five nines. “One thing one has to keep in mind is, as a provider stretches to more nines – meaning lower levels of downtime – there is an increase in cost,” says Golden.
In addition to availability, consider the business function being provided. “What’s important – and it’s a real challenge because the vendors don’t want to do this – is to have SLAs oriented towards the business value you’re expecting from the SaaS,” says Bill Corrington, cloud strategy lead, Stony Point Enterprises.
Corrington uses email as a service to explain: “Email is actually very complex. If you don’t have internal routing and contact books configured, you won’t have email delivered. The system is up, but the email is not getting delivered,” he says. In this case, he advises having an SLA for the percentage of emails delivered.
Downtime in an SLA
Corrington’s email example may not even count as downtime as far as the service provider is concerned. So it is important to define downtime in an SLA.
“People also talk about what counts as down time: only unscheduled downtime or scheduled maintenance of updating systems – does that count as downtime? From the point of view of the provider, that may not count as downtime,” says Golden.
When the system is down, you certainly don’t want to pay for it. “One thing that will always be in a base agreement is compensation in the case of service unavailability. Limited to service unavailability – we’ll refund you the cost of the service for X amount of hours. It’s never going to cover lost sales – you might want this to happen, but no vendor will ever agree to that. Liability will be just too extreme for the X the company will represent,” says Golden.
Mean time to repair and mean time to respond
An SLA should also define issue severity levels, and a mean time to repair and mean time to respond for each, says Corrington. For example, if a severity 1 issue is critical, meaning a system is down, the mean time to respond and mean time to repair should be less than a severity 3 issue, which may be more of an inconvenience.
Similarly, says Corrington, you should have service level agreements based on your users. “It is important to recognize that you have some users who are more important than others,” he says. These “VIP” users should have precedence over others when it comes to troubleshooting issues. For example, if you are using an email SaaS solution and your VIP user – a division vice president – can’t send email on his smartphone on a Saturday morning, then the problem should be addressed as a severity 1 issue.
“The vendor needs to understand who these folks are, by name or title, and the vendor has to understand that they need to meet the right SLAs,” says Corrington.
“One of the big differences in going from internal, on-premise to externally owned and operated is that span of control,” says Corrington. When there’s a problem with your internal email system, you know to call your sys admin, he says. With SaaS, you wouldn’t expect to talk to someone with full admin privileges on the infrastructure.
“You need someone in the management chain on the vendor side who will take action. It’s important to have that understood and documented. You don’t want to be on hold with the call center,” says Corrington.
A word of warning on SLAs
Finally, it is important to put the SaaS SLA in proper perspective. “One should not confuse the existence of an SLA with the actual real world performance of the SaaS app,” says Golden. “It doesn’t eliminate the need to evaluate the system.”
In other words, do not assume that the service will truly be available because the SLA says so. Evaluate the service for yourself. Consider: What has been the actual experience of customers to this point? How well does the provider provide this service? What are the provider’s plans for a disaster? Does the provider have a disaster recovery system that will be up and running immediately?
“The SLA doesn’t control what is actually delivered,” says Golden` “It’s about how you fight over the spoils at the end. In effect, you never want to have a discussion of the SLA because you want the service to be available.”
This was first published in May 2012