SaaS Apps: Is SLA the Right Legal Tool?

All apps and websites need to have legal agreements in place to set out the relationship between the user and the app or website operator.

There are numerous different types of legal agreements that you can use for your app, such as Terms of Service, Terms of Use, End User Licence Agreements, and Service Level Agreements (shorten as SLAs).

It may look like a minefield trying to distinguish between all the different agreements, and what they are for, but there are some good reasons why particular agreements pop up time and time again in SaaS apps.

Many SaaS apps (Software-as-a-Service) use what are called SLAs, or Service Level Agreements, while other businesses try to avoid them wherever possible.

Let's take a look at what an SLA is and what they look like, and then go into detail on why you might choose to use one for your app.

What are SLAs?

A Service Level Agreement is a legal agreement between the customer and the service provider (the business) that sets out details of the service itself, rather than the relationship between the parties.

This kind of agreement usually covers topics such as the scope of the service, what level of quality and performance the service will meet, and responsibilities of both the service provider and the user.

This type of agreement usually also cover what will happen in the case that there is a fault or problem with the service, how long it will take before it is repaired, and how the customer can set up or terminate their subscription.

Here's a couple of examples of the topics this kind of agreement typically covers, from Hootsuite:

And:

From this example, you can see that your clauses for your SLA agreement should be intended to reassure customers that your service will live up to industry standards in terms of performance and up-time, as well as setting out clear expectations for how quickly problems will be responded to and fixed.

Here's another example from a Hewlett-Packard application:

You can see that HP sets out the commitment to uptime (99.9%), how uptime will be measured, and any things that are not factored into the uptime calculation, such as internet or DNS unavailability, force majeure, and scheduled maintenance.

Both the Hootsuite and HP example clauses are common terms in Service Level Agreements.

So do all SaaS apps use these? Far from it. There are numerous pros and cons involved in having these legal agreements, and particularly for some SaaS apps, their customers are simply not interested in signing up to an SLA for the service.

Benefits of Using SLA for SaaS

One of the major benefits of using an SLA, especially for SaaS apps, is that it sets out clear performance expectations, as well as notifications in the case of any kind of a security breach, availability of data upon contract termination, and under what conditions the SLA can be terminated, among other things.

This means that essentially it is all-round a comprehensive contract that can position the expectations of your customers.

The typical remedy for the consumer, if your app has performance issues, is that they receive fees credited back, or reductions in the price of their subscription or license.

If the app has very few service-level interruptions, the SLA payments will not be triggered, and potential liabilities under this agreement are extremely low risk.

Another major benefit of an SLA agreement is that it usually sets out clear escalation procedures in the case of an issue. This builds customer confidence and shows the customer that at each step of escalation you are ready and willing to communicate with the customer to continue to fix the problem.

Here's an example of an "Escalation Procedure" from an Oracle product:

When Not To Use a SLA

On a practical level, some customers may feel like an SLA is not useful for their purposes.

As we noted before, one of the main benefits is that the traditional remedy in the case of performance issues under an SLA is that fees are credited back to the customer. We specified that for a SaaS app that has very little or no downtime, these clauses will never be triggered.

However, what if that clause is triggered?

Let's take a look at this example from HP that shows what is provided in the case of up-time performance not being met:

You can see that the customer is entitled to an extension of the term at no cost. However, if the up-time of the service was less than 99%, the customer is not particularly likely to want to continue the term for 10 days at no cost, rather they are more likely to want to cancel the agreement altogether.

On a related note, when a customer signs up they may be less interested in future performance and in getting their money back if the app goes down, and more interested in seeing verified up-time data and long-term successful performance in the past. This means that they may not want to sign up to an SLA in the first place.

Some large SaaS providers such as SalesForce are transparent with their performance data, planned maintenance, and threats to the system.

HappyTech notes that:

If the point of the SLA was to prove uptime and security, and if SaaS companies are 100 transparent with that data – then what is the point of the SLA?

This means that for some SaaS apps, depending on how they present their service information to their customers, an SLA may not be needed.

Part of the issue is that there may be a disconnect between what the consumer believes they are getting out of the app (a service), and what the app provider feels they are providing (software). This can lead to Service Level Agreements being put in place in circumstances that aren't suitable for this kind of agreement, such as for apps that have very little risk of downtime.

A further issue is that SaaS apps that depend on third party vendors and partners may not be able to guarantee their performance to an acceptable level in an SLA. This leaves an agreement that is filled with caveats and provides no certainty for the customer. In this situation, it may be better for the SaaS app to use some other type of agreement such as a plain Terms of Service instead.

There are some caveats that are acceptable, however, such as exclusions for particular types of maintenance or expected downtime.

In the HP example at the beginning, we saw that they set out a "Boundaries and Exclusions Clause". This is to make sure that the customer has realistic expectations of the types of interruptions and downtime incidents that are within the provider's control.

Here's another example from WP Engine that sets out excused downtime:

Should You Use an SLA?

It depends.

If you are already very transparent with your performance data and depend on many third parties for the provision of your services, an SLA may not be a suitable choice. Your customers may simply not be interested (as they don't gain very much), and you may expose yourself to liability issues if you rely on a third party that ends up having performance problems.

If your performance data is less transparent, and your service is one in which you would reasonably expect very little down-time or performance issues, this kind of agreement can clearly set out your service availability expectations, maintenance requirements, time you'll take to fix problems, and other practical information that your customers are likely interested in.

The SLA agreement is a tool that has been used in business for a long time, and have become standard features within the IT landscape. However, SLAs should not automatically be assumed to be necessary as they may not suit all SaaS applications situations.

Consider your individual circumstances, and ensure that your legal agreements are clear, specific, and meaningful in those circumstances, whether your legal agreements include an SLA or not.