Pricing is one of the most heavily debated topics in the SaaS world.
Not just how much to charge but what pricing model to go with. Do you charge per user? A flat rate? Some oddly complex credit system?
In the early days of selling software (and transitioning into SaaS), per user pricing was pretty standard.
But over time, companies realized that charging per user doesn’t always make sense for SaaS and could even limit growth. Some people even consider per-user pricing one of the worst pricing models.
On the other hand, plenty of companies happily charge for every user a customer adds to their account, and they’re raking in millions in MRR.
So, is per user pricing as bad as some think? Or is it a missed opportunity for growth? Read on to find out.
As the name suggests, per-user pricing involves charging customers based on the number of users (or seats) they add to their subscription.
For instance, you might charge $10 per user per month. The more users the customer adds, the more they pay.
Despite the negative reputation per user pricing gets, plenty of companies use it.
Slack (we’ll talk more about them later) has two plans: Standard and Plus. Each has its own price per user.
Salesforce offers many products and pricing options, but they stick to the per user pricing model for most of them.
Notice the fine print. They cap the number of users you can have in the lowest priced plan to 10 users. After that, you’ll have to upgrade to the next tier.
Lastly, let’s look at Asana. Like Salesforce, they offer multiple plans, each with a different price per user.
The interesting thing about Asana is that they have a free option. However, that free option doesn’t have unlimited seats.
Once you have over 15 users on your team, you’ll have to upgrade to at least the Premium plan. That brings me to the next point—the downside of per user pricing.
At first glance, per user pricing might sound tempting. The more users your customer adds to their account, the more money you get. Yay, expansion revenue!
Except it’s not that clear cut. There are some important things to keep in mind before you go with per user pricing that might make you reconsider.
Returning to the Asana example, let’s say you’re a small business using the free version of Asana for about a year. You’ve added 14 users to your team, and now you want to add three more, bringing your total to 17.
That would put you over the 15-user limit for a free account. Now, you go from paying zero to $229 per month or a lump sum of $2241.96 if you make an annual payment (and that’s assuming you don’t add any more users to your account).
That’s great for Asana. But for the customer, it can be a little frustrating. Even if you make it known that the price increase will happen (like Asana does), the price shock is still there.
Even if your customers aren’t switching from a free account to a paid account, price shock can still occur with per user pricing. Let’s take a look at Salesforce again.
Their Essentials plan starts at $25 per month. But once you get up to 10 users, you’ll have to upgrade to the next level, their Professional plan. And that’s $50 more per user per month. So let’s say you go from 10 users to 12; the price you pay per month more than triples:
| Essentials | 10 users | Professional | 12 users | |
|---|---|---|
| Price per month | $250 | $900 |
This can understandably create some friction for customers. Luckily there are ways to combat this, which I’ll explore later.
One of the most popular arguments against per user pricing is that “number of users” isn’t a value metric for most companies.
A value metric is the metric your product’s pricing is based on. Take our dunning management tool (Recover) for instance. Our value metric for it is MRR.
The amount you pay for Recover is based on your MRR because the more revenue you have, the more potential revenue you lose from failed payments.
As our customers’ revenue increases, so does our expansion MRR, which leads to growth.
Now imagine if we were to use per user pricing for Recover instead. It wouldn’t make sense. Even if we were to charge $100 per user for Recover, our growth potential would be cut dramatically because there’s not much value in people adding more users. They could all share the same password.
Whether a customer has 1 or 20 users, they don’t necessarily get more value from those additional users.
With per user user pricing, your growth becomes dependent on the number of seats you can sell. And at that point, it’s almost like retail, which eliminates a lot of the benefits of the SaaS business model.
To work, per user pricing almost always needs to be combined with another SaaS pricing model.
In the examples we’ve shown, the companies aren’t relying on just per user pricing. Slack and Asana come the closest but have multiple plans with added features.
Salesforce has different plan levels as well as add-on products and services.
Like most things in life, there are exceptions. For instance, SEO Powersuite strictly charges per license.
But they’re an outlier. When you look at their competitors, very few if any only use per user pricing.
I know, so far it probably sounds like we’re completely against the idea of per user pricing. But there are some instances when this pricing model does make sense.
Per user pricing isn’t all bad for SaaS companies. Here are some situations where it makes sense.
If you sell a product that benefits from having multiple users, per-user pricing can make a lot of sense. This is typically the case for team-based SaaS products.
Slack is one of the best examples of this. Nobody’s using Slack alone, and it’d be weird if you were.
However, Slack doesn’t just charge per user. They charge per active user. What that means is you only pay for users that are actively using Slack. Here’s how they define active and inactive users:
This is the best-case scenario for companies that charge per user. The problem is that Slack isn’t the norm. In most cases, SaaS companies charge for all the users added to a customer’s account, regardless of whether they log in or use the product at all.
Project management software is another example of when per-user pricing makes sense. Asana, Trello and Monday all have some form of per user pricing.
Since people collaborate on projects with these tools, they can justify charging per user.
CRM is another example. With CRM software, multiple people can add contacts, collaborate on deals, and manage customer relationships.
Tools like Pipedrive, Insightly and Streak all have per user pricing for teams.
Again, the key is that the extra users need to have added value to use this SaaS pricing model. I’ll discuss this further when I discuss alternatives to per-user pricing.
The takeaway
If you have a team-based SaaS product, charging per user could make sense. Just make sure there’s enough value added to justify the price.
If you look at most of the companies that use per user pricing, you’ll notice a lot of them are targeting enterprise or mid-market customers.
It’s not a coincidence.
One survey from KeyBanc found that 33% of SaaS companies chose “number of seats” (or users) as their primary pricing metric.
That number shocked me, so I wanted to see what type of businesses were surveyed.
When I looked further, I saw that most of the businesses surveyed were enterprise/mid-market focused.
Since enterprise SaaS companies target larger customers, these numbers make sense. Larger customers mean more potential users, which equals more revenue when you’re charging per user.
The takeaway
If you don’t fall into one of these two categories, relying on per user pricing might not be the right growth path. There are exceptions, but for most SaaS businesses, there are more efficient ways to price your product for growth.
If you’re looking for a way to price your SaaS product without only charging per user, plenty of other options exist. We even wrote a guide: SaaS Pricing Models & Strategies Demystified.
That article dives deep into seven different SaaS pricing models, so I highly recommend checking it out.
For now, I’ll go over three options that can get you similar results as per user pricing but without some of the downsides.
One of the appeals of per user pricing is that it allows your revenue per user to grow over time. But it requires your customers to add more seats in order to do it. A good alternative is usage-based pricing.
That’s when you price your product based on how much customers use it. For example, EmailOctopus charges based on the number of email subscribers you have.
Stripe charges a percentage of each card charge. So, the more their customers bill, the more revenue Stripe earns.
Just like per user pricing, your average revenue per user (ARPU) should grow over time with usage-based pricing.
This pricing model works better for some businesses than others. But if you have a way to price your product based on usage, it’s well worth a try.
Start by defining your value metric. Your value metric should be based on where your customers get the most value from your product. For EmailOctopus, that was the number of emails sent; for Stripe, it’s the number of transactions that can be processed.
There’s a good chance you already know what your value metric is. But if not, you can look at product usage data or even survey your customers.
A good litmus test for whether or not you chose the right value metric is how simple it is to understand on a pricing page.
For instance, on our pricing page, it’s super clear that our pricing is based on your MRR.
But if you look at the pricing for Keap, it’s not quite as clear what the value metric is.
Once you’ve defined your value metric, figure out how you can build your pricing around it. It could be a sliding scale like ours, per action like Stripe or buckets like EmailOctopus. It all depends on your business.
If you’re set on charging per user, you’ll probably have happier customers if you go the Slack route and only charge for active users.
You can use a tool like Servicebot to set up per active user pricing if you use Stripe.
This pricing strategy is helpful if you sell a product intended for use by entire companies or departments.
For instance, employee advocacy software like Bambu or Sociabble is usually priced based on the number of total users. However, many times, all the users who were added to the account don’t use it long term, so the customer ends up paying for non-active users.
Sure, you’ll earn more money if you charge for all users (at least in the short term). But from my experience, companies don’t tend to pay for unused software for long, particularly if the price is high.
If you want to keep customers long term (which you should if you work in SaaS), you might want to consider pricing your product to encourage them to stay.
This is a happy medium between charging per user and value-based pricing. Instead of focusing your entire pricing model around the number of users, you choose a value metric that makes more sense and then offer additional users as an add-on.
This pricing strategy makes much more sense for most SaaS companies, particularly if your product isn’t strictly team-based.
A good example of this is Ahrefs, which recently added an option to pay for for additional users.
Their value metrics are all related to SEO analysis, so basing their pricing strategy on the number of users doesn’t make sense.
At the same time, having an entire team share one password and account can be an issue for some companies, so they can add additional users as an add-on. That creates an opportunity for expansion revenue for Ahrefs.
This approach makes sense when:
The value customers get from your product doesn’t depend on how many users they have on their account, AND
There is some value to having extra users to a customer’s subscription
If charging for additional users is solely to increase revenue, you might want to rethink your decision.
There you have it. The good, the bad and ugly side of per user pricing.
Per user pricing isn’t quite as bad as some people make it out to be. But for most SaaS companies, there are better pricing models out there, and more effective alternatives like the ones I mentioned.
So, the answer to the million-dollar question: “Is user pricing right for you?”
… it depends.