Research Report: Customer Bill of Rights – Software-as-a Service

Published on October 12, 2009 by R "Ray" Wang

Connect.  Collaborate.  Innovate.
Welcome to the first of many Altimeter Group research reports.  Before you dive deep into the Customer Bill of Rights: Software-as-a-Service report, we wanted to share with you a bit about the research process and how we work within the community.

  • Connect.  We strive to bring new people together and share our knowledge.  Knowledge has no value unless others can put it to use.
  • Collaborate.  We believe in open collaboration with the market and ecosystem of thought leaders, influencers, solution providers, and implementation experts.  In collaboration do we foster new relationships and opportunities to solve client problems.
  • Innovate.  We are thinking about what’s next.  SaaS deployments and web-based solutions represent the future and we’ll be looking for the next set of innovations.

Customer Bill of Rights – Software-as-a Service

Enjoy this report. It’s been placed in Scribd for shared use.

AG Customer Bill of Rights – SaaS – Live

Use. Share. Remix.
Creative Commons License
Customer Bill of Rights: Software as a Service by R “Ray” Wang is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Based on a work at blog.softwareinsider.org.
Permissions beyond the scope of this license may be available at http://blog.softwareinsider.org.

Continue The Discussion On Linked IN

We’ve crepic_logo_119x32ated a group that you can join now that will carry the conversation further.  Sign up now and stay tuned for when the report goes out.  Look for more Bill of Rights to come. Customer Bill of Rights

Your POV.

Want to be part of the collaborative research process?  Got ideas for topics that should be reports?  Feel free to post your comments here or send me an email at rwang0 at gmail dot com or r at softwareinsider dot org.

