How we de-risked our SaaS pricing strategy(blog.frontapp.com)
blog.frontapp.com
How we de-risked our SaaS pricing strategy
http://blog.frontapp.com/2017/02/13/how-we-de-risked-our-saas-pricing-strategy/
26 comments
Big business decision makers like to pay more because it's a signal that they're dealing with someone that's going to be in business in 3 years. But their finance departments like to save money to an obnoxious degree. So charge them more per seat for enterprise features and offer them a discount that'd still more than your basic seats.
I have two questions, which are not answered in the article:
- 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?
- 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?
Sorry if this is a bit off topic, but I'm getting so tired of all those posts about how to grab the maximum amount of money from your customers. When I started selling my software, I read a lot of these articles, and was constantly stressed that I am leaving money on the table.
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?
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?
If you haven't already, give the article linked below a read. The section that I highlighted seems to fit pretty squarely with your point.
"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...
"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...
In the end a startup is still a business, and if you don't make more money, you answer to investors, or you start losing money and then shut down, which makes things worse.
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.
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're a B2C selling to students, and for us it's not just about maximizing profit or not leaving money on the table.
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...
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...
Have you done any pricing experiments? I've been tossing around some ideas about how to optimize pricing through machine learning, but I haven't been able to validate the idea at all.
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.
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 very limited experiments so far, mainly due to the fact that we feel it's unfair to offer different prices at the same time on the website. (And even if we didn't, some users might figure it out and/or complain).
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.).
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.).
I'll shoot you an email.
[deleted]
If I was a solo SaaS founder, I'd rather have 100 customers paying me $100/month apiece than 1,000 customers paying me $10/month.
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.
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.
If you are overwhelmed by support requests, one way to fix it is to charge more. Another way is to solve the underlying problem.
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.
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.
> If you are overwhelmed by support requests, one way to fix it is to charge more. Another way is to solve the underlying problem.
These are not mutually exclusive choices.
These are not mutually exclusive choices.
Is there a sweet spot for customers?
1 customer is a high risk.
10 are better.
But 1000 are Bad again?
1 customer is a high risk.
10 are better.
But 1000 are Bad again?
It's not the number of customers that really matters but the value per customer. It just happens that if you fix the total revenue for comparison, they're inversely proportional.
higher customers = less volatile risk of churn, but the volatility in churn rate for 100 customers is probably about the same as the churn rate for 1000 customers, but 10x the support burden.
Hm, then how is it that companies like Google have millions of users and virtually no support?
If I was a solo SaaS founder, I'd rather have 100 customers paying me $100/month apiece than 1,000 customers paying me $10/month.
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".
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".
Unfortunately mobile SaaS through the App Store is a pain for testing. Price updates are passed down to existing accounts last I looked.
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.
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.
Thanks for the article.
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. "
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. "
So it sounds like the takeaway from this is to A/B test your pricing. It sounds like the author has started to develop a testing culture, and that's going to pay off hugely in the future, but I would recommend adding some rigour to the testing process, doing real A/B testing rather than eyeballing it like it sounds like they're doing now. We have made this change over the last year and it has been transformational for how we develop our product.
Interesting read. How do you account for seasonality if you're comparing prices over time? Or fairness if you're A/B testing at the same time?
IMHO pricing per user / per month works well when clients are early and/or small startups, once the client has 50, 100, 200 employees then they must move out of these services because they get too expensive.
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.
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.
The trend has been to offer single-sign-on and user provisioning as the carrot to upgrade to enterprise (e.g. Slack), which nearly doubles the cost. For a 200 employee business that's $3K USD/month. Even smaller startups should be using SSO and automated deprovisioning for security. And Slack isn't going to be the only service that wants to double prices for enterprise features while still charging per user.
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.
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.
[deleted]
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.