There are hidden secrets there!
“Pricing is hard!” is a statement I hear all the time when I’m talking to the people who start or run SaaS businesses. While I definitely agree, when I hear “Pricing is hard!” from someone, I try to dig into it a little bit and ask — what’s hard about it? In my experience, the Hard Stuff™ boils down to:
Choosing a target customer segment
Choosing a pricing scheme for that segment
Choosing a price point for that pricing scheme
My mission with Reify is to try and use research as often as possible in helping people solve these specific problems. That’s why I was excited when I came across 2016’s “Pay as You Go” or “All You Can Eat”? Pricing Methods for Computing and Information Services [PDF Link] by Bhargava and Gangwar — it addresses pricing schemes in a very rigorous manner.
The thrust of the paper involves comparing and contrasting “Pay as you go” (per unit), “All you can eat” (buffet-style), and three-part tariff pricing to determine under which conditions companies might want to select each of these options when setting their pricing schemes. If you’re not familiar with these pricing schemes, here’s an overview:
“Pay as you go” or “per unit” pricing is when you pay for a product according to how much you use. A standard example of this is AWS, where the more you use, the more you pay.
“All you can eat” or “buffet-style” or “unlimited” pricing is when you pay a fixed fee, and don’t pay any more or less than that, regardless of how much you consume. An example of this would be Netflix, where you pay per month, regardless of how many times you watch the same episode of Freaks and Geeks.
“Three Part Tariff” or “3PT” pricing combines these two, in a way. You pay a base price for a certain amount of service, and a certain amount for overages. A common example is mobile phone plan pricing: you pay a certain amount per month for a certain number of minutes, and you agree to pay an overage fee if you use more than that.
To determine the optimal pricing schemes for companies in various contexts, the authors compare and contrast the impact of these pricing schemes under varying customer heterogeneity.
Customer heterogeneity refers to the differences between customers: what they want, how they buy, etc. In the end, the authors determine that customer heterogeneity is extremely important in determining the optimal pricing scheme for SaaS businesses, citing AWS’ choice of per-unit pricing as a key example.
Two types of customer heterogeneity
In building a framework to use for calculating a pricing scheme’s optimality, the authors identify two important types of customer heterogeneity: valuation heterogeneity (willingness to pay) and usage heterogeneity (rate of satiation, e.g. how much a customer will use). Modeling their equations using these two axes makes things more complex, but is considerably more rigorous as a choice.
The framework they create allows them to use values and a visual presentation (some cool graphs) to help answer questions about the impact that pricing schemes will have on usage and on profits. The conclusions are very interesting:
Generally, both forms of heterogeneity favor a “Pay as you Go” plan relative to an “All you can Eat” buffet plan. A three-part tariff (being more general) beats both on profit, although per-unit pricing yields higher market coverage and buffet pricing yields maximum consumer surplus.
This means that for the most part, unit-based pricing will provide the best combination of market coverage and profit. As usual, tradeoffs abound, but it’s always surprising to see what types of results emerge when sound frameworks are created. Generally speaking, the paper suggests that a 3PT scheme is your best bet if you’re having a hard time deciding.
With respect to the two types of user heterogeneity:
We found that usage heterogeneity has larger role to play in deciding optimal plan rather than traditional value heterogeneity.
In other words, how much a user can consume may have a bigger impact on what the correct pricing scheme for your company is than how much they’re willing to pay for the service. Again, this is very context dependent, but holds true in a lot of scenarios I ran through in my head, anecdotally. I’d be interested in hearing people’s feedback about this. (Also, note that this doesn’t mean that “you should charge per unit.” It’s simply an outcome of the model.)
A “real world” comparison
One of my favorite bits in the paper came right at the end:
The 3PT profit beats the buffet plan handily in all conditions, while its advantage over a per-unit plan is** highest under high value heterogeneity and low usage heterogeneity. This explains why AWS, **facing [a] low value heterogeneity and high usage heterogeneity market, may choose to stay with simpler per unit pricing.
Once the authors are able to assemble the model, feed it a bunch of data, and understand the results, they did something interesting: they gut-checked it against a well-known SaaS behemoth: Amazon’s AWS. AWS sells their services in a “per unit” pricing scheme: the more you use, the more you pay. A lot of people wonder why they do it this way, and assume that the simplicity of the pricing scheme alone makes it worth it. This paper suggests that while the simplicity likely plays a large role in this discussion, it’s actually the optimal choice in terms of profit and market coverage.
In terms of applying this to B2B SaaS companies like those I usually work with, I tend to recommend that people heavily consider a 3PT pricing scheme. It hits a lot of the “right parts of the curve” for value and appetite sensitive customers, and can provide other cash flow benefits. This paper confirms other research I’ve come across that touts the benefits of 3PT pricing for similar reasons.
Modeling pricing changes and their impact on a businesses’ bottom line is relatively under-researched. It’s heartening to see rigorous work which attempts to use data to answer interesting questions, like why industry leaders choose the pricing schemes they do.
Do you want to use data to drive your pricing, marketing, and sales decisions? Want to work with a team who does that all day every day? Get in touch!