In his recent blog post, Philippe Botteri from Bessemer Venture Partners lists the “10 Laws of SaaS” from their recent invite-only event for CxOs. I agree with 9 of the 10 laws, but disagree with law 6:

6. One Datacentre. Invest early in backup and diisaster recovery, but stick to one data centre, at least until well after IPO.

How many data centres you have does not matter. What matters is your SLA, and there is no mention ofervice level agreements in the “10 Laws of SaaS”.

I th think this focus on the number of data centres is wrong. Customers only want to know the terms of your SLA, and whether you meet those terms when a problem occurs.

Your SLA: What you do when things go wrong

ISVs must answer hard questions on uptime and security from new SaaS customers. B2C ISVs with Web 2.0 sites might be able to avoid these for a while. B2B ISVs cannot.

A tough and fair SLA is vital to your success as an SaaS ISV. You must focus on your SLA from day 1. You will ask customers to trust you, your software and your systems. If your SLA is not credible (or worse, does not even exist), you will not make any sales.

Your SLA is vital to your success in a way your support offer was not with on-premise sales. Any SaaS problem is seen by all your subscribers. You have to react, and you have to react now. You do not have time to stop and think, just act. You have to do your thinking when you write your SLA, not when a problem turns up.

CEOs: Spend less time on golf and more on your SLA

Did you handle the problem well? The answer is up to your subscribers, and not you. What they expect is in your SLA. You might do a great job of fire-fighting, but if you do not do what your subscribers expect then you have a big problem.

Do not spend your time worrying about keeping your hunters and your farmers separate. Instead, make your CEO your SLA champion!

Your SLA is at the heart of your SaaS business. Ignore it and you will not be going to many invite-only events at Golf and Country Clubs in Silicon Valley.

Image: Service level agreements will increasingly become a competitive differentiator in the SaaS market. How will your weasel worded SLA stand up when competitors offer real (and significant) cash for downtime?

Web news is talking about the 2 3 4 5 fibre optic cable breaks in the Middle East. While the net was designed to be up all the time, there will always be faults.

How do you react when a fault impacts your subscribers? Do you tell them it is not your fault? Do you tell them they must just put up with it? Today many ISVs are doing just that.

With no or very weak SaaS SLAs, at best customers might get a refund for that month’s service fee. Because no real cash is at stake many ISVs have not invested.

What, though, if SaaS ISVs had to pay a real (and fair) amount of cash to customers for downtime? We expect planes and trains to pay if they mess up our plans. Why should SaaS be a special case?

We can see how some ISVs value SLAs by looking at what they do and say when a fault occurs. Two recent examples:

1 Million 37signals users and still no SLA

37signals is well-known in the SaaS and Web 2.0 world. Often quoted as a good example of SaaS, all their products were down (again) for a few hours recently. This post was made on their product blog once the fault had been fixed:

… While we don’t have a formal service-level agreement (SLA), we still want to compensate anyone who felt they were negatively affected in their work because of this outage. Please write support@37signals.com (and include your application URL) and we’ll get that taken care of. …

With more than 1 million users, an SLA is the least users can and should expect. A lot of the user’s comments about this downtime were from consultants. They were relying on 37signals’ products being up and running. When they are down they could not work. I don’t know how much 37signals refunded users in this case, but I doubt it made up for the lost access to many users.

It is easy to say you are sorry for downtime. It is much better to show (with cash) how sure you are this is not going to happen again. Users that are paying for services can, and should, expect a real, tough and fair SLA from 37signals. As long as they can get away without having one it makes it a little more tempting to think that you do not really need one either.

SLA not necessary for on-demand FogBugz?

FogBugz is a bug tracking and project management system from Fog Creek Software. In the last 6 months or so they started an on demand version, which was down recently. Here are some quotes from their blog post on what happened.

The first quote is from their system admin:

… I know that we don’t officially have an SLA for On Demand, but I would like us to define one for internal purposes (at least). …

CEO Joel Spolsky then responded:

