
How we de-risked our SaaS pricing strategy - wellokthen
http://blog.frontapp.com/2017/02/13/how-we-de-risked-our-saas-pricing-strategy/
======
metafunctor
I really like the pricing model where prices are both per seat, and price per
seat increases as you add features.

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.

~~~
brazzledazzle
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.

------
ngrilly
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?

------
jakobegger
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?

~~~
aaronbrethorst
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.

~~~
k__
Is there a sweet spot for customers?

1 customer is a high risk.

10 are better.

But 1000 are Bad again?

~~~
greenleafjacob
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.

~~~
k__
Hm, then how is it that companies like Google have millions of users and
virtually no support?

------
jasonkester
_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".

------
nakovet
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.

~~~
Nagyman
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.

------
brentis
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.

------
spacetexas
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. "

------
danpalmer
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.

------
gingerlime
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?

