rishabhkaul1

Both transactional and usage-based subscription are usage based models because the metric you are billed on is tied to usage. In one, there's no minimum cost (think twilio) and in another there's tiers of usage (hence subscription) - like Zapier where you can only buy Zaps in specified blocks. So if you want to use 433 zaps, you will still be billed for 500. So it's kinda like a subscription.

I will try to make this more explicit.

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.

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.

Absolutely agree with you. I do think it also depends on the kinds of companies you are seeing. In our case, we realized we have 1 member devs, but also 1000 member teams. And didn't want to drive all the larger teams towards a "contact us" button unless they were really large. So a standard user based pricing (which most of the players in our space have) didn't work for us. That's what led to the cap.

I agree communicating this is a challenge. We're spending multiple iterations on trying to have a good calculator (we're on your 10th iteration now ha!) on our pricing page to try to explain this. Coz once obviously it makes more sense from a budget perspective, but it's not necessarily intuitive. So end up getting questions around how we calculate usage etc etc. So trying to also beef up the FAQ section more.

btw, congrats on Text Blaze!