Questions to Ask Before Adopting Usage Based Pricing | Hacker News Reader

Questions to Ask Before Adopting Usage Based Pricing

adilaijaz.medium.com

93 pointslamflam38 comments

Another thing to consider: does your usage based pricing reflect your costs.

If so, usage based pricing can allow you to offer a significantly cheaper product as A) expensive users no longer need to be subsidized by cheap users and B) users are incentived to use less resources.

This approach has some results that directly contradict what the article says:

> Question #1: Does value increase with usage? > Pricing should always align with business value.

No, cost to provide is relevant as well. If there is not sufficient margin between the business value and the cost to provide, then maybe the sale shouldn't happen. That is not to say you should never make such sales, as they might enable other more profitable sales (either directly, or by virtue of having a more popular pricing model).

> Question #2: If the customer throttles usage, is the value reduced?

If a customer can throttle usage without decreasing value, and the service has a non-negligible cost, you have a great candidate for usage based pricing. The customer looses nothing while your costs go down. You can even pass the saving onto the customer in the form of lower prices for those customers that choose to throttle.

> A customer could temporarily cache the result of an API call in memory

Caches are a good thing that can significantly reduce your hosting costs.

"If there is not sufficient margin between the business value and the cost to provide, then maybe the sale shouldn't happen."

I had the impression, when people talk about value based pricing, they assume that the value is higher than the cost.

The idea being, the customer pays more without you ending up with higher costs.

A common scenario I see is "host based pricing". We went from 100+ 2xlarge instances to 10 24xlarge instances for our ECS cluster. This was pretty transparent to our application and team, but it meant that anything with host based pricing was much much much cheaper.

We produced the same data, we got the same value, we probably cost our providers the same, but we saved a ton of money.

This is where I’m really annoyed by vendors pricing models. An example would be cpu/core based licensing meaning that you need to lump systems on the same vm, even if architecturally it would make more sense to split them.

Then we have something like Kafka per topic pricing as a proxy for per use pricing which is even more annoying because now we get all kinds of shenanigans to reuse topics to avoid paying for having thousands of them and generated on the fly.

I'm curious -- what kinds of businesses do cpu/core based licensing, in your experience?

Oracle DB and SQL Server are both licensed per cpu core. At least last time I priced them out.

Openshift is one

Also flight simulation image generation software ID often licensed per #cpu

> Caches are a good thing that can significantly reduce your hosting costs.

Sometimes. Sometimes they are a bad thing because your hosting costs are nil and the customers gets more benefit than expected from the one call without paying for it.

Years ago there was a company that decided to save on costs by buying just one subscription to some trade magazine and share it between the 7 people who needed it. Problem was the magazine was very niche and so the lost of 6 subscribers was 10% of the total subscriber base and the magazine couldn't afford to run at all anymore.

If your result can be cached and reused then you need to figure out if that caching fits into your plan.

Missing: what is the customer break even for unlimited.

If I buy a word processor for $.01/word, I can buy one for $100 - then I only need 10000 words to break even. You can play with different pricing schemes, but you need to ensure that enough people will find value in your scheme to pay you, because there is always the option of someone else's unlimited plan. Even if all your competitors are also on some sort of usage pricing, I can hire a bunch of developers to write me a custom an unlimited version, and maintain it - at some usage this is worth it.

Of course not everything is so easy. My company pays AWS because it is cheaper to do that than to buy and upgrade all the servers we need. Our usage has busy months where we use 10x as much as the slow months, if we had consistent usage it might be cheaper to have our own servers, but we don't pay AWS for the non-peak months even though they have the servers. (I don't know how AWS handles this, that is their problem not ours)

That's the general issue with subscriptions too. I'm fine with paying Adobe a subscription for a program that I use on a regular basis. I'm not fine with paying Adobe a subscription for a program that I might pull out to do something with once or twice a year.

Wouldn't that be an issue with a $500 photoshop license too? You'd only get to use it a handful of times before the software stops being compatible with your OS (probably).

Subscription seems better because you can just subscribe multiple times for shorter periods.

Certainly. Although, in my experience, you can usually keep older software running for quite a while. Maybe you even use a VM.

Yeah, this doesn't take into account the fact that you can activate you subscription only on the months that you actually use it. This is super-easy on iOS, buy YMMV on other platforms and payment methods.

I don’t want the mental overhead of this. Not to mention the dark patterns for cancellation that are prominent outside the iOS subscription ecosystem.

Yeah that's definitely an issue. I'm not sure how Adobe's subscription system works, I doubt it's too bad though.

I got a trial subscription to Adobe Acrobat to do some PDF optimization I needed done. After I did the task just went to manage subscriptions and canceled it. Was very straightforward.

The compatibility with my OS is my problem, not Adobe's. At a certain point I'll need to buy another copy, but Creative Suite 2 runs just fine on Windows 10 ("the last version of Windows"), so that date is likely far in the future.

