CMS Pricing
Over the years, I have had a number of really interesting discussions about software pricing with both vendors and customers. Pricing software (be it a license fee, an annual subscription price, or whatever other source of revenue) is a complex problem on both sides of the transaction. Vendors are always trying to tweak their pricing to increase sales and revenue. Customers are constantly trying to figure out what prices mean in terms of value and overall costs. The results of these efforts are that prices overly complicated and never seem fair.
One of the best explanations of software economics is Joel Spolsky's epic article Camels and Rubber Duckies. To quote:
One of the biggest questions you're going to be asking now is, "How much should I charge for my software?" When you ask the experts they don't seem to know. Pricing is a deep, dark mystery, they tell you. The biggest mistake software companies make is charging too little, so they don't get enough income, and they have to go out of business. An even bigger mistake, yes, even bigger than the biggest mistake, is charging too much, so they don't get enough customers, and they have to go out of business.
Joel goes on to talk about microeconomic theory of demand and supply and discusses how software is tricky because there is no intrinsic limit on supply. Which brings him to the classic Joel conclusion.
Take my advice, offered about 20 pages back: charge $0.05 for your software. Unless it does bug tracking, in which case the correct price is $30,000,000. Thank you for your time, and I apologize for leaving you even less able to price software than you were when you started reading this.
As great as Joel's article is, it only focuses on keeping the financials of a software business in the black. The article ignores another important aspect for software vendors: making customers successful. Sure, making a software sale is great. But to be viable in the long term, a software vendor needs to create value for the customer and then capture a reasonable portion of that value (surplus in microeconomic parlance). A good pricing model will charge customers in proportion to the amount of value they get from the software, but measuring value is not easy in content management software. Different pricing models use different data as proxy measures of value. The problem is that these proxies are not an exact representation of value and customers have an incentive to manipulate them to lower the cost of the software. To make matters worse, the behavior that prices encourage is often sub-optimal and risky. Customers consciously underuse or misuse products in order to stay in a lower pricing tier. This undermines the goal of making a customer successful.
Let's dig a little deeper into the unintended consequences of content management software pricing models. In the world of content management, there are essentially three ways software is priced: by named users, by servers (or CPUs) or concurrent users, and by volume of content. All of these models try to get customers who use the software more to pay more. This enables a CMS vendor to sell into small departments as well as make large enterprise-level deals. But all of these models can encourage bad behavior. Lets look into each one.
- By named users. This seems like a great model. When a customer has lots of users on a system, it means it is leveraging the product for high value things like distributed authoring. The product likely has become a critical part of many jobs — making it an important part of the operational infrastructure. Here the value is that lots of people are able to edit content. However, I frequently see this model drive customers to do foolish things like having shared accounts on the system (that is, 10 different people log in as a user named "User1"). I have also seen customers have dedicated content entry people to save on user accounts. If you don't have a user account, you just mail your content to someone who does. Both of these behaviors undermine all sorts of functionality like workflow and auditing. Any sense of accountability is gone.
- By servers or concurrent users. I lump these two models together because they both attempt to tap into the intensity of usage. This is slightly better than the first option (named users) because it does not penalize customers who have lots of occasional users. Customers with more activity pay more than customers who are more static. Here the value is the amount of management activity the software enables. If the customer's business depends on actively managing its content, the CMS is creating a lot of value. But these models can encourage users to under-power their implementations. Customers will low-ball their infrastructure. When customer buys too few CPU licenses, the system will be slow (what software vendor wants a reputation for being slow?) or there will no fail-over for upgrades or crashes (what software vendor wants a reputation for being unstable?). When customers have not bought enough concurrent user licenses, I have seen employees repeatedly trying to log in to snatch up a session when one comes available. What a waste of time!
- By content volume. While the first two models are common to all types of enterprise software, pricing by volume of content may be unique to content management software. I only know of a few vendors that sell this way but, frankly, I think this may be the best of the three options. Companies with more content derive more value from their CMS — at least they should. If a customer has a large volume of low-value content, maybe that is a problem that should be addressed for other reasons. Additional software fees are trivial compared to the cost of keeping around unneeded content: redundancy, out of date content, and poor findability all add up to great losses in efficiency — a customer will lose more efficiency to these issues than is gained by having the CMS. Bob Boiko's book Laughing at the CIO; A Parable and Prescription for IT Leadership
gives excellent strategies for thinking about the value of information. If high software costs force a better content management strategy, great! However, things don't always work out that way. I have even seen customers manage content outside of the content management system (like on a file system or in some other CMS) to avoid having it count against quota. I have also seen customers model their content to be coarser-grained to reduce the number of items. For example, rather than create a content item for every glossary term (which would increase reusability) the customer might create one glossary page with terms listed as paragraphs in the rich text editor.
All of these pricing models have their benefits and risks but they don't necessarily dictate success or failure. As I often say, a successful software acquisition establishes a partnership that delivers balanced value to both the customer and the supplier. The pricing model is an important aspect of that partnership because it establishes the terms of exchanging that value. But like all terms, pricing is negotiable and negotiation works the best when both sides seek a win-win result. If the customer is sensitive to the vendor's need to generate revenue to sustain its business, and the vendor is sensitive to customer's need to make cost-effective expenditures, mutually beneficial terms can be reached