Time for a SaaS code of conduct

Incidents like the latest Gmail outage do the SaaS industry no end of harm. Yes, of course it's unfair that Google gets public brickbats whenever its $50-per-year application goes down for a few hours, when Microsoft's $000's-in-license-and-overhead Exchange package is often out of action — for days on end, all over the world — without making headlines anywhere. As Information Week's Eric Zeman writes:

"In the decade that I relied on Microsoft Exchange to deliver my corporate e-mail, I experienced what probably amounts to months of outages. I distinctly remember not being able to get into my e-mail for one full week once due to problems with an Exchange e-mail server. In my experience, Gmail has been far more reliable."

But the point is that customers realize they're on their own when they install Microsoft software. Heck, Microsoft only warranties the CD the software comes on. There's no guarantee the software itself will actually work.

It's a different matter for cloud providers. Their customers subscribe to a working service. There's none of this buck-passing about whether the customer installed it right. They log in, and it just works. Which engenders completely different expectations when it fails.

Many providers — and Google continues to fall into this error — make the assumption that because their infrastructure is so superior:

1. it won't fall over
2. if it does, users won't mind because it happens so rarely

Wrong and wrong. For one thing, it's no good pretending these outages and brownouts won't happen. SaaS is still emerging technology and we don't know all the answers yet. Things will go wrong.

Secondly, users will mind because the provider, in its naivety and arrogance, has set their expectations too high. It has lulled them into a false sense of security and then failed to keep them properly informed or reassured once their illusions are punctured.

What the industry needs to put this right is a code of conduct to which vendors should be able to get certified, perhaps at a number of different levels (like hotel star ratings) so that customers know what they're signing up for and have their expectations set correctly. There may well be some applications where customers won't want to pay for five-nines uptime. They'll prefer to pay a lower cost and put up with the occasional outage. They will however still want to know exactly what they are getting for their money, and be kept informed when things go wrong.

Here's my suggested code of conduct, adapted from an original that I first suggested back in December 2005.

• Spell out exactly what the contract does and doesn't deliver. This includes monthly uptime commitments and time-to-resolve targets. Customers have a right to know what service levels they're signing up for — and providers, who know a lot more about what can go wrong than prospective customers, have a duty to spell out what's not included.
• Give customers a clear plan for when things do go wrong. If the service is suddenly inaccessible, it helps a lot to know there's another website users can go to for news, or that they'll receive an email within the hour telling them what's going on, or that the helpdesk is guaranteed to answer their phone call in less than five minutes — provided, of course, those procedures are robust enough to still work when all hell breaks loose at the provider's support center!
• Report live service level metrics. The kind of dashboard that Salesforce.com and Amazon.com have adopted should be the baseline industry standard. I'm constantly surprised that it still isn't. I would go further and say that customers should be able to view the same real-time information about service levels that the provider's own operations staff get to see. The information should also be available as a data feed that customers can plug into their own IT management systems.
• Have a customer insurance plan in place. I'm convinced the industry needs a scheme that's as robust as the banking system's deposit guarantees. Customers should know that even if their provider unexpectly goes out of business, there's a properly funded plan in place that allows for an orderly transfer of their data and processes to a new home. Let's take that worry off the table.
• Let customers leave whenever they like. On-demand providers should go out of their way to make it as easy as possible for customers to move or back up their data elsewhere (configuration data too, if applicable). And the customer should have the right to end a contract and move elsewhere on 30 days' notice any time their confidence in the provider is undermined. Paradoxically, a guarantee like that inspires customer loyalty because it shows the provider always has to work to earn the customer's trust.

Let me know via TalkBack if you think there's anything missing here — and if such a code existed, would it would make you more likely to use a SaaS provider?