I tested how Mechanical Turkers (N=~400) chose plans on pricing pages with 4-tiered subscriptions plans, for both a file sharing service and a payroll software service. Each respondent was randomly assigned to one of 4 conditions, where the presented pricing page was slightly different. The scenario was framed as choosing a SaaS plan for a company they're employed at.
The first variable I varied was plan order. Half the respondents saw a pricing page with plans in increasing price order (cheapest first), the other half in decreasing price order (most expensive first). There was a statistically significant difference between the plan choices for these groups; respondents in the most expensive plan first condition chose a more expensive plan. This phenomenon has been seen before outside SaaS, and it's called the price order effect.
Another variable I tested was exchanging the cheapest ($5) plan for a free plan. Half the respondents saw a free plan, the other half a $5 plan. There was no statistically significant difference in the plan choice for these groups.
Getting familiar with previous literature, I would surface a couple of general thoughts:
- The most expensive plan first approach may give the visitor a more expensive image of the product, a higher "reference price". If a prospective customer is comparing two products from two different companies, they may favor the one that seems cheaper (has a lower "reference price") even if the offerings may provide similar value.
- The hypothesized mechanism for the price order effect is that you don't look at all the options as a whole, but you begin by assessing the first option, which is the leftmost one for us reading left-to-right, and then judge the next option by comparing it to the previous one, and so on. You compare added (more features/less cost) and lost (less features/more cost) value. Because we weigh losses heavier than benefits, there's an inertia toward the initial options. Only options with benefits that greatly outweigh losses combat that inertia. Hence respondents tended to choose plans more on the left.
Is that somehow possible to share your your thesis? I'd love to read end to end.
Similar to how few people would put their first application out in public, I prefer to keep my thesis private unless someone finds the information really useful :)
What do you recommend for pricing in SaaS before reaching product market fit?
Pricing is highly specific to the product and the market, so it is hard to give general advice.
But if I were to give general advice, I’d say that we see far more SAAS startups underpricing their product than overpricing.
The problem with overpricing seems obvious—we in our daily lives as consumers are more likely to buy products if they are cheaper, and so pricing higher is presumed to reduce sales.
But that’s not how business markets tend to work—in business markets, where customers make what’s called a considered purchase, the result of a reasonably objective and rigorous analysis of options, startups that underprice tend to have the problem I call “too hungry to eat”—by pricing too low, they can’t generate enough revenue per deal to justify the sales and marketing investment required to get the deal at all. In contrast, by pricing higher, the startup can afford to invest in a serious sales and marketing effort that will tend to win a lot more details than a competitor selling a cut-rate product on a shoestring go-to-market budget.
TLDR: When in doubt, double prices. :-)
The screenshot in the article is actually the updated pricing, after I followed advice from @patio11. Here's a screenshot of the original pricing: https://imgur.com/a/3JtUU
That was definitely too many plans. I also really like the copy suggestions, and have started using that in some AdWords campaigns: "Save weeks of development work on PDF generation; fits easily in the budget for any project."
Thanks a lot for the help!
You could just have one metered plan and show how usage gets cheaper the more you use it.
• 0 - 100 PDFs: $0.20 per PDF
• 100 - 1,000 PDFs: $0.10 per PDF
• 1,000 - 10,000 PDFs: $0.05 per PDF
• 10,000 - 100,000 PDFs: $0.02 per PDF
• 100,000+ PDFs: $0.01 per PDF
I don’t like that the customer is invoiced at the end of the month, instead of paying at the beginning. I was worried that someone would generate a lot of PDFs, and then their card would be declined. I might have spent a lot of money on hosting and wouldn’t be able to collect payment. For brand-new customers, I could also collect payments at certain intervals (E.g. $50, $100, $500, $1000, $5000.) After 2 months, I could trust them more and just have one charge at the end of the month.
I could continue to have monthly plans with quotas, and add the pricing tiers based on usage. If a customer knows that they will generate at least 100 PDFs per month, then they could pay a discounted rate at the beginning of the month, and save 30% on the first 100 PDFs.
I was also thinking that customers could buy “credit packages” at a discounted rate. This would useful if they are running a one-time batch job, and wanted to get a discount for the next 1,000 PDFs. The credits would also roll over to the next month, and I don’t think I would set an expiry date. I paid for some credits on KeyCDN, and it was really annoying when they expired after a year.
I’ll continue to think about this and A/B test different pricing over the coming months.
An excellent question! Net on net, removing the CC required upfront decreases conversions in the early life of startup,
until you’re sophisticated with regards to onboarding, in-app messaging, lifecycle email, and reachout by a customer
success team. I would not suggest you remove the CC required from this free trial.
Name pricing plans to sell them to the right users
And make sure the names make sense to them, not you. One thing I hated about buying from Dell was I had to decide if I was a small business, medium business, consumer, etc. Who do I know? And does my choice give me a worse price?
Most people in that situation will not be deterred by having to enter a credit card for a free trial. And those are the customers you want.
You always have recourse against fraudulent activities - the credit card company will just reimburse
Talking 3 man business, not 4000 person enterprise.
If I want to buy something I'll put my credit card info in wherever it's asked for. If something happens that's why I have a credit card. Their problem not mine.
I've done it across multiple websites, and combined with a half-decent call to action and a quick signup (just 3 fields) you can convert pretty easily.
Personally, my website conversion is ~2% which is pretty good:
Prior, when I had two options the conversion rate was ~1.5%. Now the sample size is only ~25k (12k for each) so take from it what you will...
In terms of pricing/value, you should already have estimates of value for different customer sizes/use-cases and put together prices based on those estimates. On the call, it's your job to learn as much as you can about their problem so that you can determine how best to solve it with the products you offer and where it falls on your pricing scale.
Don't do on-prem unless they pay you a boat-load more and SaaS isn't an option they're willing to consider. It's way more of a headache.
NDAs are usually fine, but better to pay a lawyer a couple bucks to throw together one for you and try and use that one all the time rather than having to review a bunch of different ones coming from other companies.
Travel is case-by-case. Definitely not necessary for just a quote, and not strictly necessary for sales if your video demos/sales calls are on point, especially if your customers are tech-inclined.
Interesting, I would have said $X.87 is still the best strategy when talking pricing/extracting value, even for B2B.
I've seen $X.99 versus the $X but never $X.87
I had to chuckle a bit. So you want some science to discredit the idea?
Can you do an article on reaching out to SMB's and selling them a SaaS? I know most SaaS that sell to SMB's actually do a lot of sales over the phone, but I'd rather not spend my whole day on the phone. (I am thinking about creating a SMB SaaS that solves problems for the retail stores we run now.)
Is there really an "enterprise" channel where you can go and find all enterprise businesses? Or s single "consumer" channel.
Look at all the SaaS companies that sell to SMBs. The marketing channels are there, but you have to find the channel that suits your market.
Startups aren't the only type of business where the people within them congregate in specific areas. So you just have to find those places for your specific customer profile.
The SMB marketing channels are surely there, but they are small and distributed, so they require much more manual work than regular channels.
The pricing is currently per user, since I've envisioned it as a tool that you'd invite all your developers onto. For the most part, this has been the case, but there are some companies using it heavily on the server-side and only inviting a small number of users.
To account for this, I've considered charging a small amount per access key (say $2/mo for a base plan) instead of per user. A typical app has an access key for each developer working on it, plus one per server, so for a team of 5 this would work out to ~16/app/month (assuming test, staging, and production server environments; some have more). Most teams seem to have at least a few apps; some have as many as 10.
The good thing is this would scale up with usage, starting very low and then getting pretty substantial as you get more and more use out of the product. The bad thing is... it would scale up with usage, and therefore might disincentive heavy use.
1 - https://www.envkey.com
I think per developer is more fair and still a good approximation of buying power and utility.
You can have small teams with large per capita usage, and large teams with low per capita usage. You ideally charge a price that each customer is happy with and that makes sense for your business. If you can't survive with 100x or 1000x as many customers at this pricing tier, you either take it off the price list immediately or when you get n additional customers of this tier (if you're still testing for product market fit).
The ideal price list repels potential customers that are a bad fit for your business. Doesn't make anyone greedy or customers bad people - just that a firm has a higher cost base or a specific business/individual won't get enough benefit from the product offered.
Charging per key reduces the value in my opinion, exactly for the reason I stated above. It puts blocks at the point where the product is most useful (Adding a key).
I can live with extra cost when a new developer is brought on board. There's already a few things I need to buy to bring them on, and this is a reasonable extra cost. But adding charges when I add key adds friction exactly at the point where I want the product to reduce it.
You require large users to pay more for the same functionality, that $5/mo user gets.
I would create 2 plans:
1) Regular, $9/mo per user
2) Enterprise, $29/mo per user with some added functionality, like custom login page, branding and some user management/sub-users.
This way you will give an actual value to enterprises, that justifies paying more, while keeping smaller users happy, by removing confusing pricing.
I've been planning to add additional perks to the larger tiers over time though. For example, I'm now working on audit logs, and will likely limit the amount of history for the lowest plan (sort of like Slack).
On the per-user pricing, how do you think about the possibility of a company that signs up with just a few users but manages hundreds of servers through the product?
Even if you can't rate limit in your current release it's in the license and when you can you move people up to a higher tier. This solves the issue of charging larger customers more without them getting more value.
Unlimited number of users, files, etc should never be part of a public pricing tier. Fine for a negotiated agreement with an enterprise that has a definite period - it's a great thing to concede to close an enterprise deal and should be essentially costless. When it is in a public price list it makes larger sales much, much harder.
Keep, for example, Cloudflare in mind. They have first built their user base, and once they were used by thousands of companies, they started offering additional options, Enterprise ($2K+) accounts etc. Focus on growth first, and keep some aces in your pocket for the time your revenue will stall. This way you will be able to be innovative whenever growth is slow, and there is a possibility a competitor will show up and take your business.
I used to work at NetSuite and this is exactly how we did it, the real cost (after any consulting) is the cost of users.
We exited to Oracle for 9billion.
You can charge more for more users, there's nothing wrong with that model. The more resources you require, the more you pay.
>I’d probably increase your pricing to $99 / $499 / $2,499
Would the argument that $X.99 implies cheapness not apply to $X99 as well? I feel like 99 anything is an old psychological trick to make the customer feel like they aren't really paying $500... they are paying $499.
I think most, if not all, business customers know the x99 pricing is a psychological gimmick and since it's well known is it really a gimmick any longer? When I see $499 I immediately think $500
Great quote and great article!
"I would probably use the fact of the call and concierge onboarding to tell everyone that of course you charge for your services, just like they charge for their services, but that as a limited time offer you’ll retroactively waive one month of fees if they can commit to a 15 minute conversation about why the software didn’t work for your needs."
What is the "why the software didn't work for your needs" part? Is this meant to be a call with users who are canceling and offer to waive a month of fees if they explain why? It seems out of place under the "To demo or not to demo?" heading.
A small nitpick: there is a section called "Selling to undifferentiated SMBs", but there is no explanation what SMB is and it's pretty tough to google that.
Next time you see an unfamiliar acronym, google "define [acronym]" and you'll get the most common definition. For example, "define smb" shows the correct meaning: A small and midsize business (SMB).
I should also add that it’s a conference and a community. I’ve found the reading there to be pretty good for quick reference (I don’t really hit the site anymore) but there are some good SaaS pricing references that come up through there, too.
Out of a dozen replies, about 10% were pricing their product lower, 30% were pricing the same but taking higher margins, and 60% companies were charging 2.5x-6x more than they used to. Median was around 3.5x. So the majority of companies had marked up their prices severalfold, and only one company had lowered their prices.
In a few cases, I've taken the strategy of increasing prices over time as I've solidified and polished my offering. Discounting the product initially to gain enough usage stats to rough out edges, develop an internal support knowledgebase, and suss out unexpected use cases and user segments early on. I'm not sure if those products would have been as successful if I had charged more out of the gate and cut my teeth on those higher-paying individuals.
It would be really interesting if you could break that down even further.
When you charge a penny extra, that's all incremental margin from the customers you keep, but for the customers you lose, some of lost revenue is balanced by not having the costs associated with supporting them any more.
Pushing the most price sensitive customers out the door isn't that bad, because they're also likely to be the least loyal down the road, and maybe the highest maintenance relative to their spend.
It does make me curious though who the target customer is - somebody who's comfortable setting up a Unix CLI tool for their backups (creating a cron job etc.), yet who wants to cede bucket ownership to a 3rd party and pay a 25x markup for the pleasure? I personally don't mind having to click "Create Bucket" in the AWS console if I get to pay $3/mo instead of $75/mo on my 300GB of data. shrugs
I think it's just the wrong pricing model to have a flat rate per gigabyte. A flat rate looks simple, but far from being transparent or 'honest', it's essentially arbitrary in this case. Other than backend storage, Tarsnap's main non-fixed cost is Colin's time providing support - but that scales mainly with the number of customers, barely at all with the amount of data they're using. Thus, heavy data users are effectively subsidizing light data users, who pay far less than their 'fair share' of costs.
This may be intentional. Not every service tries to provide an optimal solution for every use case.
> it's just the wrong pricing model to have a flat rate per gigabyte.
I have no axe to grind (I'm not associated with tarsnap in any way, I'm not even a user though I have considered it) but some of the discussion here makes people sound somewhat entitled: "I want X, and I don't want to pay more then $Y for it, and any service charging more is silly/bad/ripoff".
Stating that something ins't the best choice (or even a good choice) in some (or many) circumstances is fine, but "it is wrong for me so I don't see how anyone can think that it is right" is an irritating stance.
The pricing model seems to work for plenty of users, enough that it works for the service as it has been successfully running for some time. If you think he is missing out on a huge amount of money from the users who are put off, why not start your own service priced to be attractive to that userbase, and take the profit you see that service as giving away.
> providing support - but that scales mainly with the number of customers, barely at all with the amount of data
Sometimes having lots of small customers works better than having a few large ones, even if you have a few large ones and lots of small ones. With large customers you are sometimes beholden to their whims at the expense of the smaller majority (or they expect you to be beholden to their whims and get difficult if you refuse!).
> but far from being transparent or 'honest', it's essentially arbitrary
Being arbitrary in no way precludes being transparent or honest.
> heavy data users are effectively subsidizing light data users
Only if they don't go elsewhere, which they are perfectly free to do. tarsnap is not in a monopoly position such that people are effectively forced to use it.
(I'm not intending to pick on you specifically, there are other comments I could have responded similarly to, but this post just happened to be the one that tipped the balance on my rant reflex!)
More generally, I suspect you are underestimating the number of people who tick one or more of these boxes: (a) Impressed by Colin's security chops and the security focus of Tarsnap such as its Bug Bounty program; (b) Have never heard of BorgBackup; (c) Value customer support; (d) Are worried that an open-source project would not be maintained and prefer a vendor whose livelihood depends on the product (d) Have experience with Tarsnap on previous projects; (e) Only need to store 20 Gb and for whom saving $5 per month is unimportant; (f) Have revenue in the millions and for whom $75 per month is a rounding error.
Even if there were no such people and Tarsnap's new user growth was zero, it might still make sense for Colin to triple the price of Tarsnap in order to maximise the income from existing users.
With GCP/AWS, you can copy and paste a bucket ACL that only allows PUT operations, and enable versioning to ensure nothing can ever be deleted by overwrites.
With tarsnap there is one person who can delete all your existing backups - Colin, because he owns the bucket. And he will for sure within 7 days of your account falling below a $0 balance.
That might be a feature in case you got killed in a car accident and you want some secret to be buried forever. But for me, I'm archiving my family photos/videos and I'd rather AWS keep charging my account and keep my data alive until my estate can sort out my digital data, which could take months.
> it might still make sense for Colin to triple the price of Tarsnap in order to maximise the income from existing users
And there's the rub. I don't like the idea of somebody holding my data hostage. I'll gladly contribute to a Patreon if an open source developer needs recurring support.
1. What are the benefits and market size of Tarsnap compared to other backup solutions like BorgBackup + GCP?
2. Would Tarsnap make more profit it it raised its prices?
We seem to be arguing about question 1, but Patrick's advice to Colin is about question 2. Earlier you pointed out that Tarsnap is 25 times more expensive than GCP which indicates that Tarsnap's target market is not very price-sensitive. If Tarsnap doubled its prices for new customers would the rate of new signups really drop by more than 50%?
How many people have several months, or a year, of runway on their Tarsnap account balance? Meanwhile, there have been cases of people being dead for years with their auto-pay agreements keeping everything humming along while they rot. Keep in mind that recurring payment agreements often aren't cancelled when a credit card number or expiration date changes.
Finally, AWS will give you about five months of unpaid bills before they suspend your account and delete your data. I would assume GCP has a similar policy.
This is a danger for Tarsnap.
There are plenty of data sets for which that is reasonable. There are plenty of data sets, perhaps not at your shop, where $0.24 laughs in the general direction of the value of a gigabyte. I previously used Tarsnap at a HIPAA-regulated SaaS app. The fines for unplanned disclosure are measured per-record not per gigabyte; my rough guesstimate on proration is $12 million / GB but what's an order of magnitude or three between friends.
I'll get that might not be attractive to you. You are likely not a good customer for him.
To me, it takes a lot of data and not much amount of my time to make that value proposition waaaaay worth it.
I wish I were at a place in my life where the difference between $3/mo and $75/mo ($36/year vs $900/year) is a non-issue, but unfortunately I'm not. So for now my family photos and videos will have to be securely stored with the (probably) slightly sub-par designs of the open source software I'm using.
The shift that Tarsnap needs to look at is this: how much is the company willing to pay to never lose this data X probability of data loss without Tarsnap. And then subject that number to a ceiling of hiring competent (this is very important work) developers to replicate Tarsnap.
Take that amount that companies would be willing to pay, and then divide by the actual size of the data. A company with 1TB of super valuable data will likely be willing to pay at least $X000 a year to have it safeguarded, which is really $X per month per GB.
What is the target market for Tarsnap vs G/A;
what do they offer at that higher cost that their target market wants? or is their target market simply the ignorant-to-storage-costs-CIOs/IT-departments?
Also the tarsnap feature set and security model.
The hyper unixy approach is valuable to some as well.
We can argue about whether that really differentiates them from GCP etc, but that's their spin.
If you supported the lower performance edge equipment you got more customers looking for cheap crap, trying to make it do things it absolutely shouldn't, and the customers contacting you were paid less and not that capable of helping you help them... and man were they frustrated.
Higher end data center stuff, routers for big enterprises, you got customers who spent more because they knew what they wanted, knew the product, their company had actual change control, and they were being paid more so they tended to know their stuff and were easier to work with. Granted there was pressure on the high end, but it was more professional pressure.
Within a week, we'd sold our first $995 package. This was for a B2B SaaS.
$999 (or in this case $995) meant they could whack it on their card and not go through approvals process etc.
Obviously this price point will vary with industry and time, so suss it out in your industry (if it is applicable at all).
I'm genuinely asking -
1. 999 - looks cheap
2. 998 - mmm..why not this?
3. 995 - nice number divisible by 5
4. 990 - well...why are we loosing $10 here?
5. 1000 - 4 digits might be considered expensive but 3 might not?
Trying to learn & understand selling to B2B.
500 limit? $499
1000 limit? $995
While this could sound sketchy, business absolutely love it. If that monthly charge is $1000 or $1001, now I need another level of approval and signatures.
It's certainly good advice in the right context, but it does very much depend on that context. For a B2C business, particularly one involving discretionary spending on something your customers enjoy rather than something they need, even a slight price rise can also backfire horribly, and equally a significant reduction can result in disproportionate user growth and retention and ultimately much better returns.
As far as I can tell, the best thing you can do in that sort of environment is test in your own particular situation, study your data, and be very careful about making dramatic changes that you will find difficult to wind back if they don't pay off.
When you go for the lower price point, you're getting people less in your niche and thus want more bang for their buck, or really want a different product entirely.
You’d be surprised to learn how much someone else’s money people are willing to burn, to save face.
I have often wondered if there was a business in just feature copying a well known SAAS business and selling at exactly 50% the price. The selling pitch would be "identical product, but half the cost because we don’t have the massive SV overheads." I have seen quite a few examples of this in practice, but none where it is blatantly stated.
Patio11’s argument is that most companies are charging a safe number that works, however that number is too low. By charging more, yes you will scare away some customers, but the customers who are concerned about price aren’t the customers you want.
In your case, say you cloned something like SendGrid and charged half the price. Their big customers like Airbnb or Uber effectively don’t care how much an email costs to send, they just want to guarantee that it is sent. So if you manage to score a customer like that, you are leaving a lot of money on the table.
On the other hand, the customers that do care about price are likely going to be lower quality, maybe they are sending bulk newsletters which if marked as spam will damage your company (as your IPs will end up on blacklists) - meaning more work, and more cost, cleaning up their mess.
I tend to think the mantra of charging more has gotten a little too popular and I suspect that many companies are now charging too much.
The big customers like Airbnb and Uber very much care how much it costs to send emails. The most price sensitive customers are the largest and they will try to screw you down on price much harder than smaller customers. When you are sending a billion emails the price per email is much more important than if you are sending a hundred.
Taking your example, there is no reason to think that charging less would result in more spammers using your service provided that you maintained equivalent quality controls. Spammers are probably the least price sensitive mass email customers as they are professionals who are most concerned about deliverability and ROI.
This goes both ways. You can definitely also increase net present value by pricing higher as long as value > price. Even better would be to create segmented/dynamic pricing that would maximize value capture up and down the demand curve.
If the market pricing is apparently so inefficient that a lot of potential value on the high end isn’t being captured (in economics speak we call this the consumer surplus), then this means there is also potential for arbitrage on the high end. Clone any service and charge 4X!
Probably a more useful approach to take is for the original service to do this - set up your own competitors and see where the customers go. This approach is pretty common in the non-SAAS world.
In my personal experience, I once chose a host for a game server for my friend group because it was by far the cheapest option. However, one day with only a couple hours warning the host shut down. I didn't even have a chance to download a backup. Had I been running a for-profit server, my entire business would have vanished overnight and choosing the cheapest option would have shot me in the foot. Often paying more is worth the guarantee that stuff you depend on won't vanish overnight.
The way to develop and manage those relationships would likely be very different, and that has implications throughout a company including support, marketing, sales, etc.
You should keep them on a grandfathered plan for at least a period of time and/or nag them to upgrade (optionally with a discount for their trouble).
You price your product by looking at the resources you consume. We did that initially too but it's a wrong way to price a product.
You are not taking into account that resources are available to everyone, you are simply not factoring the "luck". Don't devalue your luck, I attribute 99% of the prize we charge to luck.
Customers pay for the luck. We've made impossible possible, those who do not agree can choose a different supplier.