Comment by AlotOfReading

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.

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.