M4 - Saas Pricing Models
M4 - Saas Pricing Models
M4 - Saas Pricing Models
PSYCHOLOGICAL HACKS.
There are three crucial components of a profitable SaaS pricing strategy:
the pricing model is used to balance value and revenue.
the pricing strategies is used to achieve the growth goals.
the psychological pricing tactics is used to fine-tune the price.
Price scales alongside usage. It makes sense to correlate usage and price: if you
have volatile demand, and use less of a service in a given month, why should you
expect to pay the same amount as a boom month?
Reduces barriers to use. There are no big up-front costs with usage based pricing,
and even the smallest startups can get started with your product, safe in the
knowledge that prices will only increase alongside their usage.
Accounts for "heavy user costs". With fixed price packages, there's always the
risk of "heavy" users taking up a disproportionate amount of your delivery resource,
without compensating for it with increased spend.
Disconnects value from the product. Do your users really care about the number
of API requests they generate? Or do they care more about seamlessly integrating two
crucial pieces of software?
Flat rate and usage based pricing are relatively uncommon in mainstream SaaS, and it's tiered
pricing which is the de facto model used by most companies. At its heart, tiered pricing
allows companies to offer multiple "packages", with different combinations of features
offered at different price points.
The average number of packages on offer can vary hugely, but the average clocks in 3.5 -
often geared towards low, middle and high price points.
Leave less money on the table. By appealing to multiple personas, you can
maximise the revenue generated from different types of customer: offering a single
$100 package will overcharge users with a $10 willingness to pay, and undercharge
users willing to spend $200.
Clear upselling route. When your customer outgrows their current package, there's
a direct route to the next price point.
CONS OF PRICE TIERING
"Heavy user risk". If top tier users regularly exceed their allocated service usage,
you have no recourse for collecting extra revenue to compensate.
Spend a few minutes browsing pricing pages and you'll come away with the impression that
Per User Pricing (also known as Per Seat Pricing) is the go-to SaaS pricing model.
Pacific Crest's annual SaaS survey backs-up these findings: across the companies surveyed,
per user pricing was the most popular pricing model used:
This popularity can largely be attributed to simplicity: a single user pays a fixed monthly
price; add another user, and that price doubles; add a third user and, you guessed it, the
monthly cost trebles.
This makes it extremely easy for customers to understand what their monthly subscription
buys them, and easy for SaaS startups to manage and predict their revenue.
For an archetypal use case of per user pricing, look no further than road mapping SaaS
Product Plan. The only variable in their Business Plan is the number of users added to the
account, and the per use price is the same, whether you're a single user or a team of 100.
Simplicity. Per user pricing is one of the simplest, most direct pricing models,
making it easy for would-be customers to calculate monthly costs: great for users, and
great for simplifying the sales process.
Revenue scales with adoption. With this pricing model, revenue scales directly
alongside adoption: if you're able to double the number of users within a company,
you'll be rewarded with double the revenue.
Predictable revenue generation. SaaS companies are reliant on the recurring
revenue model, and per user pricing makes it easy to calculate and forecast each
month's revenue generation.
It limits adoption. By charging per user, you provide a reason to avoid adding new
users to the tool. This also provides an incentive to cheat, and wherever possible,
share a single login between multiple team members.
It makes it easy to churn. By limiting adoption, you also make it easier for
customers to abandon your service. After all, who's more likely to churn? A team of
100 people using your product, or a team of 10?
One variant of the per user pricing model is active user pricing. Many SaaS companies
(particularly those targeting the enterprise) encourage yearly billing cycles. This can mean
that a new customer could pay for hundreds of employees, up-front - without any guarantee
that those employees would actually use the software.
Per active user pricing tackles this problem head-on, encouraging customers to sign-up as
many users as possible, with the safeguard that only active users will actually be billed for.
Slack are the most famous example of this SaaS pricing model: no matter how many users
you pay for, you'll only be charged for those that actually use the software.
At Slack, you only get billed for what you use. So you don’t pay for the users that
aren’t using Slack. And if someone you’ve already paid for becomes inactive, we’ll
even add a prorated credit to your account for the unused time. Fair’s fair.
PROS OF PER ACTIVE USER PRICING
Customers only pay for active users. This means no money is wasted on unused
seats: customers only pay for what they actually use.
Doesn't work so well for SMBs. This pricing model works great for improving
adoption in enterprise organisations, but when cash is tight and team sizes are small,
per active user pricing doesn't offer much extra incentive to bite the bullet.
For the previous two SaaS pricing models, users were the common variable, but it's
completely possible to use features as your value metric instead.
Per feature pricing separates out different pricing tiers according to the functionality available
in each, with the higher priced packages associated with a greater number of available
features.
PER FEATURE PRICING EXAMPLE
The primary differentiator between Evernote's Basic, Plus and Premium packages is the
different range of features on offer, with new functionality "unlocked" with each upgrade.
Difficult to get right. How do you know which features your users will want?
Getting the balance wrong can discourage adoption, as crucial features end up in
overpriced tiers, or the bulk of your product's benefit ends up in your cheapest
package.
Leaves a bad taste. It's easy to feel resentful with per feature pricing: you're paying
a monthly fee to use a product, and still, you're missing out on some of their
functionality.
7) FREEMIUM BUSINESS MODEL
Thanks to high-profile success stories like Slack, Evernote and Dropbox, many SaaS
companies use freemium pricing: offering a free-to-use product, supplemented by additional
paid packages.
The freemium business model is typically used as part of a tiered pricing strategy: the regular
paid packages are supplemented with a free, entry-level tier.
That tier is then limited across certain dimensions in order to encourage users to upgrade at a
certain level of usage, typically employing feature-based (if you want X feature, you need a
paid package), capacity-based (if you exceed your allowance, you'll need a paid package) or
use-case (you can use the free package internally, but not for managing customers)
limitations.
Their "Free" package allows small companies to talk to their first 100 contacts for free: when
demand for the service increases beyond that point (most likely correlating with company and
revenue growth), it becomes necessary to upgrade to their paid packages.
Viral potential. With such low barriers to use come significant viral potential:
companies like Dropbox grew so rapidly because of user referrals, as their existing
users passed on the product to friends and colleagues.
Freemium is a real revenue killer. Free users don’t generate any revenue for your
company. This means that your paid users need to generate enough revenue to support
the cost of acquiring and serving all of your users - paid and free.
It's easier to churn on a free package. The more we pay for things, the more we
value them. While a free-to-use version of your SaaS product makes widespread
adoption simple, it also makes it easy for users to adopt a throwaway mentality,
increasing churn as a result.
It can devalue your core service. If your product solves a painful, expensive
problem for free, your users have may resent having to eventually pay for the service.