User pricing metrics update
Steven Forth is a Managing Partner at Ibbaka. See his Skill Profile on Ibbaka Talio.
The most common pricing metric in B2B SaaS is still per user pricing. PeakSpan and Ibbaka recently conducted a survey on pricing and Net Revenue Retention. One thing we wanted to explore was the relationship (if any) between pricing metric and NRR so we included a question on pricing metrics. The results of the survey will be released at SaaStr in September, but here are the responses to the question “What pricing metrics do you use? (Check all that apply)” N=339 as at July 16, 2023
‘Per User’ was the most common response at 128 and ‘Per Active User’ came third with 72. Looking at this in retrospect, I realize there are a lot of different approaches to user-based pricing that we could have called out. Let’s do an inventory.
Types of user-based pricing
Here are the basic types of user-based pricing.
Total number of users
Number of users registered on the system
Number of users who have accessed the system
Concurrent users (number of users accessing the system in the same time period)
Active users (with some clear definition of what ‘active’ means
Let’s look at each of these pricing metrics and see when they should be used.
Total number of users
There are some subscriptions based on the total number of users in an entity. It does not matter if the user ever access, or is even registered on the system. One might sell a subscription to a company based on an estimate of the total number of employees. One would then have a process for registering employees, activating employees, and supporting use but these would not impact price.
Before we discard this type of pricing as a relic of the old on-premise past, where we let the buyer take responsibility for operating the system, let’s pause and see if there is still a case for a subscription based on the total number of users.
There are cases where value is driven by the total number of people impacted by a system regardless of whether they use it or not.
An example, there is a system used to guide consensus in group discussions. One of the early use cases was to use it to get to a consensus on referendums on capital investments and bond issues in school districts in the United States. This system is sold in the US with the number of registered voters as the pricing metric. It can impact all voters through the conversations it sparks, not all of which need to occur on the system. This is a legitimate, value-based approach in which the total number of potential users is a good pricing metric.
Number of users registered on the system
Some enterprise applications are sold on the basis of the number of registered users. Users are often registered through some sort of automated mechanism such as a .csv file upload or through integration with SAML or some similar user authentication system.
The user can be registered on the system without ever accessing the system. The number of registrations can be the pricing metric. This is slightly more restrictive and accurate than simply estimating the total number of potential users.
It makes sense when the value of the solution is based on number of users regardless of whether someone uses the platform or not. Insurance like applications, that create value when a certain event occurs and one is not sure who it will occur for or when, often use this pricing metric.
Some platforms are collecting data from other systems and providing analytics from this data. The number of users for whom data is collected can be a meaningful pricing metric here.
Number of users who have accessed the system
Some buyers resist pricing based on registered users and want to make sure that users have at the very least accessed the system. An activation message is sent out through email (or Slack or MS Teams, I have even seen this done through SMS) and only those users who respond and complete the registration process are counted and paid for. In some cases, the registration process itself collects valuable data and provides the user something of value.
Making sure the activation process itself provides value to the user is one of the best ways to ensure successful activation and continued use. When activation is part of value creation pricing activated users can be a good pricing metric.
Concurrent users
A few years ago, OK, more than a decade ago, there was a trend to pricing concurrent users. This was a form of cost based pricing. The number of users on a system had only a small impact on costs, but the number of users trying to use it at the same time could put demands on servers and bandwidth. Concurrent users became a common pricing metric. One still sees this approach among legacy vendors who have not updated their pricing design in years.
Over time, the cost of servers has gone way down (thank you AWS and Azure) and bandwidth has become cheaper. Concurrent user pricing has faded away.
Are there cases where one might still want to use concurrent user pricing? Yes, when having two users on the system at the same time lets the interact and these interactions are key to value. This is true of many synchronous communications apps. That said, it may be better to capture that value directly, by measuring the interactions. That would be a flavor of active user pricing.
Active users
The big trend today is active user pricing.
This is part of the larger move to usage based pricing. The thought here is that if a user is not active they are probably not getting value and the more active they are the more value they are getting. At the same time, one does not want to price in a way that discourages use. A bit of a catch 22 here. Active user pricing is going to give a lower number of users, not all users will be active, so you are going to want to be able to set a higher price than with other styles of user based pricing. The way to do this is by focussing pricing on the activities that track with value.
The key to active user pricing is to focus on the uses that result in something of value to the user or the organization the user is part of (and who is likely paying the price).
The way to do this is with value paths. A value path is a series of actions taken by a user that results in something of value. The first step to active user pricing is to map out value paths. Then monetize one or two of these value paths, being careful not to do so in a way that could discourage use.
Not all users need to be priced
Ibbaka sometimes gets into conversations with companies who feel they are missing a big revenue opportunity by not pricing all users that access their system. Maybe, But before jumping to this conclusion and looking to change user pricing metrics ask …
“How does each user create value for other users?”
This is one of the key questions to be asked in user based pricing. If there are users who are creating value for other users you may not want to charge them. This is the basic idea behind Freemium pricing models, where network effects mean the more users there are the more value is created and one does not need to monetize all users. LinkedIn has done a great job creating value for users of Premium offer while supporting a large community of users who do not pay directly.
A classic example of this was Adobe PDF, where there is not charge for readers while content creators have a number of tools available to them. The same pattern can be seen at Tableau, where Creators, Explorers and Viewers all have different prices (but even Viewers pay a price).
It can make good sense to price different types of users at different levels and some users may warrant free access.
How Slack implements active users
Slack has a lot of good pricing practices. The GBB+E (Good Better Best + Enterprise) pattern is well thought out and the value positioning of each package is clear. The fencing is also good, with the ‘access to the most recent 90 days of message history’ pushing almost all business users to the Pro package.
One of the things I really like about Slack’s pricing is the way it handles accounts that are not actively used.
I still remember the first time I got a notice from Slack that Ibbaka had inactive users and we would not be charged for them. It was very different from my experience with other SaaS vendors who kept charging for applications we were no longer using and made it difficult to close the subscription. The good will created is still with me.
What user-based pricing metric should you use?
To decide on what user-based pricing metric you should use try answering the following questions.
What are the different types of user? User persona are a good way to get at this.
How does each persona use the solution to get value? (Consider economic, emotional and even social value)
How does one user’s usage create value for other users?
How does use create value for the organization the user belongs to?
How will pricing impact usage? What feedback loops exist, can you turn them into positive feedback loops that encourage use and revenue?
If you can answer all of these questions, you will be able to
Decide which types of users should be monetized
The pricing metric for each type of user
To actually set pricing levels you will need to go a bit further and develop value models. You may even need different value models for different types of users if they get value in very different ways.
Once you have pricing metrics and value models the pricing will be obvious.
Pricing Metric: The unit of consumption for which a buyer pays.
Value Metric: The unit of consumption by which a user gets value.
Value Model: A system of equations estimating the economic value a solution provides to a customer or segment. One cannot execute on value-based pricing without a value model.
https://news.ycombinator.com/item?id=36609641&utm_source=hackernewsletter&utm_medium=email&utm_term=startup_news
https://evernote.com/compare-plans