Ask HN: Need Help with Pricing Model
3 comments
The reason customers are struggling with MTU-based billing is because that’s “your world/your problem” language.
Bill them by terms and items in “their world/their problem” language. Customer profiles, customer records, data records, or whatever makes sense to them.
When they ask you “what’s an MTU?!” take the words you use to explain it and consider billing on that instead. They’re not using you to store/produce MTUs; they’re using you to better connect with their customers.
You also don’t need to go full utility pricing (where if they do nothing, they pay nothing). Tiered approaches to billing give you and them more certainty and removes a bit of friction from the initial interaction. “Up to 25K user profiles and 1000 email events (additional emails $10 per 1000)” might be more customer-friendly language.
You can have customers that you lose money on if they have exactly the perfectly wrong shape of data for a while. Just make it easy and make sure you have a path to being profitable on the aggregate.
Bill them by terms and items in “their world/their problem” language. Customer profiles, customer records, data records, or whatever makes sense to them.
When they ask you “what’s an MTU?!” take the words you use to explain it and consider billing on that instead. They’re not using you to store/produce MTUs; they’re using you to better connect with their customers.
You also don’t need to go full utility pricing (where if they do nothing, they pay nothing). Tiered approaches to billing give you and them more certainty and removes a bit of friction from the initial interaction. “Up to 25K user profiles and 1000 email events (additional emails $10 per 1000)” might be more customer-friendly language.
You can have customers that you lose money on if they have exactly the perfectly wrong shape of data for a while. Just make it easy and make sure you have a path to being profitable on the aggregate.
Price should be based on value to the user - not cost to you. So ask yourself this question - if you have 2 customers, each with 25,000 profiles. Customer 1 has average monthly sends of 1,000. Customer 2 has average monthly sends of 10,000. Is customer 2 getting 10x more value?
If they make revenue per message sent, then the answer is "yes". Customer 2 is getting 10x the value, so you can charge them 10x the price. Your current model maps with value.
If this is the case, you have a "fire bad customers" case. That is, if you are a car insurance company, you make more money by causing your worst drivers to stop being your customers! You can simply tell them that you aren't interested in working with them any longer. Or you can set incentives which will select against them. (Minimum charge per month?)
But if Customer 1 typically has more value per message sent because of the selections which your system is using, then there is value which you are not capturing.
A new system could try to capture that value any number of ways. $x per 10,000 profiles, plus $y per message sent, would be straightforward.
If they make revenue per message sent, then the answer is "yes". Customer 2 is getting 10x the value, so you can charge them 10x the price. Your current model maps with value.
If this is the case, you have a "fire bad customers" case. That is, if you are a car insurance company, you make more money by causing your worst drivers to stop being your customers! You can simply tell them that you aren't interested in working with them any longer. Or you can set incentives which will select against them. (Minimum charge per month?)
But if Customer 1 typically has more value per message sent because of the selections which your system is using, then there is value which you are not capturing.
A new system could try to capture that value any number of ways. $x per 10,000 profiles, plus $y per message sent, would be straightforward.
For your scenario, i'd probably either just bite the bullet and migrate everyone over (maybe giving a permanent discount to the users only using email) OR Create a "hidden" tier not available to the public for these specific users, that way they can be grandfathered onto the old plan and not get screwed by the new pricing.
As for grace period, I usually warn people at a minimum one billing period away. If it's a product that takes a large effort to move off of i'd probably recommend a bit more time as you don't want to force people to keep paying at a price they aren't comfortable with.
As for grace period, I usually warn people at a minimum one billing period away. If it's a product that takes a large effort to move off of i'd probably recommend a bit more time as you don't want to force people to keep paying at a price they aren't comfortable with.
The challenge with this is it makes price estimation difficult (we currently can’t even do annual pricing) and we incur costs on total number of profiles in the account and not only the ones engaged. (We have to do customer segmentation for every user profile).
We are considering profile-based charging (everyone does this) and the biggest challenge for us is the price difference this will cause for some existing customers. Some customers actively use us for just transactional email analytics and do not send messages so we charge them just for the data events. The new pricing model could mean charging them up to 15x which is unreasonable. I am also trying to avoid creating a separate pricing for just the transactional email analytics. Products with multiple pricing models can be confusing.
I'd appreciate suggestions on how to deal with this? Also, what grace period should we be looking at for migrating customers?
(More context is available here: https://obem.be/2021/12/12/rethinking-our-pricing-model.html)