AWS has what they call a cost-following strategy, where their pricing actually exposes the architecture of the system to the point where you can understand how it's implemented and the data structures used if you look at the pricing.

I've heard it being described as an alternative the kind of speculation and navel gazing that precedes all other kinds of pricing and is ultimately useless anyway. However you choose to paper over your costs with pricing schemes, some customer will have a use-case or hack that blows through it and gives you grief. Or a competitor will do cost-follows and give everyone a reason to switch to them.

The idea is that you figure what your costs are to provide the service, and then add your margins and just charge that. Add as many axes as your customers will bear, and let them make the decision on how to use the tool, even if it seems complex.

Works great for technical tools, but I've always been skeptical about how consumer pricing is done. The Amazon Prime membership itself goes against this principle, of course. Consumers will usually value predictability over analysing ROI, so flat rates might just make more sense there.

>I've always been skeptical about how consumer pricing is done

Consumers seem to mostly favor memberships/subscriptions. Even utilities like electricity and water and pretty much predictable in practice. Pair per view/pay per listen/pay per read seem a lot less popular in general for media. The counterexample may be books, but then most people don't read a lot of books per month/year.

Which makes sense. A lot of people want to budget fairly tightly and subscriptions are better for that.

> Pair per view/pay per listen/pay per read seem a lot less popular in general for media

There's lots of reasons for this.

Spotify is $9.99/month. Average listener streams 25 hours of content [1], and the average song length is 3.5 minutes [2] -- this means most people pay about $0.023 per song.

For one thing, by charging per song you now force someone to make evaluations of their use. I'd be much less likely to just leave music streaming in the background (which I sometimes do) -- even if I walk out of the room -- if I have to think about that constantly increasing bill. You could also get into runaway costs, if it was accidentally left on (but muted) overnight or longer, for example.

I can't find data on it, but I'd bet there's a long tail of users who stream significantly fewer songs, and a small handful of users that stream significantly more. Spotify makes a lot of money on that long tail due to low usage.. why would they sacrifice that? Alternatively they could jack up their price-per-song, but that would dissuade all but the lowest-usage users.

And honestly as user, I don't want the cognitive overhead of thinking about this.

[1] https://www.businessofapps.com/data/spotify-statistics/

[2] https://fortune.com/2019/01/17/shorter-songs-spotify/

I'm certainly part of that long tail. I tend not to have music on background most of the time.

You're absolutely right. Literally a couple decades ago Clay Shirky coined(?) the term mental transaction costs in the context of paying for articles, etc. It would be absolutely exhausting to have to decide whether it's worth a nickel every time you read something or listen to a song--especially, as you say, with music where it might just be on in the background.

Amazon offers cost-follow pricing by default. Prime is the unlimited override.

Also, shipping costs are largely included in the price, and the shipping price / prime thing is just an economic game on top.

Something that is missing from this article: Do your customers understand the metrics their usage is based on? If not, you're going to have trouble selling your product on a usage model.

Good point.

A few days ago I read, many companies prefer cost predictability to cost efficiency.

Well, people are generally fine with variable pricing efficiency. They just don't want it to exceed some budget cap.

I think that's sort of covered by "Is usage predictable for the customer?"

The problem is that I'd probably argue that something like AWS at least somewhat breaks this question (and others). Unless you're only using AWS for something like S3, it's mostly only predictable by trial-and-error and billing alerts. Heck, there are consultants whose full-time job is helping clients with AWS bills.

OK, maybe the big cloud providers are outliers, but they don't even allow you to put caps in place aside from billing alerts and building your own triggers.

>I think that's sort of covered by "Is usage predictable for the customer?"

I initially thought this too, until reading the content of that point. The emphasis is really predictability in this section, even if usage is consistent, customers will have a hard time trusting it if they don't understand what it is based on.

Cloud providers are generlaly selling to technical customers. But you need to make sure you pick metrics that your customers understand. If you were selling a recipe system and your target market is restaurants and chefs, would you charge for PostgreSQL table usage or the number of recipes that can be stored?

Saying you can store 100MB of table data, but that should fit for your 100 recipes, is different than directly specifying that your plan includes 100 recipes. Even if the customer plans on never actually having more than 80 recipes.

I think that's fair but it also depends on the product. Something like Stripe, per transaction is a very obvious variable metric--and, even better more transactions is almost certainly a good thing for a merchant. A metric based on MB transmitted or API calls would be pretty silly.

AWS is inherently much harder to tie to non-technical measures. Yes the customers are more technical but that doesn't mean AWS formulas are necessarily predictable for them.

AWS pricing info sure is testing that theory! /s /not-so-s

