Does anyone have experience with how conversion rates are affected by these different pricing schemes? What are the pros and cons you've encountered with each approach?
-at the early stages, usage models didn’t work for us because it attracted customers who were uncommitted to using the product
-the advantage of a subscription is that it filters out people who just want to use something occasionally (which is fine once you’re huge, but at the beginning you want people who are committed)
-I found it impossible to make enough money on the usage model. It’s maybe great for users but if you go out of business your users won’t be able to use it anyway
-we do automated real estate reports. When we charged per report people ran a lot less reports and tended to be stingy about running them. We wanted to encourage users to use it so an unlimited subscription made users happier, even if it meant their per report cost was higher. Also, we got tired of people computing the cost of a report mentally. Since the margins per report are good, an unlimited subscription works much better.
-once you reach a certain size having free and lower usage tiers can be a good thing but first you need a bedrock of recurring revenue that you can count on. Unless you have boatloads of VC money to burn.
-this will vary greatly depending on the specifics of your product. For example, developer tools that are easy to test out, but require a credit card to go to production make a lot of sense, but that was not us.
-if you can sign up very large customers that you know will use it a lot, usage models can make sense. But this requires a really really good product that already has PMF and requires that you can sell to mid market or enterprise customers and the sales cycles can be long. You can easily go out of business waiting to sign those customers.
Subscription pricing works best for end-user tools that help a certain function do their job better (ongoing). Why? If your target customer has to ask their boss for more budget every time they want to use your product — your business is dead in the water.
1. It aligns to my costs, so I'm not too worried about abuse.
2. It allows servicing "small" users, there is no need to jump onto a recurring plan. You can just buy one package of "credits" and use it for years (or even just coast quite a while on the free trial).
However I think there are downsides with the usage based pricing as well:
1. It discourages using the service. If each use costs money it is a small hurdle to clear. Even if it is cheaper most users will "feel better" with unlimited or pre-paid packages as they are using what they paid for.
2. Predictable cost to the user.
3. Can often be more profitable, especially for small users.
If you use their smart cards to pay for your tickets then they cap your daily spending at $10 (the price of a day pass) and your monthly spending at $50 (the price of a monthly pass). In effect they notice if you would have been better off if you'd have bought a day pass at the start of that day or a monthly pass at the start of the month and retroactively convert you to that.
However, I personally prefer approaches, where not every request gets charged but instead having "packages" with a discount on every step, e.g.:
- 2000 Requests -> 2$
- 10000 Requests -> 8$
- 100000 Requests -> 15$
- unlimited Requests -> 69$
If your costs don't vary a ton with usage, it could be better to offer subscription pricing. If need be you can offer tiers that support different levels of usage. You can also feature-gate other aspects of your product, so it doesn't seem like you're pricing based on usage per se. Rather, you'd be charging more for customers that need SSO, more than X seats, SLAs, etc.
I will say that one downside to having minimal marginal costs is that some customers will bristle at paying value-based prices. They'll think that if your cost is minimal then they shouldn't be paying much for your service.
It's really interesting to read all the different perspectives shared below. We each have our unique portal onto the pricing landscape, and seeing what others have learned, and how they put their perspective into words, is quite enlightening.
Usage based pricing works well for customers who value flexibility more than predictability, and subscription pricing works well for those that prefer predictability (and probably want a discount). It makes sense. Customers in the first camp are growth oriented or otherwise undergoing a transformation of some kind. The latter group has stable operation and is looking to optimize.
Usage based pricing should be more expensive than subscription pricing to make up for the lower value multiple it gets should you raise or exit.
Usage-based comes with more work in the short-term: more internal metering, controls for bill-shock, observability so users can see usage by billing vector, pricing/marketing work to help users understand their expected costs for different workloads.
We use a subscription model, which price depends on a very fixed metric of the customer. Think number of rooms in a hotel, it usually never changes.
Not based on users, as that might constantly change and we don’t want customers to think about, if the new employee gets an account or not or has to share it with a co-worker.
Subscription based revenues are more predictable, the user knows the price in advance, the user can easily clear the fixed budget with superiors, the accounting department knows what to expect every month, no one gets a bill shock, no one needs to worry about usage and budget.
We have like no variable cost, so we don’t worry about high usage.
It of course depends on the product and your target group, this works very well for us and our customers.
But the most important thing is to get the product right.
Do you already have customer prospects you could ask? Are they more concerned with a runaway bill or paying for subscription services they end up not utilizing?
Could you find a sweetspot in the middle? (“You only pay $3.14 for the days when an employee use the service” or “You pay for the usage, but it’s very transparent and predictable pricing, we’re not AWS”)
Baking in flexibility on delivering features packaged and priced differently becomes an unfair advantage.
Aligning pricing plans with feature flags can also help.
This might sound like additional work to the startup.
I would ask if you see your SaaS as a billing platform around features, or features that can't bill.
Billing will always evolve around clients in different industries, verticals, etc.
I have a targeted approach I have used many times before, happy to chat offline.
* What does the product actually do?
* What do they get for a "use"?
* If the usage-based pricing is an add-on, what value does the product provide without it?
FWIW, I think that the conversion would be fine either way. If you haven’t already, it might be worth adding a free tier.
The data from the free tier then could answer the questions around what is a more effective model for your app. You’ll want to see healthy margins and you’ll want to mitigate for abuse that you actually see in the data from the free tier.
I landed on a hybrid base subscription with guaranteed usage and usage based pricing past that
SaaS = more secure reoccurring revenue. Slow revenue growth. But highly predictable.
You can have the best of both worlds with tiered pricing. $20/month for x usage, plus $y for overages.
Imo subscriptions are an easier sell, since it’s more predictable.
Subscription with a free tier, and usage based pricing above a certain amount.
We find our customers (mostly education sector) flat out could not get variable pricing approved. There's probably many other teams and sectors in that boat.
That said, flat rate pricing is sooooo much easier to deal with... Especially if you want to pass through the cloud costs, and not use your own "usage determination"
So in the beginning it doesn't matter. Maybe later it will, The only way to know is to pick one and see what happens.
Success and failure will be determined by the quality of your customers and the scale of your knucklehead mistakes. Your sales contract is rounding error. At Good luck.
A general piece of advice: identify the closest measurable factor(s) to "the more I do $X, the more business value I get out of the service."
For example, if analyzing more data improves business outcomes, consider usage-based pricing (e.g., GBs of data). If the value comes from sharing with other departments or collaborating, then these features could be part of a pro plan, or you might use per-user pricing.
Another important point is that it's usually better to have a customer pay nothing (e.g., a free tier or a 50/50 chance of converting them to a serious plan) than to have a customer who pays inconsistently, such as $0.75 one month, nothing the next month, and $1.10 the following month. These customers are problematic; they'll demand support and play the "I'm paying" card, and you'll incur card processing fees. Avoid this by setting a minimum charge or offering a small free tier to attract users who might pay later.
This is what I often end up at honestly, but it may not suit you;
Lets say each $thing is 1 cent.
Free trial Requires card, 14 days with 1000 credits (encourage urgency to evaluate now, not later - many eventually forget), customer pays with card for anything over the 1000 in those first 14 days - but is not auto charged for a standard plan on trial end. They are then emailed to encourage conversion or the account will be deleted 30 days from trial end (encourage urgency, keep a clean platform/GDPR compliance).
Standard $20/User/Month - each user gets 2000 non rolling over credits per month, but that is aggregated at the org level e.g an org with 5 users gets 10,000 credits. Additional credits are 1c.
Pro Additional features. Depending on how much value those create you either tack on a $featuretax e.g add $10 a user, or if they are just low value nice to haves/quality of life when dealing with large volume, then trade them for a higher minimum volume so $50/user/month gets you 5000 credits per user.
Anyone who does serious volume come talk direct, but they get a discount in exchange for contractually committed usage.
-Always possible to alert on overages at an account level (100% alert to main contact should be default), cap is usually appropriate too.
This model gets you a load of stuff for free, mid volume users can add extra users for free, or choose extra nice to have features instead or aswell. A minimum charge is instituted per user, regardless of thier usage. User is not feeling like each click costs money "It's included", at least until they're using your platform in volume at which point "they're in". Door is open to doing enterprise/high volume deals.