[HN Gopher] Questions to Ask Before Adopting Usage Based Pricing
___________________________________________________________________
Questions to Ask Before Adopting Usage Based Pricing
Author : lamflam
Score : 82 points
Date : 2021-06-04 12:36 UTC (10 hours ago)
(HTM) web link (adilaijaz.medium.com)
(TXT) w3m dump (adilaijaz.medium.com)
| awillen wrote:
| 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.
| gizmo686 wrote:
| 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.
| phamilton wrote:
| 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.
| spockz wrote:
| 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.
| ezekg wrote:
| I'm curious -- what kinds of businesses do cpu/core based
| licensing, in your experience?
| darrylb42 wrote:
| Oracle DB and SQL Server are both licensed per cpu core.
| At least last time I priced them out.
| jonfw wrote:
| Openshift is one
| k__ wrote:
| _" 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.
| bluGill wrote:
| > 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.
| dillondoyle wrote:
| 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.
| bluGill wrote:
| 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)
| ghaff wrote:
| 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.
| thebean11 wrote:
| 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.
| ghaff wrote:
| Certainly. Although, in my experience, you can usually keep
| older software running for quite a while. Maybe you even
| use a VM.
| sudhirj wrote:
| 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.
| foobiekr wrote:
| 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.
| thebean11 wrote:
| Yeah that's definitely an issue. I'm not sure how Adobe's
| subscription system works, I doubt it's too bad though.
| ghaff wrote:
| 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.
| freeone3000 wrote:
| 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.
| k__ wrote:
| Is Slack's active user pricing actually usage based pricing?
| gerner wrote:
| 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.
| bachmeier wrote:
| 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?
| ToJans wrote:
| 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)
| ezekg wrote:
| 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.
| runako wrote:
| 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).
| sudhirj wrote:
| 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.
| ghaff wrote:
| >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.
| gregmac wrote:
| > 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/
| ghaff wrote:
| 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.
| PaulWaldman wrote:
| 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.
| ghaff wrote:
| 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.
| PaulWaldman wrote:
| >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.
| ghaff wrote:
| 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.
| k__ wrote:
| Good point.
|
| A few days ago I read, many companies prefer cost
| predictability to cost efficiency.
| ghaff wrote:
| Well, people are generally fine with variable pricing
| efficiency. They just don't want it to exceed some budget
| cap.
| ChicagoBoy11 wrote:
| AWS pricing info sure is testing that theory! /s /not-so-s
___________________________________________________________________
(page generated 2021-06-04 23:01 UTC)