Want taste? Eat your slop.

Input based pricing vs Output based pricing

Usage based pricing is being talked about a lot lately. Partly due to changing unit economics for software but also because its trendy right now. One discussion I’ve had several times recently is about the difference in pricing user inputs and pricing user outputs. Both fall into the world of ‘usage based’ prices but they’re perceived quite differently by customers and can shape your business in meaningful ways.

Within the two pricing setups below they can both be setup in many ways. You can charge purely on use (1 unit = $1) or in more complex ways like tiered usage (units are cheaper the more you use) or in allotments (500 units a month on your subscription). These changes are a separate arm of pricing and don’t really change the differences below.

Input based pricing

This form of pricing charges the user for the consumption of some resource. Users pay per unit and presumably use that resource to go and do something. Examples of this might be API calls or number of contacts in a CRM. In the non software world this would be like charging for petrol or electricity.

This kind of pricing is very common, partially because it’s really easy to meter. One SQL query will tell you how many contacts you have and therefore how big your bill should be.

I’ve seen a lot of products aim to switch to this kind of pricing recently. I can see why. Every user, regardless of their size, pays an amount proportional to how much they’re using the product. As a result you’re extracting all the possible revenue.

The problem with this pricing model, at least form the customer perspective, is that what you’re billed for may not be well correlated to value.

If you are billed per contact in the CRM per month and half your contacts are terrible then you’re paying for the waste. If Netflix charged for every movie you started you’d probably be annoyed if you were billed for something you ended up hating.

That’s not to say there aren’t ways around these things. You can have a refund on movies you didn’t like or automatically remove bad contacts to help reduce billing.

Additionally, not everyone has the same aversions to being billed this way. Getting billed per API call might be fine if that API call is buried three levels deep into your product. In that instance you’re probably not thinking about the API at all. That service has become a utility in the same way that power and water are utilities. In an ideal market competition pushes the prices down and the service becomes a commodity. Okay for users, not always a great business to build.

If you’re not a commodity, lets stick to the Netflix example, then you often see a rationing behavior in users. Before someone uses one of their precious Netflix Tokens they’re probably going to check the ratings.

For something like Netflix this is probably a bummer (and why they don’t price this way). For other products it can be catastrophic.

If your product relies on user generated content then rationing can actively degrade the product experience for everyone. If it cost money to post a video on TikTok and users rationed out of creating them then there’s less to watch. With less to watch the whole product loses it’s appeal and content self-filters to people making an ROI decision on “if I post this can I make my money back”.

Arguments about whether short form video is good or bad aside, this happens in B2B products as well, especially marketplaces. Network driven products rely on a strong and active network. Rationing degrades that network and the value delivered to all users, not just the ones who ration.

So why would anyone price this way? Assuming they’re not a commodity, its often because its simpler. Simpler at least in comparison to output based pricing.

Output based pricing

Output based, or as its sometimes called Outcome based pricing is a variant of usage based pricing that charges based on a positive outcome.

Compared to input based pricing this one is a lot more complicated to measure and therefor bill.

Let’s go back to the Netflix example. Assuming they wanted an output based price they would need to find a way to bill you only for the shows you liked. There are some rough ways to do that, if you binge 4 seasons they you should probably pay for it but its open to a lot of interpretation.

Intercom, which became Fin, which is now part of Salesforce, has become a little bit of a headline for this type of pricing. Historically they charged an input based price based on the number of support conversations you had. Their outcome based price, built specifically around this AI agent Fin, was billed based on successfully resolved issues. If Fin couldn’t solve it, you didn’t pay.

I think that’s a great way to price a service. I don’t think many products have that kind of transactional, clear cut, incremental usage pattern. While you could technically mark a request as ‘not resolved’ to save a few bucks, if that goes out to an end customer as “Elliot marked your case as not resolved” that creates a negative experience that probably isn’t worth the money you save.

Netflix on the other hand would be a lot harder to meter. If you ask me at the end of an episode if I liked it and I don’t want to pay as much, I’ll say ‘no’ and save my Netflix Tokens.

This difficulty is part of what pushes people to input based pricing. Lots of people want to charge only when the customer gets ‘value’ but its murky and hard to measure it ends up being more trouble than it’s worth.

To use another example imagine a sales CRM like Salesforce. You could argue that having a tidy view of your sales pipeline is valuable but really the reason you have one is to close more sales. You’re relying on users to be honest about their deals, not to mention the general difficulty in keeping deals up to date at the best of times.

This kind of pricing has it’s own type of rationing, which might already be clear. In output based pricing users ration by lying. If you can easily, and with little downside risk, avoid marking the value as collected then you pay less for the tool.

To make this kind of pricing work you not only need a clear unit of value delivered, you need a concrete way to mark when it happens.

Output based pricing also has downward pressure on price. First movers here have the advantage of being able to price against the incumbent value of the outcome but that doesn’t last. Fin could likely claim “we save you X hours, that’s normally worth $40, we ask for $10” but when there’s a dozen competitors in the market the price fixes around the the way of doing things and the $40 it once cost become irrelevant.

This tends to work fairly well in multi-sided interactions like Fin where there is some social pressure to record the truth. Your sales lead has no idea you didn’t mark the deal as won but if you’re booking a landscaper and they mark the job as ‘didn’t happen’ that creates friction.

Conclusions and advice

Usage based pricing can definitely work. A lot of the drive at the moment is that ‘Tokens’ is now a currency in a lot of software. Power users can now generate costs much higher than light users.

Even with that considered, realize that this is a trend. I am all for experimenting with pricing and packaging but the market is fickle and may shift again to ‘buy once for life’ or back to ‘monthly subscriptions’.

There may be some pressure to change your pricing to match market expectations but it’s important to know if that’s why you’re making the change.

My prediction is that long term some subset of Fin-like businesses will always choose outcome based. Others that are commodities will pick input based and we’ll broadly optimized towards pricing predictability across the rest which likely means a fixed monthly fee.

If you’re thinking about price changes like this make sure you consider the consequences of rationing or dishonest usage and what effect that might have on your product.

Source link

Share:

Leave a Reply

3 latest news
News Archives
On Key

Related Posts

Everything hackable will get hacked

Everything hackable will get hacked

Over the past year, AI models have become much more capable of performing cybersecurity work. These changes are reshaping both the threats facing the web