[benkan]

I believe that usage-based pricing is valuable to the customer, but I see one problem for the vendor: If each use of the product is billed, this provides an incentive NOT to use the product. In other words, you actively drive usage down.

I'm not saying that I am against usage-based pricing or that it does not make sense, but especially in B2C markets, this might be a problem.

[martin_a]

> If each use of the product is billed, this provides an incentive NOT to use the product

We are running a special solution since 2020 with a "pay per order" model. I thought like that in the beginning, too. That has changed.

The product is just _so_ useful to us that we save so much money on each order that the processing fee is peanuts, compared to that.

So I think this might come down to the usefulness of the product. In our case with this specific solution it works very well, but I'm not sure it would for something like a database or something like that.

[rishabhkaul1]

I didn't quite understand this. Why would the vendor have a problem with this - you mean rising cloud costs?

For the customer the value is ofcourse apparent. They aren't locked into a monthly fixed price. Plus the cap helps drive predictability incase of spikes of usage.

[tokamak-teapot]

The problem for the vendor is that their customers are encouraged to avoid using their product.

[rishabhkaul1]

That's interesting. Because that's exactly the behavior we're trying to prevent.

Think of the alternative: - A user uses the product for one hour and they pay the same amount as they would if you use it for the entire month.

I think that's where the cap becomes important. Think of the cap as a traditional user based pricing. Now only in the case where EVERY single user ends up using it VERY actively will they ever pay that amount.

In every other case, they end up paying less, because they're only paying for the value.

So if Slack is today charging $8/user, but instead they change their model to max $8/user, but users who message lesser pay lesser than $8, then it's a fantastic decision commercially. Esp as an org scales.

I think the real issue is that, when you add a new user, you're not really sure if they're going to use the software fully, so you're hesitant adding them (think about buying a salesforce license for a solution engineer). But if someone said "hey, you don't pay the full amount, till they end up using very actively", then you're more likely to invite more people because the risk of racking up costs is lower.

So the hope is also that a pricing like this leads to more experimentation and wider adoption by a customer.

[sokoloff]

What’s Slack’s incentive to charge strictly no more for any individual user? I can see them going to $x per activity, capped at $15/user/mo and $10 * (total number of users)/mo, but if they’re getting $8/user/mo now, there’s little incentive to make that $0.01-$8.

[rishabhkaul1]

Ok, slack & notion are bad examples because often the entire team is on it by default.

But imagine tools, where there is high aversion to adding more seats unless you're 100% sure. Like CRM & CMS systems, or like Support tools (Zendesk), or shared inbox tools (like Front) or project management tools (Asana) and so many others.

[benkan]

The vendor would have a problem with disincentivized usage becaused in the model, it earns the money purely by usage. It is a commercial problem, not a technical one. The company wishes to earn money, yet puts in place a model that decreases its only revenue driver.

[illwrks]

I understand it to mean, if you're the type of customer that is a high volume user your costs go up, therefore your then incentivised to reduce your usage.

[baq]

It might actually be a good thing if you are close to your architectural scaling limits