Last time I dealt with usage-based pricing, I racked up a $13k bill for an APM service. I wasn't aware it was even happening until the attempted charge at the end of the month. No warning emails we sent to me. Thankfully, they let me off the hook as I had been a customer for years before they moved to usage-based pricing. But I'm no longer a customer, because that event made me reevaluate if the service was really even worth it at that point in time.

Suffice it to say -- as the owner of an SMB, I despise usage-based pricing.

That shouldn't be a knock against usage-based pricing per se, that's a knock against usage-based pricing that fails the predictability test (#4).

Products aimed at other parts of the enterprise (e.g. Sales, HR, Support, etc.) frequently meter on the # of seats. Since a "seat" usually maps to an employee, this has the benefit of being predictable as well as proportionate (to the overall cost of the employee).

No mention of competition. This is an obvious one: Will we be more expensive than the competition if we change our pricing? And another: Will we create an opportunity for a competitor to jump in?

My experience with offering usage based pricing was not positive, mostly because we didn't impose a time limit on the consumption of the prepaid credits, which resulted in a a huge cash flow problem. We've now switched to a more standard tiered subscription model with some optional packages, where each tier also imposes limits on the usage, and this works way better. (Of course, n=1, so YMMV)

As someone who's implemented a usage-based billing system for an enterprise SaaS company, I think this leaves out an important practical consideration - what's the cost of building and maintaining the systems you need to support usage-based billing?

We used Zuora for billing but had to build the whole usage-based system ourselves on top of it and integrate. It was definitely not trivial (maybe there's a startup in there somewhere), and I would just say it's worth factoring in that cost when making this decision.

Is Slack's active user pricing actually usage based pricing?

I think this is a reasonable question. Usage based pricing seems like a trending topic lately and I hear Slack called out as a good example. Monthly seat licenses were a practice that existed long before more obvious "usage based pricing" models became prominent.

I'd love to hear more thoughts on the topic.

I am having a current experience from a customer's perspective on usage based contracts.

having a VERY frustrating experience with Iterable making us switch to an opaque multi-combo usage contract and this article has some good points.

This turned into a long vent, but points I would additionally add from my current experience as a customer:

7: consistency in pricing & contracts 8: transparency 9: ability for customer to calculate themselves (might add into #4 predictable)

there was a recent thread on ousting their CEO which mentioned these sales tactics. To me personally Iterable is now a totally different company, feels like Oracle level behavior pushing onto my small company.

We've been long term customers, to the point my first contacts and support requests were with the ousted CEO Justin himself.

Last year contract renewal they tried to force this but a higher manager intervened. No luck this time; radio silence.

#7: Is pricing consistent: Having consistent contracts over long time frames is important to many small and large customers. Changing structure dramatically during a contract renewal feels like holding us hostage, and contract length is only one year.

If you make a change in pricing how does it affect existing customers?

Big one for me. I strongly dislike even if it might save a small amount of money - and that's a big if.

I feel like companies are taking hundreds of millions in VC $ and are then forced to hold you hostage to pay back the investors.

#8: Is pricing transparent: How is pricing calculated and is it clearly understandable and useable for #4 predictable?

For me this is the biggest problem. We went from a simple contract based on unique emails charged CPM.

Their new pricing combines unique emails + send volume + custom events.

Custom events are the oddest to charge for. First, they were a big value proposition originally something new to ESPs. Like the article says could be similar to salesforce charging for Opportunities it's in iterables best interest for customers to get value using unique (or what once was) features.

#9: is the customer able to calculate their usage charges themselves?

This is a horrible point: there is no way, at least that I know of, to actually count how many custom events we sent in with their GUI !!!!

only on my backend. I asked they never replied so I don't think I'm missing something obvious.

The points in the article: #4: Is usage predictable for the customer? Not really. We are an agency clients come and go all the time, each having wildly different email lists. In politics things grow dramatically during the last 3 months, but it's unpredictable.

Question #3: If the customer throttles usage, is that ok for your strategy? It would result in less revenue for Iterable on all three usage charges.

First for us would be cutting out custom events that don't provide us with the value for the cost, but are nice to have and original value prop.

We already throttle anyways for 'dead' contacts remove them from Iterable DB before billing.

I can see this as a strong argument for charging simply for email send volume, as sitting rows in DynamoDB are super cheap compared to SES. At least switching to that alone makes sense logically for costs on their end.

But they should have thought of this years ago or rolled out to new customers only.

Question #5: Is the pricing axis large-scale? The proposed tranches are large scale for our numbers, but if you are moving to complicate this why not just charge CPM and discount at higher levels? I currently don't know the proposed CPM overages for any of the 3 usage items, and if they break them out that breaks the veil of their combined opaque new pricing.

It looks like not a big discount at high end usage but again hard to tell.

Our existing old contract was very simple and did have significant large-scale pricing savings.

Reply on news.ycombinator.com