Commentary

Mary Hayes Weier
 

A 'Bill Of Rights' For SaaS Customers

Analyst R "Ray" Wang is a tireless and well-respected customer advocate in the world of enterprise software. Now Wang is bringing his advocacy over to the SaaS side with his recently published "Customer Bill of Rights" for SaaS. I share with you some of the highlights.

Analyst R "Ray" Wang is a tireless and well-respected customer advocate in the world of enterprise software. Now Wang is bringing his advocacy over to the SaaS side with his recently published "Customer Bill of Rights" for SaaS. I share with you some of the highlights.Wang points to three things that separate SaaS deals from on-premises software: software license rights, vendor product investment, and client remedies for breaches in service level agreements. He addresses these topics with the types of questions that customers should be asking their SaaS vendors and themselves.

Regarding license rights, Wang notes that SaaS vendors typically own the core code, and customers own the data. "What happens if the vendor goes out of business? What happens when the vendor is acquired by a competitor?" he asks. In other words, don't do a SaaS deal unless you've figured out your exit strategy.


More Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

On the vendor investment front, Wang notes that SaaS vendors are doing a good job of updating and improving their products, often several times a year, and customers instantly get those improvements because it is, after all, a hosted online software service. But could this change? "Will vendors attempt to charge for 'new' modules that represent extensions of existing capability?" And regarding SLAs, when systems go down, "What are fair remedies? How much liability will be provided by the vendor?"

Wang also stresses that customers demand "timely and meaningful interactions." Vendors should respond quickly to service requests, bug fixes, and help desk issues. They should let customers know right away of changes in product road maps, pricing or support.

While recent outages prove SaaS isn't perfect, customers should demand quality. "This includes full disclosure of known and potential defects that relate to performance, availability, bugs, integration, and partner solution compatibility," Wang writes. "Penalties for breaches should reflect the business impact of a disruption or inability to access a capability promised to a customer."

And to ensure a vendor is viable, customers should get "access on a periodic basis to the vendor's financial statements along with insight into the vendor's operational performance in areas such as incident and problem management, security management, and business continuity planning."

Wow. And that's just a few blurbs from the first eight pages of an impressive 15-page document designed for CIOs, IT, and business managers who want to break from the old guard of on-premises software, and stake ground in the new land of SaaS. Let freedom reign.

Still, reading this document made me wonder, at one point does the new guard start looking like the old guard? In other words, I doubt you'd get Google to comply with much of what's in the "Customer Bill of Rights: Software-as-a-Service," especially for small-and-midsize customers who aren't bringing in that much revenue. I think Google would more likely say, "You're only paying $4 a month per user for email-are you kidding me?"

Kudos to Wang on this document, because customers need to be thinking of their rights going into SaaS deals. But they also have to remember that the more they ask for, the more it might start looking like a traditional software deal instead of that really inexpensive monthly software service, with few strings attaching either party. -


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links