Customer Bill of Rights - Software-as-a Service. In contrast to the closed-wall, not-invented-here traditional style of industry analyst firms, R actually solicited feedback from dozens of thought leaders outside of his firm as well as numerous firms themselves. I was honored to be asked to participate with many individuals far smarter than me and think it turned out well. My specific feedback is reproduced below so you can see the issues that I thought were particularly relevant.
1. "Issues related to software license rights. Software vendor owns the code. Licensee’s own the data. In true multi-tenancy, code cannot be client modified because a change for one client perpetuates to all clients in a multi-tenant environment. Clients must assess exit strategies. What happens if the vendor goes out of business? Is acquired by a competitor? What do you do with the data? How do you prevent lock-in?"
There are two things missing here that need to be fleshed out. The first is not the data ownership per se, but the semantics of the data. Getting flat file dumps out of the SaaS system is not valuable without the business rules that govern the data structures within which the data is stored. At Siebel, customers could purchase (under NDA) the data models and logical models of the system. I believe SaaS customers should have the same right.
The second issue that needs to be teased out that I've seen nobody address is process ownership. As you know all too well, there are core and context enterprise processes that are digitized in the customer's software through their specific configuration. In the case of highly differentiated processes, the customer should own the intellectual property of their differentiating process as embodied in the SaaS vendors software configuration. This can include the process models (notated in BPMN or some other standards-based representation) but also the specific instances of the process itself. If I were a customer, I would be extremely nervous if my vendor could take the embodiment of my enterprise's uniquely differentiated processes and offer it to someone else on the same multi-tenant infrastructure (especially a competitor), and that possibility is greatly increased in the SaaS environment.
2. "Include an entire agreement clause. Prospects and clients should ask for this right to ensure that demos, proposals, and promises made during the selection process are included in the final contract. Vendors should expect clients to include documentation as exhibits in contracts."
This has always been a gray area in software negotiations. On-premise vendors make all kinds of promises that they will never document because it would cause revenue deferral if caught. I'm concerned about the serious revenue recognition risk that vendors place themselves under when they make promises they can not keep. I think a broader point (not for this document necessarily) is that the entire revenue recognition process for SaaS companies needs to be revisited for these and many other issues related to the customer lifecycle.
3. "Perform due diligence on a vendor. Prospects should be able to examine a SaaS vendor’s financial viability, security risks, and legal liability. Key areas should include financial performance, legal risks, management team background, customer lists, and SAS 70 compliance."
The SAS 70 issue needs to be teased apart further. I believe customers deserve the right to have regular audits conducted of the vendor data center for their own purposes as well as hiring third-party auditors to do so. Some vendors refuse to share the results of their SAS 70 certification process other than validating that they have the certification, and this not acceptable to many customers for certain business processes (Hire to Retire) in certain industries (Pharma) and certain geographies (EMEA).
Finally, a general comment: I appreciate the individual tenets described under the SaaS Ownership Experience Spans a Five-Phased Lifecycle. But for each individual tenet "professional customer relations, timely and meaningful interactions" etc., I kept asking agreeing with the principle but then immediately asking myself "how should this be measured and what's the appropriate benchmark?" This should be no surprised given my background and expertise, but I think it's a critical point. Examples: Is a roadmap update every 6 months "timely"? What "format of remuneration" is acceptable without putting undue burden on both parties? I expect that much of this information is not available given the infancy of the industry, but this would be a very valuable area of research for Altimeter or others in the ecosystem to pursue.
You can see the full document here:
AG Customer Bill of Rights - SaaS - Live
Other excellent coverage of this topic follows:
A 'Bill Of Rights' For SaaS Customers
Posts
No comments:
Post a Comment