We've explored usage based pricing for our app which has a core unit-of-work that delivers value to the user. We've talked with various customers about adopting usage based pricing in place of our standard cost per user pricing model. We thought it would be great to align user costs with value delivered.
Turns out no one wanted the usage based pricing even if it could save them money based on their predicted usage. Companies preferred the consistency, clarity and control of a user based pricing.
We didn't try out a cost cap like the $20 here, so maybe that was a missing ingredient in our tests.
This is something that has been known for many years in the consumer space: customers dislike usage based price even if it would be cheaper. This is both because they don't like the unpredictability and also because now every transaction involves a tiny pang of losing money. "Unlimited for a constant fee" is much nicer psychologically, because you take away the guilt of using the app.
This is mostly a thing in consumer products though, perhaps for b2b it is different.
I agree with this reasoning where it concerns someone who already recognizes that what they are using is a worthwhile tool for what they want to do on a regular basis. But for a looser test drive situation sometimes the flat sign up here with autorenewal and don't forget to cancel darkish patterns can be a blocker to entry. I look at it like a pre-paid vs post-paid mobile phone story where sometimes you just want less friction and hassle than a contract even if it's benefits are better. The thought experiment below is simple and who knows if User A would come back to the tool if faces with a problem to solve in month 3 but I think it supports a UBP approach.
User Journey A
One (out of 100 landings) decides to take a 1-month $10 subscription, fiddles around a little but at the end of the month is not convinced of the value based on how much the tool was used. Cancels Subscription.
User Journey B
One (out of 70 landings) decides to put down a $10 prepaid amount for a block of product usage. Month 1 has limited usage. Month 2 has limited usage. But in Month 3, they face a problem this product solves and find long term value along the way.
Absolutely agree with you. I do think it also depends on the kinds of companies you are seeing. In our case, we realized we have 1 member devs, but also 1000 member teams. And didn't want to drive all the larger teams towards a "contact us" button unless they were really large. So a standard user based pricing (which most of the players in our space have) didn't work for us. That's what led to the cap.
I agree communicating this is a challenge. We're spending multiple iterations on trying to have a good calculator (we're on your 10th iteration now ha!) on our pricing page to try to explain this. Coz once obviously it makes more sense from a budget perspective, but it's not necessarily intuitive. So end up getting questions around how we calculate usage etc etc. So trying to also beef up the FAQ section more.
Turns out no one wanted the usage based pricing even if it could save them money based on their predicted usage. Companies preferred the consistency, clarity and control of a user based pricing.
We didn't try out a cost cap like the $20 here, so maybe that was a missing ingredient in our tests.