How we de-risked our SaaS pricing strategy
blog.frontapp.com
blog.frontapp.com
It gives you nice geometric growth for the bigger clients (lots of features × lots of users), but also allows you to have a very low cost for the smallest clients (less features for 1 or 2 users).
For some reason, a lot of companies instinctively give discounts for big customers. If anything, you should be charging your enterprise customers _more_ per user, rather than less. They have the money. This geometric pricing model lets you charge big bucks for big customers, and even leave room for a nice discount percentage if it comes to that. Salesforce has been using this model for quite a while, and it appears to have been working nicely for them.
- How existing customers react, when they discover the new pricing on your website?
- At some point, do you migrate "old" customers to the "most recent" pricing model, to avoid having to maintain tens of pricing model in parallel?
But at some point I realised that it doesn't matter. You don't need to make the maximum possible amount of revenue.
If you sell your product for a lower price, you allow more people to use it.
Sure, make your product cheap and you might leave money on the table with big enterprise customers. But if it's cheap, maybe a school can afford it.
That must be worth something too, right?
I'm not saying that you should give away your work. But once you make enough profit, why not try to maximise the positive impact your software has on the world?
Having said that, I do think that trying to min-max pricing is quite a waste of time and resources, assuming you're already at a good place for pricing, and like you mention, are already gaining a decent profit. You'd probably be better off spending developer time and resources into satisfying your customers' needs, performance improvements, instead of extracting the most profit out of them. It's easier to tweak pricing once you build out more value for your customers, instead of paying a bunch of people silicon valley salaries to figure out if 25$ per user vs 26$ per user is better.
We definitely want our service to be available to lots of students and to help them learn. But pricing it too low can not only leave money on the table, but actually make our product less valuable. Why? When you pay for something, you want to make the most of it. So our students have an even bigger incentive to keep learning. If it's too cheap, it loses its value, and in a way becomes less useful.
So we try to tier prices and offer a much lower price in developing countries for example. But we still want to find a "sweet-spot" for our main customer base, so people feel that they get value, but also that it's not too cheap so they stop caring about it.
Pricing experiments aren't always evil and the motivation isn't always to grab as much money as possible. Plus, don't forget that you can maximize profits by lowering prices in lots of cases. But you need to be able to test it to find out...
It would look something like:
1. Use historical price data to determine the optimal price for each customer given what we know about them. 2. For a small number of customers (<10%), randomly adjust prices slightly to find additional data.
Once we have the data, we could find the price elasticity for customers (elasticity = % price increase / % change in purchases; so if elasticity is > 1, it makes sense to increase prices, if elasticity is < 1, you should decrease it), and use that to increase prices.
We did a few experiments via email, where we offered a different discount to different cohorts. For example, some people will get an offer for 20% discount, and others for 40%. We tried to extrapolate pricing elasticity from that, but it's still hard... We have a few ideas for other experiments, but didn't get round to it yet. It's one of the areas we need to be more careful.
I'd be happy to talk to you and try to understand what you have in mind. (I didn't quite). Hope it's ok to contact via the contact details on your profile? (Or feel free to reach out to me.).
Your time is worth something, and customer support is a very real burden. In the case of a $10/month user, answering one customer support email more than wipes out all of the revenue you've earned from them that month.
1 customer is a high risk.
10 are better.
But 1000 are Bad again?
If only one in 100 customers sends a support request, you can spend an hour to answer it, and you still made a lot of money even if each user only pays $10.
These are not mutually exclusive choices.
"As Douglas Rushkoff says, we need a new operating system for startups. The current one will keep producing the same extractive and monopolistic empires we’ve gotten so far. No, what we need is a new crop of companies that are institutionally comfortable with leaving money on the table. Leaving growth on the table. Leaving some conveniences and some progress on the board, in order to lead the world into a better direction."
https://m.signalvnoise.com/exponential-growth-devours-and-co...
I go back and forth on this one, since I have both $10 and $300 plans.
One one hand, it's frustrating to watch those $10 plans trickle in every day, barely making a dent in revenues. Fortunately, support needs are pretty low for my product, so more customers doesn't necessarily mean more work. And at least it's not a big deal to lose a customer (especially a high maintenance one).
On the other hand, while it's really cool to get the email announcing a new $300 signup (which translates directly to a $3k/year raise in my salary), it hits pretty hard when one of them leaves.
I think it'll always be a case of "the grass is greener".
From the app from the article: 40$ per user / per month - 10 people startup => 5k a year - 100 people startup => 50k a year
When it becomes too expensive you only have a few options: - keep the heavy users in and remove other people from the service - have a shared user for people that don't use the service that often (If identity is important, who did what, then this becomes confusing) - move away from this solution, consider competitors
SaaS companies should consider medium to large companies and think about pricing caps, light agent roles, etc.
For example: the first 100 actions are free for each user, after that one simple fee is applied of 40 per month / per user. I don't know what is a proper solution yet.
For those prices, we can hire a full time employee just to be the admin for your service and get them doing more productive things on top of that. Charging per user is not sustainable when you get into the higher numbers, so we'll look at alternatives, host our own services long term, and/or hire a dedicated admin.
Apps are also a bit different requiring more b2c orientation and simplicity - at least with my limited resources. I chose what I felt was an unique way to capture user confidence via temporal "tiers" - monthly, quarterly, and annually with discounts per.
I think I chose a decent discount as I have a relatively even subscription distribution - challenge is - it's near impossible to model MRR, Churn, LTV when Apple limits the data and strips UUID from subscription.
My only issue with it is that you never actually outline a methodology for working out the main problem you highlight other than just do it. It would be helpful if you quantified (perhaps using %'s rather than hard figures) this trade off.
" A lot of people fear changing pricing too often because they think it will scare away their customers. And for some—that might be true. But never experimenting with your pricing means you may never learn the value of your product and its potential for growth. "