Can your ISV survive paying real cash for SaaS 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 24x7 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 Web site 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 centers 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.