SaaS SLAs

SaaS contracts have three main SLAs. Which SLAs are relevant for a particular contract depends a lot on the service being provided and the context in which it is being used.

So, for example, if you are buying an air traffic control system you will want it to run 24×7 and uptime is going to be a big issue. On the other hand, if the SaaS service is an accounting system, then you are probably only concerned with uptime during office hours and downtime, even if irritating, is not going to be a critical issue.

So, the first SaaS SLA is uptime/downtime. At first blush that’s a pretty binary distinction, but in practice it can be more complicated. If the SaaS system is totally down and no-one can reach it, then it’s down. But what if it’s not totally down, but limping? Or some of your staff can reach it, but others can’t? There’s no right answer to any of this: you just have to form a view as to what works for your company, and the accompanying price point.

The second SaaS SLA is system response time. You rarely come across this one because for most SaaS services system response time is not a critical issue. But if you are running an air traffic control system, a stock trading system or a payments system, it is a big deal and you need to make sure your contract provides for it.

System response time is usually measured as the time it takes for the SaaS system to respond to an API call, the point of measurement being the edge of the supplier’s network. Assume that the API call arrives at that edge at time X, and the response leaves the edge at time Y, then the gap between the two is the system response time.

The third SaaS SLA deals with support. Generally these are reasonable obligations because the nature of incidents is that you can’t be sure how long they are going to take to fix (and major incidents should be addressed by the first two SLAs). If you are a buyer with a lot of negotiating power, you might be able attach service credits to fix times (see next week on service credits), but usually a more practical approach is to provide for an escalation path whereby, as the time to the fix extends, you get a response from an increasingly senior person until, if the problem persists, you are talking to the CEO.

There’s no right answer to any of this: you just have to form a view as to what works for your company, and the accompanying price point.