Which users are you monetizing? Which should you monetize?
Steven Forth is a Managing Partner at Ibbaka. See his Skill Profile on Ibbaka Talent.
Many Ibbaka customers have been doing user audits over the past couple of months as they prepare for 2023. They are finding a surprising number of users that they are not monetizing for a variety of reasons. Unmonetized, or weakly monetized, users are ranging from 3% to as many as 70%. Addressing this can be a big revenue opportunity independent of price increases.
Looking across these companies one finds a number of anti patterns on how they are pricing users.
User types are poorly defined, users that get value in very different ways are all treated and priced in the same way
Usage is poorly monitored, and the vendor does not keep track on users or enforce contracts
Contract terms are poorly monitored, which sounds like poor usage monitoring but is importantly different, in that customer success is not paying attention to what the contract says, this is especially a problem where sales can negotiate many different terms and discounts
Platform architecture forces poor user management, so that it is difficult to enforce the terms of the contract or track users and usage
Should you even be using user-based pricing?
Before asking if users are being properly monetized, ask if users should be monetized at all.
Too many SaaS offers default to usage based pricing because it seems typical for their category. For many applications the number of users does not correlate with value. Our own platform, the pricing and customer value management platform Ibbaka Valio does not monetize the number of users as we want to have as many people as possible using it.
Monetize users in two cases only:
Each user requires a unique view of the data or unique workflow
Number of users is a key value metric and is therefore used as a pricing metric
Value Metric: The unit of consumption from which a user gets value
Pricing Metric: The unit of consumption for which a buyer pays
So assuming that you should be pricing users, what type of users should you price?
Types of users and pricing
There are many ways of defining users.
Named User - only a named person, generally with one e-mail address can access an account, shared users are not permitted
Named Transferable User - like a named user but accounts can be moved from one person to another
Active Users - only users who have been active on the system by some well defined definition are charged, Slack was a good example of this
Concurrent Users - the number of users accessing the solution in a defined period of time is gated (I have seen these range from microseconds to hours)
Approved List - only users meeting some predetermined attributed are allowed to access the system, there are many possibilities here, ranging from emails with a certain domain name name@yyy.xxx or access through approved DNS addresses, to members of a group, or people with a provable certification and so on …
Users endorsed by other users - this seems to be a relatively new metric and is being used by communities and solutions that are growing through viral adoption
Just as there are many ways to define users there are many different pricing metrics one can apply to them. Some solutions will price different types of user differently and pricing metrics can be combined.
One can combine …
transaction or usage pricing with user pricing, such that a user gets only a certain number of transactions (and then one could make some of these transactions transferable between users
named users with concurrent users, such that only named users are allowed to be concurrent users
different user rights with different pricing metrics, not all users are the same in what they need to do or how they get value
The goal is to match the pricing metrics to the value metrics and to solve for predictability and flexibility.
Once can anchor pricing on one type of user, say Named Users, and then provide flexibility by providing a discount based on Active Users, and so on.
Pricing and RACI
One way to define user rights and match them to pricing metrics is the classic RACI matrix: Responsible; Accountable; Consulted; Informed.
One can translate this to different rights to act on the system and view data and then price each of these roles differently.
Responsible - this could be an executive user or a person responsible for designing workflows and assigning people to different tasks; this person could be priced higher than others or as they are accountable they can be a good target for outcome based pricing
Accountable - this is often the person who does the work in the application and in most applications that Ibbaka reviews this is the most common user monetized
Consulted - these users often need to comment on work done in an application, but do not need to have a unique view or to actually do the work
Informed - these users need to be able to see the work done and view reports, possibly receive notifications, but they do not take any actions or change data
In pricing designs that differentiate these types of users the pricing is generally highest for Responsible and Accountable and lower for Consulted and Informed.
A fifth type of user could be described as ‘covered.’
Covered - these users are included within some sort of boundary or fence, this is often used in pricing security-centric applications
User feedback loops and usage-based pricing
You do not always want to monetize every user. More and more companies, especially product led growth (PLG) companies, are looking for ways to encourage viral growth. You may not want to directly monetize users that are contributing to viral growth.
A basic way to do this is to provide a rebate and even an incentive to users that bring in new users.
A more sophisticated approach is to use graph theory to identify users with high centrality and give these users discounts. Of course there are different ways to measure network centrality.
Degree Centrality - is determined by the number of connections
Closeness Centrality - finds the nodes that are closest (as measured by the number of edges one needs to travel across) to the other nodes (or some subset of nodes)
Betweenness Centrality - identifies the nodes that are on the paths between nodes
Eigenvector Centrality - is a measure of the influence of a node in a network
These all represent different ways of providing value to a network of users and can all be priced differently.
We are now approaching the edge of pricing practices. Pricing by network centrality is an emerging theme and as networks, network effects and virality become better understood they will see more use.
Five things to do to improve user pricing
Do a user and usage audit, make sure that you understand all usage and types of users
Do a contract audit, make sure that customers are aware of and are following the terms of their contracts
Do an exception audit, identify the contracts that do not enforce a standard set of user definitions and terms
The first step is to enforce actual contract terms and to have a plan to normalize terms and standardize contractsDo a RACI for everyone who should be using your solution and make sure that your user types reflect the different users and responsibilities
Develop pricing for the different types of user and how each type of user gets value