Copyright © 2009 R Wang. All rights reserved.

  • [...] Analyst Ray Wang has called for new levels of transparency from vendors in its manifesto – the Saa….  Wang states that customers should be informed of known functional bugs, potential security risks, recurring performance issues and service availability problems.  He states that customers have a right to know the highlights of financial statements, locations of data centers and compliance with government regulations.  Product managers will need to consider what level of transparency is necessary to ensure that offerings are competitive in the marketplace. [...]

  • [...] What SaaS/on-demand/cloud (anyone remember David Terrar getting annoyed at me about this conflation?) have done is to simplify delivery but exposed the need for due diligence in a way that on-premise has masked. When your data is held elsewhere, questions get raised. Message to vendors: get over it and deal with the problems. In the meantime, check this as a prime example of what I mean by making your life difficult. Read and implement the SaaS Customer Bill of Rights. [...]

  • [...] In my opinion there are lots of advantages for software vendor those who deliver both on-premise and SaaS. They offer unique value proposition of transition from one to another. You might ask – what is the need for a transition? There are many drivers for transition– Enterprise maturity, satisfaction issues, control, etc… There are lots of examples where customer moved from SaaS to their own private cloud and vice versa. If I were a customer, my bill of rights includes transition + Ray Wang’s bill of rights. [...]

  • [...] VMware’s acquisition of SpringSource may have seemed strange in October 2009.  However, SpringSource brings an Eclipse-based IDE, Apache, and Tomcat tools to the table.  vSphere delivers the ability to migrate workloads and manage VM’s.  The Hyperic acquisition provides many key PaaS components.   Force.com will deliver the applications, analytics, search, collaboration, and a solid base of applications customers.  The result — customers can now take advantage of True SaaS solutions and custom build in Java PaaS side by side.  Meanwhile, Salesforce.com can shed the APEX code of the SaaS 1.0 world and moves to an open standard – enterprise Java.   In essence,  organizations can now have their cake and eat it as both VMware and Salesforce.com move to the next generation of Cloud.  While there are many benefits of PaaS, customers moving to VMforce should seek provisions in The Customer Bill of Rights: SaaS. [...]

  • Ray – an excellent piece of work with clear, practical guidelines.

    Do you have any examples of data escrow arrangements used by SaaS vendors? I am thinking of the right to access the data in the event of a dispute.

  • Ray,

    Nicely done! In addition to identifying commonly accepted best practices for all software transactions, the report includes many insights that address risks unique to SaaS deployments. After reading the report, I have several observations that I’d like to share with the community.

    1. In section 5, the report states that SaaS licenses should allow customers to assign rights to their affiliates or successors in interest. License restrictions often include limitations like “personal,” “non-transferable” and “internal use only” without the right to sub license. These limitations are at odds with how enterprise users typically use their software. The license grant clauses for SaaS should not use these “gotcha” limitations, and should more clearly lay out use permissions and limitations in plain English. For example, internal use only limits may prohibit a customer from allowing its contractors, business partners, affiliates and outsource vendor personnel (acting on the enterprise’s behalf) from accessing and using the licensed software. And in the remote worker global enterprise environment, SaaS use rights that aren’t “worldwide” aren’t good enough.

    2. Since an essential allure of SaaS for enterprise users is on-demand consumption, service agreements should not lock customers in to long term contracts. In my experience, many SaaS vendors have not fully embraced the “buy-only-what-you-need” pricing model. They really do want, and more importantly, contract around perpetual use consumption and revenue models. As the report points out, revenue recognition and resulting minimum usage limits set by vendors are reasonable pricing mechanisms. Collared pricing bands and volume discounts are all reasonable mechanisms to encourage customers to buy more for longer periods. But multi-year contracts that unduly penalize customers when they decide to walk away — because, for example, the SaaS vendor stops innovating or the product simply no longer satisfies the customer’s business requirements — should be rejected. Instead, customers should be allowed, for their convenience, to walk away from a SaaS deal by providing reasonable advance notice to their vendors and paying MODEST termination fees. The “art” is, of course, negotiating what modest means in a given context. It is, however, clear that termination fees that require customers to pay the full amount of the usage fees over the remaining portion of multi-year contract terms are NOT modest. By the way, customers should NEVER have to pay termination fees if they walk away due to non-performance of the service or breach of the contract by the vendor.

    3. In section 2, the report states that proposals and other sales-cycle documents should be incorporated in final contracts. As an enterprise buyer’s lawyer, I’ve tried this occasionally and it is usually unworkable. Proposal documents and marketing material often lack sufficient clarity and “what if” language to rely on when trying to interpret the real understanding of the parties. Moreover, the parties may have negotiated trade offs during the sourcing process that result in conflicts between the early stage sales documents and other contract clauses, statements of work responsibilities and service levels. And for better or worse, sales puffery makes its way into these early stage vendor communications. To be clear, vendors should absolutely be required to stand behind the promises they make to win the business. In my view, however, these pre-contract promises and sales material have to be converted to meaningful contract language by experienced professionals for them to serve as useful guides to the parties during informal and formal dispute resolution activities, and to avoid introducing inconsistencies between the various parts of the agreement.

    4. In the SaaS context, unlike on-prem software, vendors possess the keys and the lock box containing the application and the client data. This special relationship of trust should obligate SaaS vendors to exercise a very high duty of care – a level of care that is not necessarily required of other IT product vendors where the client has the benefit of possession. In addition to on-going access to client data as you mention in the report, I also advocate that, as a general rule, SaaS vendors should be prohibited from denying access to client data and the SaaS application as a means of vendor self-help, even in the face of alleged violations of the contracts by their customers. This is often controversial in negotiations and exceptions to the general rule as it applies to access to the application (NEVER the data) are appropriate (i.e., prolonged non-payment of material amounts due and circumstances where ongoing access to the application would cause the vendor or its other customers to suffer irreparable harm). Nevertheless, business continuity and quiet enjoyment are fundamental assurances SaaS vendors should offer enterprise users that plan to use SaaS for important (not just mission critical) business processes.

    That’s my POV . . .

    -Marc

  • Ray, I think you laid out a very strong framework, but a couple of areas that you may want to revisit:

    The first point is indirectly related to the BoR. You mention up front that “More Frequent Cycles of Innovation” is one of the key benefits of adopting a SaaS model. It may seem like semantics, but I don’t think that Innovation is the right word to use. What you’re primarily referring to is a more rapid release cycle, which primarily addresses bug fixes and modest feature enhancements, but in my mind that is far from “Big I” Innovation. I think that many vendors like to position sustaining engineering activities as innovation, but in my opinion it usually isn’t (see more on my perspective on my post “New Features Masquerade as Innovation” .

    But I also want to pick up on Subraya’s point on Disaster Recovery and the impact on business continuity. I would suggest that you consider some guidelines on what’s acceptable. Most people think of RPO/RTO (recovery point and recovery time), but that doesn’t really contemplate LOST data and LOST transactions that occur between the actual DR event an the recovery, even if SLA’s are met.

    On a related point, we have talked about the role of SaaS escrow in the past, but it doesn’t account for the fact that while you may be able to get your data (and meta data), and perhaps access to the code itself, you still lack the underlying infrastructure to run it. There’s a good discussion on this on a blog post a month ago from Frank Scavo entitled “SaaS contingency plans need more than software escrow”, with good comments from Jeff Gordon (http://twitter.com/negot8or). Further, the cost to run it as a single instance may be prohibitive since the underlying premise to a multi-tenant deployment is that the economics work only when hosting many, many customers.

    My 2 cents.

  • Ray,
    Fantastic Report. I had done a bunch of work in this area and captured some of the things customers need to keep in mind while engaging with a SaaS vendor in my three part series SaaS Buyer’s Guide http://www.prudentcloud.com/saas/saas-buyers-guide-choosing-the-right-vendor-20022009/.

    One thing I did not see was around Disaster Recovery, Governance areas. I have found that customers do not do the necessary upfront work around ensuring DR is in place. Governance issues like how their data will be secured and preventive measures taken to handle penetration etc are also areas that do not get the necessary focus during RFP cycles.

    Would love to know what your findings were around Service Credits etc for loss of service and the resulting impact on business.

    Subraya Mallya

  • This Bill of Rights turned out very well. We are very glad to have been able to contribute to it. This paper creates a nice even playing field for vendors and clients alike. Having a shared general expectation will only improve communication and further understanding of SaaS in the market. We are looking forward to seeing this gain traction in the space.

    - Matt

  • [...] colleague along with Jeremiah Owyang, a long time enthusiast for social networking, have produced a SaaS Customer Bill of Rights – see the scribd document above produced under their business moniker Altimeter Group. This [...]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Related Posts