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.
We produced the same data, we got the same value, we probably cost our providers the same, but we saved a ton of money.
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.
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.
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.
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)
Subscription seems better because you can just subscribe multiple times for shorter periods.
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.
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.
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.
Also, shipping costs are largely included in the price, and the shipping price / prime thing is just an economic game on top.
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 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.
A few days ago I read, many companies prefer cost predictability to cost efficiency.
Suffice it to say -- as the owner of an SMB, I despise usage-based pricing.
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).
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.
I'd love to hear more thoughts on the topic.
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.
