In the old world, software pricing was based on the number of users that were entitled to use the software, with (often) a distinction between concurrent and non-concurrent users. It was a simple model. The pricing was easy to understand, and the customer’s compliance was, in theory at least, easy to verify.
A lot of that approach was carried over to SaaS, with pricing being based on the number of authorised users. Again, it’s a simple model and with SaaS it’s even easier to verify. But is it a good model? There are at least two reasons for thinking that it isn’t.
First, as a SaaS vendor, you want your software to be pervasive in your customers’ businesses. You want it to be so ingrained in their operations that they find it very hard to move away from it. Pricing per user discourages pervasiveness so, from that point of view, it’s sub-optimal. It’s much better to price on a different metric, and ideally one that lines up with the value extracted by the customer. So, for example, if your SaaS product allows for the management of a fleet of cars, you could price by the number of cars managed, and put no price or limit on the number of users. You still have a pricing metric, you still get your revenues, but you have taken the brakes off adoption.
The second reason for not pricing by authorised user is the increasing use of APIs and machine to machine (M2M) interactions. If you price by user and your SaaS product also offers an API to which customers can connect, then a) you will find it increasingly difficult to track the real number of users and, b) if the connected system can do the work of, say, ten humans, your revenue will decline by 90%.