The most predominant license metrics used today for most enterprise software are either a named-user or machine-locked license. With the named user license metric, fees are applied typically by the name and role of the user accessing a set of software functions. This is often used with enterprise CRM or ERP software. With the machine-locked license, fees are applied based upon usage on a particular machine. These metrics are typically used with traditional desktop software deployed throughout the company.
Another type of license in use is the concurrent license metric, or, the case where license fees are paid based on a high watermark – the maximum number of users that can access the software at one time. This is sometimes also called a “floating license” as the license rights are in essence, available or floated among users provided one is available (e.g. they haven’t all been checked-out). This typically requires some license management technology, and works well in large environments where a large number of users access the software, and the administration of managing a large number of named users or node-locked software deployments becomes overwhelming.
Concurrent licenses are often adopted by software producers that start with a named-user license or node-locked license metrics. There comes a point where there is a need for simplicity, and a concurrent license meets the need. In addition, the availability of software in a concurrent license model promotes deeper account penetration by allowing additional users to “test drive” the software.
The trick is – how do I price the concurrent license? Since more users can potentially access the same “amount” of software when it’s made available in a concurrent method, the software producer wants to ensure that they don’t lose revenue. Certainly, if the software is providing more value, then one can argue that the software producer should make more money than before.
An effective approach is to evaluate software usage for a single license with the existing metric, and then determine usage in the concurrent. From there, pricing can be multiplied by the increase in usage as a starting point. For example, let’s assume that a software producer sells a desktop productivity perpetual license for $100, and also that the software is used on average 2 hours per day. For a reasonably large deployment, one can assume that the software license will be used 8 hours per day as all users in a particular site will have access to the software (4 times the usage, and presumably, 4 times the value). This suggests that concurrent license should sell for $400, or, close to that price. Of course, market testing may suggest a slightly lower price. In real world experience, I have seen the software license sold with the concurrent license metric priced anywhere from 25% higher than a machine locked or named user license, up to 400% higher. The method used above was part of the process used to establish the concurrent license price.
Now, let’s assume that the software producer is selling to an enterprise that has a worldwide presence, in which case the software might be used “around the clock”. In this situation, the software license that was only used 2 hours per day may now be used 24 hours per day. This is 12 times the usage, so perhaps a price of $1200 may be needed. Again, the actual price will probably not be so extreme.
What’s nice about offering the concurrent license is that it doesn’t have to be the model license metric, but it can be part of a larger portfolio that enables more flexible pricing and license for different types of customers. One can offer a machine locked license for individuals, a campus-wide concurrent license for SMB accounts, and, a worldwide concurrent license for global accounts.
Next week: SaaS is More Than a Software License Model!