SaaS SLA (Service Level Agreement) Best Practices

Before I get into advice on SaaS SLA practices, let me make one thing clear. I know as well as anyone that legalese is an important aspect of drafted agreements and provisions. However, that’s not what I’m here to discuss, and that’s not what you really need to worry about.

Once you have your SaaS SLA charted out in practical language, your legal department can interpret into fluffed language. Trust them, you’re in good hands with them. As for building your SLA in the first place?

I’ve been dreading this one. These things are technology-inspired politics for the most part, and that’s something I like to not have to be a direct participant in, politics. But, these things are very important, and if they’re not properly designed and drafted, then you can be brutally exploited, sued or even cited by the government for various mischievous practices.

So, as much as I hate having to talk about this and you hate having to research it, neither of us has much choice in the matter.

So, that said, the first thing to bear in mind with this is that in an SLA, you’re basically declaring what is fair use of your service in exchange for an agreed price from the user. That’s common sense, but there are some things to consider by way of definition of fair use.

You see, with your SLA, you need to outline the purpose of your SaaS, and what all constitutes proper (intended) use, and fair use of the software, in order for citing fair use for agreed price to actually have a meaning.

This is more important than just defining it for the further agreement clauses, either. You see, if you don’t define clearly what, and only what defines fair and intended use, then you have no legal claim to complain about abuse of the service.

If you don’t define this, and you don’t state what crises your support will take responsibilities, then people can “hack” your system, misuse it and do things with it they shouldn’t. And they can break it foolishly, and demand support and resolution grants for things you shouldn’t have to cover.

This is the biggest thing you have to worry about. Define what you intend them to be allowed to do, and define what constitutes a genuine accidental problem you are willing to make time to support.

Along with this, you also need to state the consequences of abusing the service or misbehaving within its space. If they can disclaim ever being warned of consequences, they can challenge actions you take in response to said rule breaking.

So, your SaaS SLA is all about outlining what your service is for, and it’s about making sure that the user knows what will happen if they do something foolish and malicious. It’s a fatal mistake to just assume that it’s a simple agreement about service for a price. Because that leaves you open to a world of worry and struggles the likes of which you cannot begin to imagine until you’ve lived through it. Just, now that you know what to frame out, make sure you let your legal people put it in concrete terms.

improves saas

Omri Erel
Omri is the Head of Demand Generation, as well as the Lead Author & Editor of the SaaSAddict Blog. Omri established the SaaSAddict blog to create a source for news and discussion about some of the issues, challenges, news, and ideas relating to SaaS and cloud migration.
Omri Erel on sabtwitterOmri Erel on sablinkedinOmri Erel on sabgoogleOmri Erel on sabfacebook