Forrester’s “An Enterprise Software Licensee’s Bill Of Rights”
My former colleague at Forrester, Ray Wang, just published version 2 of his An Enterprise Software Licensee’s Bill Of Rights, based on interviews with 71 enterprise software vendors and an online poll of 101 end user companies. Ray has become one of the most quoted analysts on the globe on issues related to licensing and software maintenance, and with the wide readership this report will receive, I thought it would be worth mentioning some of the implications to service and support.
Ray has been very outspoken in the past about the cost vs. value received from maintenance contracts (check out his ‘five tips to lower software maintenance fees‘ article), so I was a bit apprehensive when I saw the new report. But I find the Bill of Rights to be a very rational and balanced take on lowering risk and ensuring value for both vendors and users. It is especially interesting to see some “Web 2.0” thinking entering the picture, and some of the Rights will definitely raise the hackles of some very “Web 1.0” companies.
Here are some highlights, along with my take-aways:
- Full disclosure of “in the box” functionality. Vendors should provide disclosures of the standard (“vanilla”) functionality a customer can expect upon go-live. In addition, “in the box” capabilities should be classified as “no modifications required”, “minor configuration”, and “major configuration”. Custom capabilities not included in a standard deployment should be called out.
This single issue may explain the high failure rate for CRM software. It continues to amaze me how companies select software based on RFPs that ask about functionality in such a way that vendors can always answer ‘yes.’ As I always say, ask for customer references on all key functionality. Oh, the dozens–if not hundreds–of times I’ve heard complaints that functionality a company assumed was in the product turned out to be ‘demo’ code.
If your company has overzealous sales and marketing teams, this one item can cause lots of headaches for service and support. A common example: A new customer explodes when presented with a quote from PS to implement a set of customer features the customer thought was “out of box.” Or tech support takes a hit to customer satisfaction when the customer calls trying to configure something to work like it did in the demo–only to find out it can’t.
- Pay for actual usage. Many contracts contain provisions for price protection for additional licenses. However, few vendors offer clients the opportunity to remove unused software or shelfware. Vendors need to allow the customer to adjust overall counts of license metrics on a defined and regular basis. Users should retain the right to return for full credit any software that is not used in the implementation and receive credit for any licenses above and beyond the number of users actually using the product in some fixed time period that has been agreed to by the vendor based on how long an implementation should take.
I understand, and agree, with the spirit of this Right, but think the reality of wanting credit for unused software is a very muddy business. Again, some fault may go to overzealous sales reps who sell an account more than they can possibly absorb, but if customers are carefully checking references about implementation times, there shouldn’t be too many surprises. For support management, this problem will present itself when maintenance renewals come up, and a customer refuses to pay maintenance for unused portions of software. If this happens to you, fight to see that the sales commission is also deducted–retroactively. (Yes, I do live in a fantasy world, but if bad sales reps were financially penalized more often the problem would stop.)
- Permit customers to freely share modifications with one another. Licensees should have the ability to freely share software modifications with one another as a community of users. Should the software vendor wish to incorporate such modifications into the standard software, the author of the functionality should be eligible for a royalty or other equivalent benefits.
This is my favorite part of the report, and where my Web 2.0 reference earlier on comes from. In light of SaaS vendors doing Idea Storming, and open source vendors allowing customers to contribute to code, this Right makes perfect sense. But my guess is some more traditional software vendors will see this as a loss to services revenue. I’ll be interested to hear if this model becomes reality for on premise vendors.
Ray includes a section specifically on Maintenance, and for the most part I don’t think these Rights will cause too much heartburn for service and support. One problem area may be allowing customers to unbundle service options and pick only those that they want. An example cited is, “a customer could unbundle support services from upgrade privileges rather than pay for upgrades that may not be used, or could pay for support calls as needed.” It would be challenging to identify piece-mill pricing for every line item in a support contract, and I dread to think how many cycles will be wasted if customers push this to the extreme. I also think it may be a false economy, with customers cutting things out of the maintenance agreement to save costs, then hitting a big problem later on and demanding support they refused to pay for at the onset.
I would encourage you to read this report–you can be sure your customers will before their next maintenance renewal! Let me know if you have any comments or questions; I can pass along questions to Ray if you have them. And as always, thanks for reading!