User-based pricing has gotten a lot of bad press recently. It is generally seen as a lazy pricing metric, used by companies that have not thought deeply about their value metric and how to connect their pricing to value. But there are many cases when user-based pricing is the best approach and should be used.
Stop Per User SaaS pricing; You're Killing Growth by Patrick Campbell at Pricing Intelligently makes a lot of good points, but it is not the whole story.
First, a few definitions. What do we mean by 'value metric' and 'pricing metric'?
The 'value metric' is one of the most important concepts in pricing work. It is the unit by which a user consumes your service that correlates with the value they receive. Let's take a simple example. When I am painting a room and I buy a can of paint I am most interested in how many square feet the can will cover. Different paints have different properties and some cover a surface better than others. Gallons of paint is not a good value metric because it does not correlate well with value. The number of square feet or square meters covered per unit of volume is a great value metric, for paint.
One of the first things we do in pricing work is try to understand all of the potential value metrics. We use these to research potential value, build market segmentations and calculate economic value relative to alternatives.
The 'pricing metric' is the unit you price in. For paint, this is most frequently a volume metric. That is what painters are used to paying for, and familiarity can often make buying easier. For software, number of users is a common pricing metric, and it has been for a long time.
There is a simple test to see if per-user pricing is a good candidate.
"If two people share the same log-in do they get the same value as if they each had their own log-in?"
If the two people get the same value when they share a log-in, then per-user pricing is probably a bad idea. For one thing, it encourages cheating. People will be tempted to share their log-in as it does not cost them anything (they don't lose any value themselves) by doing so. If value is not tied to an individual user's use then per-user pricing is not measuring the value.
There are many cases where the software provides value for individual users. If the software is customized for my use then other users will not get the same value that I do. There are many ways software can be customized for me. I may have the various consoles and controls set up to suit my personal style of work. There may be integrations with other applications that are unique to my needs. The software may be tracking my use and using this data to share relevant content.
One pushback I get on this is the example of Microsoft Office and other personal productivity applications. These are almost always priced per-user, and in the past there was no personalization so that is not a justification for a user-based pricing model. My copy of Microsoft Excel looked almost exactly like yours, and I had no trouble using it. These applications go way back before everything was networked and before applications started collecting data on use. There were fewer pricing metrics possible back then and software did not evolve as quickly. The pricing paradigms of twenty-thirty years ago may have a long half life but they are going away.
So, use per-user pricing when the value of the software is tied to its use by a specific user. Using individual data to configure the software and help it adapt to the user is one way to connect an individual value metric to a per-user pricing metric. This is what the skill and expertise management platform TeamFit does. Each user has their own skillmap, and the skill recommendation engine uses information about each individual to suggest skills. Per user pricing makes sense in this case. Another way to justify per-user pricing is to ask people to pay for privacy. This metric is not just relevant to personal productivity software. We expect to see more and more companies offer different pricing based on differing levels of data rights. That is a topic for another day.