By: Cris Wendt
Pay-per-use licensing and pricing models have a lot of cachet these days, especially as a model ideally suited to some cloud computing environments.
But, behind a pay-per-use pricing and software licensing model are a lot of implications to both the producers and users of software that may not be obvious, or necessarily advantageous. Consider the following, which are a few of the lesser discussed issues involved in moving to a pay-per-use model.
Of particular interest is the revenue stream associated with a pay-per-use license model. Ultimately, a producer of software would like to make more money from a per-per-use model as it provides more value to the consumer, yet the consumers of software typically have a perception that they'll pay less for software. This comes from the ideas that aren't paying for shelf-ware, and that fees will be low for infrequently used software. The successful model will require a balance of the flexibility of pay-per-use, with the predictability of a subscription or perpetual license model. This requires a model similar to what a cell phone company does, requiring a minimum commitment to get a desirable fee for the unit of usage. The goal of everyone is really to allow customers to be more productive and achieve business results by using and paying for more software, but it must be done in a way that customers aren't incited to use less software because of cost.
Providing software in a pay-per-use model is like giving the customer a gas-pedal in a car in that it helps a customer to achieve business results faster, but, in the process, costs can escalate to exceed budgets. So, along with the gas-pedal, the software provider must also provide a brake in the form of management tools, so that the customer can gain visibility into usage, and, throttle back usage if needed.
The selling process in a pay-per-use model becomes more consultative. The barrier to adoption is theoretically lower with a pay-per-use model since a large up-front perpetual or subscription license fee isn't required – the customer only pays for software only as it is used. Growing usage to drive more revenue for the software producer requires more emphasis on customer education and the effort of sales engineers to show customers how to be more productive by using the software.
The packaging and bundling of products (monetization units) from underlying software functions becomes in some ways, simpler. Rather than creating larger and larger "bundles" of products and functions that drive up the deal price (and lead to a degree of shelf-ware as lower utilization products are often bundled with higher utilization products), customers tend to want to use more atomic levels of functionality that match closer to what they need. Product Marketing still needs to effectively determine the best grouping of functions to create a product, but customers will have less tolerance for complex combinations of product bundles or suites.
Ultimately any successful pay-per-use model requires a good understanding of how products are used to produce benefit for a customer.