… But there are some problems with SLAs. The biggest one is the lack of statistical meaningfulness when outages are so rare. We’ve had, if I remember correctly, two unplanned outages, including this one, since going live with FogBugz on Demand six months ago. Only one was our fault. …

Downtime is always your fault. Your customers pay you money for the service. If you do not provide it, then it is your fault. The buck always stops with you. In this case they went on to make an offer to pay for the downtime:

… In the meantime, our customer service folks have the authority to credit customers’ accounts if they feel like they were affected by an outage. We let the customer decide how much they want to be credited, up to a whole month, because not every customer is even going to notice the outage, let alone suffer from it. …

The tone of this whole post is that an SLA does not mean anything. They claim it is not always their fault. In any case, many subscribers did not even notice. You might not see it this way if your team cannot work. Fog Creek should do better on reacting to faults. A real, tough and fair SLA would be a good place to start.

Planes, trains and SaaS SLAs

In the old days plane and train firms were not liable for delays. At best you might get a refund for your ticket. Tough luck if you had any other losses. This has now changed due to user pressure.

In the software world we have built a story that software is special. We say that it is complex so usual rules cannot apply. We see this story in the success of very limited liability for software errors.

Planes and trains also tried to avoid paying. They said delays were caused by acts of nature beyond their control. This worked for a while, but no longer. Why should software be special? Why should ISVs be able to get away with excluding risks that other industries can only dream about?

Cracks in the walls of (no) software liability

We all spend time and money working around security holes in our software. Why have these holes not been fixed? As the respected security expert Bruce Schneier explained back in 2004, ISVs have no financial reason to do so. The user pays the cost of the holes, not them!

Like planes and trains and their acts of nature, ISVs have been good at avoiding liability. This will not be so for ever. Many people no longer see software as special. For them it has always existing, like electricity. ISVs will have more trouble getting these people to sign old contract terms. They rightly demand the same rights for software as for a fridge or a TV.

If classic ISVs must pay real cash to fix things when they go wrong, it will be hard for SaaS ISVs to avoid the same rules. It should not change user’s rights if software is on-premise or SaaS.

Is SaaS more complex than an airline?

Like in bad old days or planes and trains, in these early SaaS days 37signals, Fog Creek and others can get away with no or weak SLAs. This will not last. As customers switch to SaaS they will expect to get the service they are paying for. If the service is not provided then their costs must be paid–in full.

The user’s goal with the SLA is not to make money from downtime. The goal of a real, tough and fair SLA is to make sure that you invest: You must invest time, money and effort to ensure that the risk and impact of downtime is very low. The cost of the SLA is the stick to beat you with.

An airline cannot control the weather. You cannot control whether a fibre optic cable in the Middle East breaks. Both can assume, though, this might happen. You can plan for this and include it in your SLA cost plans.

Having to pay real cash focuses attention

Your B2B SaaS customers that pay you real money will expect a real, tough and fair SLA. This is not to say all subscribers expect or need 24×7 access. For each user downtime in certain hours, days or months are a higher risk than others. Your SLA will need to take this into account.

If you have to pay real cash for downtime then you will do what it takes to avoid downtime. Problems will always occur and you must handle them in the right way. You can limit the risk of a large cash payout with insurance.

The first thing SaaS prospects will look at is your SLA. This must be very open and clear on your website for all to see. The terms must be clear and say what cash payments are made for downtime.

Comparing your SLA with those of other SaaS ISVs will become a key part of the SaaS purchase choice. You will not get away with hiding your SLA. You need to shout about how good your SLA is, not hide it! It cannot be a secret.

You need a real, tough and fair SLA for SaaS

You cannot plan for “Black Swan” events such as 3 meteorites hitting your 3 data centres at the same time. You can plan for fibre optic cable breaks. Assume you must pay real cash for downtime and your SaaS business model will be more solid.

Make your real, tough and fair SLA the core of your SaaS business model. Plan that downtime will cost you a lot of real cash. Do this and you will be a big step ahead of your competitors.

37Signals and others can win at the moment with no SLA. This will not last for ever. Don’t build your SaaS business model on the false hope you can get away with it as well.

It did not work for planes and trains, and it will not work for you either.