| |
| ▲ | mattzito a day ago | parent | next [-] | | I spend a lot of time on pricing and packaging of SaaS software and the challenge is real. Everybody says they want simple pricing, which often aligns to seats or MAU - but then they want usage-based pricing, but then they're concerned about unpredictable costs and spiky usage. Unfortunately, there's no such thing as a free lunch - you can have simple and predictable but you will have some users that you pay for that aren't getting value. You can have usage-based billing, but then you run the risk that anyone who uses an antipattern for the product will suddenly cost you a ton (or consume all of their allocated quota and be dead in the water, which is differently bad). The more flexibility you offer, the more complexity you're putting onto customers and sales teams to understand what's the best way for them to consume the software. There's also a lot of market pressure to "follow the crowd" - even if you have an option that is (in your mind) more customer friendly/favorable, if you are structuring your pricing differently than the competition, there will be customers who are concerned that they're not getting "a good deal" or concerned that the structure will end up being less favorable to them over time (after all, why does everybody ELSE do it this other way?). Sales reps also prefer pricing strategies that are at least structurally consistent with other products on the market, because it makes their lives easier. Similarly, it's very difficult to change pricing nad packaging later on - changing price is relatively simple, but changing units of billing or retiring an old offering can be an extremely difficult task. (disclaimer: these are just my own opinions, everything is hard) | | |
| ▲ | AlotOfReading a day ago | parent [-] | | I've seen companies square this circle with capped hybrid billing strategies. Customer gets charged the min of bills. Bureaucratic customers that need specific billing models can pick them but most people will accept the savings. | | |
| ▲ | mattzito a day ago | parent [-] | | It's funny, this was actually one scenario that I thought about mentioning but I had to get on a plane and was running out of time. It is true you CAN do this, but very few do, for a few reasons: One is, it's bad for margins - when you build a pricing model, you inevitably end up creating a system where some customers subsidize other customers. You assume each user or unit of usage is going to cost you X/unit and you charge X+Y. There is inevitably going to be a distribution of users and their usage patterns and costs, and the 90% percentile is probably going to be 5X, and the 10% is probably going to be .2X. There's not any malice there, it's just that different users have different usage scenarios and they use the product differently. Another reason relates to the issues with usage-based billing. Even in that scenario, whatever usage dimension you measure on will have users that don't fit the profile and they still end up being subsidized (from a margins perspective) by customers that DO map to the profile. A really naive example - you're a database company, you want to be cheap for people to get started, you go with usage based billing and charge based on storage. For most customers, that works - assuming your product value is apparent and differentiated, I think most people would understand that "I have to pay more because I'm storing more data, and accessing that data can be more expensive, queries more complex, and the utiltiy that I get from the database scales as the quantity of storage increases". Great, usage based billing, let's do it. But - then you have users who store very small amounts of data but with incredibly high query volumes. Your options are to either just eat the cost of those users (which might be fine for some amount of time) or now start to add additional dimensions on which you meter usage. So now you charge for storage AND cpu time AND maybe concurrent connections if that's a problem AND bandwidth. Congratulations, you have now created the perfect usage-based billing model, which perfectly assigns customer charges to handle the multitude of usage patterns that customers experience. BUT, it's really complicated to explain to people, and it's really complex to predict costs. That has two implications, one of which is that your value proposition has to be increasingly compelling as complexity increases. To use the database example, at some point someone at a customer will say "honestly, wouldn't it be more predictable if we just spun up a couple of VMs and ran a database instance ourselves?". Complex usage-based pricing works if you've got incredible technology that would be difficult to impossible for a customer to deploy themselves, but if your value prop is convenience and/or abstraction, you're diminishing that value as you make the pricing model increasingly less convenient and less abstract. The other factor is that someone has to build and manage the metering of all of these things. Even a single dimension like storage is complicated - how do I bill for additional storage? Do I look at the total storage at the end of the month and multiply by X? That hurts users who, say, run end of month batch jobs - but for you, users that use huge amounts of temporary space and then free them before the end of the month, that hits your bottom line (depending on your own architecture). So maybe you want to charge on a daily basis, but now every problem gets more complicated. Then, if you extend that across multiple billing dimensions, it's just gotten harder and more complicated. Now it's rock and a hard place time - you can stick to one abstract usage measure that is easy to reason about, but you're inevitably going to have some users that underpay based on that usage measure and some that overpay. Or you can add more dimensions and make things more "fair", but everybody's lives are harder, both for the customer and for you and your team. When you give customers automatic optimization, you get the worst of both worlds - you make less money on the bottom 10% (usage-wise) of users/customers because they end up falling into the usage based billing, and you make less money on the top 10% because there is capped upside for you as the provider. For customers, sure, it saves them money, but what you're really giving them is a price cap (not to exceed X). I would say for the sales teams, it's also not great, because they have all of the challenges of explaining two different models. For enterprises, it's a mess because 1) they'll probably want to negotiate specific billing terms for their use cases (we don't want to pay X for bandwidth, we want to pay Y) and other structural terms, all of which your billing system needs to support. At the end of the day, however you charge for anything is an abstraction layer on top of your costs. That's true if you charge per user, or per object, or per gig, or per connection, or whatever else. It's all unit-based pricing even if it's not usage-based procing. You have to decide how much work you want your engineers, customers, salespeople, etc. to do in order to build, explain, and understand how much someone will pay for software. My general advice is to pick the simplest pricing model that protects your margins and prevents abuse. For infrastructure-y products, things like storage, compute, network, are all reasonable meters. For SaaS products for business users, per-user pricing is well-understood, and there are things you can do if you really want to apply a usage-based element there (bill based on MAU, or have a MAU component separate from seats purchased). But there's really only two scenarios - you pick a small number of meters and understand that some customers will subsidize other customers, or you meter across a bunch of dimensions that align to your costs and create a lot of complexity for your customers. Blending the two gives you worse margins and the complexity of both options combined. | | |
| ▲ | AlotOfReading a day ago | parent [-] | | Yes, it's worse for margins. However, we're in a thread about how potential customers don't want to risk either spending lots of money for services they won't use or dealing with spikes. Not choosing one or the other inherently puts the cost on the provider, shrinking margins. I don't think it's an especially hard model to understand though. It's commonly called pay-as-you-go in consumer mobile plans and sold as the cheapest option to customers that may not even speak the language the fine print is written in. Those consumers still understand the service they're getting. Telecom is actually a good example of how granular billing can get, but still produces an incredible profit margin even with simple pricing strategies. | | |
| ▲ | mattzito a day ago | parent [-] | | Sure, it’s also very easy to understand paying for deli cold cuts by the pound, but it doesn’t make it a good comparison. Consumer telecom is a great example of a very constrained problem space. There’s two levers, call time and data. And the population of people who are consuming that are limited to the size of the family. By contrast, enterprise telecom is incredibly complicated, with variable pricing by region, by time, type of inbound number, and then the software that sits atop that telecom is an additional license. Telecom is also largely a commodity - one provider is the same as the other. SaaS providers are fundamentally trying to not be commodities, and so the comparison is weak at best. | | |
| ▲ | AlotOfReading 14 hours ago | parent [-] | | Consumer telecom is simple because providers have chosen to simplify the pricing strategy, not because they don't have other billing metrics available. You aren't required to have a complicated pricing structure even for incredibly complicated services. Doing so is a deliberate product choice with consequences. They're also not truly fungible, though that's mostly for the higher end of the consumer market. Think about TMobile's "uncarrier" marketing, or Verizon's network coverage marketing. | | |
| ▲ | immibis 12 hours ago | parent | next [-] | | And they have high enough volume to average out the outliers. Did you know that in New Zealand, some business/server telecoms offer different plans based on how much of your traffic goes overseas? It's connected to the rest of the world with, like, five really long and expensive underwater cables, but it's also a not-quite-tiny market itself and if you can serve customers in NZ from a server in NZ, you can avoid expensive routing. (Your customers will also appreciate having a ping time lower than 300ms, even if they don't know what ping time is) Meanwhile, ISPs in Europe don't charge you extra based on how much traffic you send to New Zealand, because you could max out your 1Gbps flat rate with NZ-bound traffic and it would still be a tiny percentage of all their traffic anyway. | | |
| ▲ | AlotOfReading 11 hours ago | parent [-] | | Didn't know about NZ, but it doesn't surprise me. Seems like we mostly agree. Another fun trap I've seen on the enterprise side is that pinging different towers can have different charges. Highest I've seen was $15 per ping. |
| |
| ▲ | mattzito 8 hours ago | parent | prev [-] | | I think now we're just arguing semantics. The only billing metrics for cell phones that are visible to the user are usage in minutes and data. This is the easiest type of metric to understand and meter - because it's pure aggregation, and you have a fixed window over which you count the number of bytes or minutes consumed. Compare that to technology metrics like storage consumed, query executions, etc. where the variability in units and behaviors can be massive. What would be other metrics that you could bill consumers for that they could do anything about? > You aren't required to have a complicated pricing structure even for incredibly complicated services. Doing so is a deliberate product choice with consequences. You're making my point - the simpler you make it, and the more abstractions you put, the more decoupled each billed object is from the underlying costs. The implications of that are that you have to be careful about making sure that the economics work out, and that means either you have some customers subsidize others or you are very confident that customers can't use your product in such a way that it turns your numbers upside down. At the same time, that abstraction that you choose will not map to how every customer wants to buy. To go back to several posts ago, "per user" pricing is a per-unit abstraction that lots of customers like and understand. Sure, customers recognize that some users will use more than others, but it's a deliberate product choice that you abstract the more complicated dimensions from the users. It sounded like YOU, as a buyer, want a DIFFERENT abstraction, which is "usage" - and again, that's reasonable, but as a product team have to make exactly the same calculus, which is "what metric do we use instead as a proxy?", with the understanding that there are lots of SaaS products where usage patterns are highly variable and it is difficult to come up with single units that cover your bases without making the per-unit price higher than it might otherwise be. It's not hard to imagine yet another buyer who says (assuming the product metric chosen was "storage consumed"), "wait, I like usage billing, but your per-GB cost is really high for us, because we store a lot of data, but we don't access most of it - why can't you just charge me for data accessed?". You either say no or add more billing dimensions. > They're also not truly fungible, though that's mostly for the higher end of the consumer market. Think about TMobile's "uncarrier" marketing, or Verizon's network coverage marketing. It's interesting, because that ALSO proves the point, because the only differentiation you are citing are things other than what customers are being metered for. There's availability differences, but that's orthogonal to the billing metric. If I have connectivity, my minute on tmobile is the same as my minute on verizon is the same as my minute on mint, and the differentiation is everything OTHER THAN the billed minute. To wrap up - I don't disagree with you that there are benefits to usage-based billing. The point that I am making is that for essentially any SaaS product that has any depth, it can be difficult to pick a single metric at an attractive price point that a) covers your margins across the spectrum of usage behaviors, and b) maps to the metric that the vast majority of your users want. If you try to make everybody happy, you either lose the simplicity or you hurt your underlying margins while simultaneously making everybody's lives harder. |
|
|
|
|
|
| |
| ▲ | ricardobeat a day ago | parent | prev | next [-] | | Usage-based pricing makes sense when you’re buying infrastructure products. For (most?) other things, the price is based on value, not material cost. The cost of that PDF generation might as well round up to zero, but developing the tech cost multiple man-years of work. How do you price that “objectively” unless you’re given a breakdown of the company R&D expenses, operation costs and margins. That is not a reasonable request. Either you’re happy paying $X because it solves your problem and brings equivalent value to your business, or you’re not. I do agree seat-based pricing is often ridiculous, but that’s a problem for the free market to solve. Alternatives usually pop up given enough demand. | | |
| ▲ | freedomben a day ago | parent | next [-] | | I agree that in general usage-based pricing makes the most sense (particularly as that is a good proxy for measuring how much "value" someone is getting from it), my biggest complaint was that the way they were trying to measure it was dumb and very outdated. It really only made sense in a world where everyone was still running on physical servers or VMs. I would certainly concede that pricing is a very hard problem for a product like this, but whatever pricing they come up with should at least map onto the system it's being used in. Basing it off of number of pages of PDFs generated might would make sense, but they insisted on knowing how many CPU cores I would be allocating (which makes little sense when it's deployed as a highly elastic lambda function!) | | |
| ▲ | doctorpangloss a day ago | parent [-] | | You sound like the worst possible customer. Don’t you see? Nobody is obligated to serve cheap people. | | |
| ▲ | freedomben 8 hours ago | parent [-] | | > You sound like the worst possible customer. Don’t you see? Nobody is obligated to serve cheap people. No, I don't see, but it's clear from your personal attack that you do see and that you can help me, so thank you in advance. Please, help me to see. Can you please point out to me where I'm being the "worst possible customer" ? Is it because I refuse to lie and/or make shit up to jam my extremely square peg into their round hole? (which I might add, would open me to legal liability down the road if I guessed wrong (lawsuit for underpaying license fees), or would mean I drastically overpay and even bankrupt the company if I guess way too high. What if I get one customer and use 500ms of a single vCPU all month, but I guessed 50 vCPU?). If they want to know things that I don't even know in order to price them, what else should I do? I have a theoretical product that doesn't exist yet, with 0 users, 0 vCPUs, and 0 vRAM because it isn't deployed yet. I have no idea if I'll get 10 users in the first year or 10,000,000. How many vCPUs and vRAM should I tell them so they can price it? Keep in mind this will be deployed in an AWS lambda function so it scales literally on-demand, demand that we have no idea of yet because the product doesn't exist. We also have no idea how much CPU and RAM it will even need, because again it doesn't exist so it can't be profiled or measured.
If you can't answer that, I won't accuse you of being "the worst possible customer" ;-) Maybe a different approach. I have a PDF library that I want to sell you. I typically charge $10,000 per vCPU per month. You are thinking about building a product on top of my library and ask me for pricing (which I don't publish anywhere so you have absolutely no idea what to expect). You have no idea how many users (if any) you'll have, and you plan to deploy this as a lambda function that can scale from 0 to Infinity almost on-demand. I ask you how many vCPU per month you're going to use so I can quote you a price. What is your answer? |
|
| |
| ▲ | eastbound a day ago | parent | prev | next [-] | | Salespeople often misunderstand value-based pricing. If a product costing V dollars is made of N parts, then each part provider claims their value is V, so they deserve V-$1. A PDF conversion may be required for the end-users, but it doesn’t make the entirety of the value of the product. It just doubles it, as well as the N features before that. But although each feature doubles the value of the product, the order of features doesn’t matter; A PDF export might have been added as the second feature, but the 10th feature still doubled it. | | |
| ▲ | WJW a day ago | parent [-] | | It's uncanny how accurately this maps to departments claiming they contribute V-$1 of the total profits. Sales argues they bring all the money, engineering argues sales would have nothing to sell without the products being made, platform claims no products would run without the infra they provide, support claims everything would grind to a halt without their constant babysitting of the users, etc etc. Only HR and Facilities don't claim to be directly responsible for any revenue, but that's only because everyone needs them anyway. | | |
| ▲ | stavros a day ago | parent [-] | | Well, it's all true. Without one of these, there would be no V. |
|
| |
| ▲ | Aeolun a day ago | parent | prev [-] | | > How do you price that “objectively” unless you’re given a breakdown of the company R&D expenses, operation costs and margins. You ballpark how long it would take you to build something similar? You don’t need any breakdown for that, just a marginally competent engineer on staff. | | |
| ▲ | immibis 13 hours ago | parent [-] | | Software developers: > we can't do estimates. Software developers as soon as estimating something would be beneficial for them. > all you need is one of us on staff, to do estimates. |
|
| |
| ▲ | derefr a day ago | parent | prev | next [-] | | What you described is likely usage-based, in the sense that the (presumably cloud) vendor usually has to reserve a certain amount of resources per user, “just in case”, because they don’t know / can’t predict your activity pattern. Same reason VMs are still charged for when started but idle: they reserve their CPUs. What people really want, when they say “usage-based billing”, is outcome-based billing. They want to get charged money whenever they hit the button in your software that makes them money (or, for a cost-center, saves them money.) Think of e.g. tax prep companies. (For the average Joe employee), they don’t charge you money up-front; instead, they take a part of the net-positive return they fully expect to find you. They make you happy, then take a slice of your happiness at the exact point that they’re making you happy. Outcome-based billing. | |
| ▲ | xp84 a day ago | parent | prev [-] | | Yes. There’s nothing more obnoxious to me than products like Figma where my company has a limited number of full licenses. They are super stingy with what my account type can do, so the 2 times per year when I need to get involved inside a Figma document or even a FigJam board I have to go begging for someone else’s license, but it would be way too costly to pay as much per seat for the entire company as we pay for our designers, for whom that’s obviously a core tool. |
|
