Time for a SaaS code of conduct

Time for a SaaS code of conduct

Summary: It may seem unfair that SaaS providers get bad publicity whenever their systems fail - on-premise software is always going down without hitting the headlines. But people expect better from SaaS. The industry needs its own 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?

Topics: Outage, CXO, Cloud, Collaboration, Emerging Tech, IT Employment

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • It has been "emerging" ever since we used green terminals.

    Always encourage local backups of data. Never assume you can always recover. Never encourage your users to put all of their eggs in one basket. Always make offline access available.

    "SaaS is still emerging technology and we don?t know all the answers yet. Things will go wrong."

    It has been "emerging" ever since we used green terminals to connect to mainframes. The problem isn't that we don't have answers - the problem is that we are so bent on making this model work a certain way we don't realize how flawed that certain way is.

    I'm sorry. Dumb terminals with only enough power to merely display an image and take some input are forever gone. Our computers will [b]always[/b] have, use, and need a lot of spare local processing power and memory, and will [b]always[/b] need to be able to access resources while offline.

    It's not going away. It's a fact of life. Things go wrong, stuff fails. Network connections aren't reliable, and never will be. Anybody who thinks we will ever move to 100% cloud computing is living in a fantasy Utopian world.
    • Likewise ...

      ... anybody who imagines we will remain 100% on the desktop/on-premise is living in the Dark Ages.

      There are a minority of people who simply can't abide the idea of being dependent on a network. But to describe the model as irredeemably flawed is bizarre. Do you have similar views about power and water?

      As for encouraging local backups of data, isn't that opening up a horrendous data security risk?
      phil wainewright
      • Sounds exactly like SaaS

        [i]Microsoft only warranties the CD the software comes on. There?s no guarantee the software itself will actually work.[/i]

        all the agreements that are signed when dealing with anything SaaS, basicly state that even though they are being paid, they are not responsible for any loss of any type.

        At least I can return the software if it does not work, or I can pass it along to someone else who can make it work to recoupe the cost.

        What do you have after your SaaS vendors goes away?
  • Seems to be a theme developing here...


    Right on! I'm definitely on board with this.

    In fact, your code of conduct adds nicely to a Cloud Computing Bill of Rights I put forth a few weeks ago.




    I also heard a lot of support for the 30 days notice termination clause at Cloud Summit Executive earlier in the week.


    Your concept of "insurance" for vendor failure is a significant enhancement to these concepts, and one I think deserves more vetting. You've got my mind racing with that one.

    Excellent post, and thanks for your thought leadership here.

    • SaaS Escrow

      SaaS Escrows provide for this type of insurance or succession planning. Object Code and Data are protected in escrow and released on demand following an extended outage (~8hrs or more). Part of the planning is determining who would host the application upon release. DR testing is critical to make sure the plan works.
  • Standards of Service Delivery

    Applause for raising expectations of service quality. What's the point of a service agreement that merely says, "If it doesn't work, you don't pay"? If the user is merely breaking even on the net value of the service, why bother using it at all?
    What users want is transparency and consistency of actual service performance: one possible manifesto of service buyer expectations is offered at http://www.salesforce.com/assets/pdf/datasheets/SevenStandards.pdf
  • RE: Time for a SaaS code of conduct

    Phil, I couldn't agree more. As soon as one pays anything for a service, one has a right to know the terms under which that service will be delivered. At OpSource, our SaaS ISV customers can offer their end-users the same SLA we provide to them.
  • RE: Time for a SaaS code of conduct

    Hi Phil,

    Lots of good stuff in here. The topic of best practices for SaaS SLAs was a major section of an IBM SaaS conference this week - Ken Harris, the CIO of Shaklee, who has 10 SaaS applications, presented his recommendations for negotiating SLAs with SaaS vendors.

    I blogged about it yesterday on my <a href="http://intacct.blogspot.com"> SaaS 2.0 blog.</a>

    Ken had several things he looks for in SaaS SLAs that would be nice to add to your list, and we at Intacct add a few more in our <a href="http://us.intacct.com/downloads/08datasheets/DS_Buy_with_Confidence.pdf">Buy with Confidence</a> SLA.
  • RE: Time for a SaaS code of conduct

    Confidentiality and trust. See my post Laundry as Intelligence http://rvsoapbox.blogspot.com/2008/10/laundry-as-intelligence.html
  • Yes, need a TrustE for SaaS or something similar

    This would save a lot of time for vendors and strongly benefit customers. At EchoSign we've aped trust.salesforce.com with trust.echosign.com, and attempted to cobble together all the above through a combination of internal and third party services.

    Having a clear standard would be helpful all around.
    • Great Minds...

      Jason, couldn't agree more and I recently wrote an post calling for a SaaS certification program called "We need a TRUSTe for SaaS apps": http://glasseyonsaas.typepad.com/glassey_on_saas/2008/09/we-need-a-truste-for-saas-apps.html

      The code of Conduct could also be a part of this.

      Alex Glassey
  • RE: Time for a SaaS code of conduct

    Perhaps I am too much of a libertarian, but while I agree with the thrust of your arguments, I am not sure that we need yet another industry body to address issues that in my opinion are better left to individual customers and individual firms.

    Your analogy to electricity is apt. We do not have SLA's regarding the non interruptibility of electricity, though to be fair, we have a longer operating history and hence a set of expectations based upon real experience. I have been responsible for installing expensive battery and generator backups precisely because there is no enforceable SLA's in this industry. My point being we deal with this fact in other utility industries, so why should SaaS be special.

    That said, I think the bulk of your argument is correct. The open publication of metrics helps substitute for lack of operating history and is a basis for forming a trust relationship with the customer.

    Further your comments regarding a substitute web site for information flow etc are great marketing imperatives for any company that is serious about attracting and retaining enterprise customers.

    My only difference is that I think the companies that adopt such tactics will survive and the rest won't and so don't bother with Yet Another Industry Body
  • RE: Time for a SaaS code of conduct

    Some good ideas, Phil, and ones that some mature SaaS businesses are already addressing. I have looked at each of your five points and reckon that, with the benefit of eight years of delivering SaaS in a technologically conservative and very risk-averse sector (construction), BIW and its customers have already got to grips with at least four out of the five points.

    See my post at http://www.extranetevolution.com/extranet_evolution/2008/10/a-saas-code-of-conduct.html

    I am not sure having an industry body set some standards is attractive. Surely, customers will vote with their feet and migrate towards SaaS businesses that do deliver high levels of resilience, reliability and risk management.

    Regards, Paul
    Paul Wilkinson
  • RE: Time for a SaaS code of conduct

    Hi Phil,

    Great post, though apologies for the late reply. As CEO of a SaaS company, I can say you've nailed it in terms of what customers should and do expect. I think there is definitely opportunity for third parties to define and validate compliance with these standards. I also think there is an opportunity for startups or open source groups to create technology (e.g., SaaS-focused monitoring) that could be shared between vendors and used to verify compliance in an automated way (in the way salesforce.com does today).

    Like most vendors, we work hard to comply with the points you mentioned and I'm sure we'd benefit from not reinventing the wheel where possible.

    -Nick Mehta
    CEO, LiveOffice (www.liveoffice.com)
  • RE: Time for a SaaS code of conduct

    I actually put together my own "Online users bill of rights" back in August that has a lot of the same elements:

    1. Files, documents, or anything else that the user has created and saved online cannot be removed or be made inaccessible without a 30 day advanced notice.

    2. The service must be accessible 95% of the time each month. Specifically, users must be able to access their data, be able to delete or retrieve existing data, with availability of at least 95% in each month long period. It is also highly encouraged to make public a tighter uptime commitment, including the consequences of not meeting that commitment.

    3. During downtime events, the service must make a best effort to provide status updates, estimates as to when service will be restored, and an explanation of what led to the downtime after the event. It is also highly encouraged to make known a central location to distribute this information.

    4. The service will provide a performance SLA describing the average page load time they expect to see, and the consequences of not meeting that average in any given month. This is especially important for API's and services like AWS.

    5. The service must give at least 30 days notice prior to making any "major" changes in the functionality or level of service provided up to that point (including API interfaces). It is also highly encouraged to involve the users in the decision making process prior these changes.