Pay-per-use Software Pricing? No Thanks!

I get a lot of input into my research from speaking with software buyers and sellers, which I analyze and process to come up with firm conclusions and recommendations in my published research and forum speeches. I'm going to use this blog to air some work-in-process analysis, to solicit additional thoughts and information from you. Just recently, Ive been considering why people are talking about 'pay-per-use' a.k.a. 'utility pricing' for software, and to me, the disadvantages to buyers and sellers outweigh the benefits.

Software pricing should be simple but fair, value-based, future-proof and published (see The Five Qualities Of Good Software Pricing). Yes, a one-price-fits-all 'per user' fee isn't fair or value-based, but that doesnt justify the potentially horrendous complexity of tracking detailed usage. Role-based user pricing, such as SAP user categories, is a much better way to reflect diverse usage profiles.

Im not arguing against flexible, on-demand services, particularly for temporary needs, such as renting some CPU power for a few hours. I'm concerned about pay-per-use pricing models for regularly used applications. To me they would be:

  1. Complex to define and track. How will a company measure time-based or transactional usage when it can't even count named users reliably?
  2. Unpredictable and uncontrallable. How do you prevent an unexpected, unbudgeted bill at the end of the month?
  3. Expensive. Some people assume that it'll be cheaper if they only pay for what they actually use. That's an incorrect assumption. The per hour rate will always be sufficiently more than the per year rate to push customers to the latter. Price is driven by negotiation leverage and competition, not the licensing model.
  4. Counter-productive. You want people to use the tools you've made available, so why create a cost disincentive?

What do you think? How do you want to purchase your business applications? What advantages can you see in pay-per-use, over prepaid capacity models, that might outweigh the above drawbacks?


I broadly agree - but pay-per-use can have its benefits

The time when pay-per-use pricing makes sense is when the "use" of the software is linked directly to a business outcome. i.e. a CRM system that you only pay per new lead added, or when a prospect is converted to a sale - which is often a key reason why the CRM system was initially implemented. A real example of this is EFT (electronic funds transfer) systems (arguably the biggest SaaS market to date! or is it BPaaS?) - where a merchant pays per transaction - but the transaction only happens when they sell something - so business value is realized and hence they are willing to pay. Larger merchants can negotiate the fee down based on volume, so negotiation is not out of the question with this model. However, defining business value related directly to a single piece of software is difficult - as most business processes touch many pieces of software - so I do broadly agree that pay-per-use pricing is not a great model - but it does have its place.

it's tradition in certain markets

I've been in the software industry for over 30 years, and it wasn't until I found myself in the financial services industry a few years ago that I came across a pay-per-transaction pricing model for complex, niche enterprise software. Apparently, it's pretty standard in certain industries, where transactions, not number of users, count.

1. Transaction counting is done by the application so customers don't carry the burden.

2. Increased transactions always equaled increased revenue, so if the numbers were up one month, it was a good problem to have.

3. Financial transaction processing software is ridiculously expensive. Enterprise license, annual maintenance plus per-transaction fees added up to far more value than I could see, but there weren't any other options except build-it-yourself, which would have cost more. It was the standard in the industry, across all vendors and many discrete applications.

4. Since it was about numbers of transactions and not numbers of users, and higher numbers equated with more revenue, no one blinked an eye at the model. Only the occasional outsider like me was outraged.

Yes, this is a little different from pay-per-use by users, but I wouldn't be surprised if this is where the idea came from.

My business helps small to mid-size companies take a best practices approach to the complex decisions around choosing enterprise software. I can't think of a single one who would find pay per use acceptable. They'd liken it to having to pay every time you brewed a cup of coffee.