Pricing Schemes

As we all know support pricing is as much art as science, but pricing schemes are fairly limited. You can price:

• by user: you have a choice here since you can price by named user (anyone liable to use the system) or by concurrent user (the maximum number allowed to use the system at one time, regardless of how many different users can exist.) This scheme works well if the underlying product itself is priced by user — and naturally it should be possible to audit the number of users to minimize, shall we say, counting errors. Because it’s annoying to have to count users each day many vendors sell support for bands of users, say 100-200 users.
• by system or platform. This works well if the product is itself a box, or runs on a particular box, but may have various numbers of users or caretakers. Here again you want to be able to audit the number of systems.
• by support contact. The approach here is different: instead of counting heads (or boxes) we count the number of individuals allowed to contact support for personalized, 1-1 service. This scheme is often a part of a mixed scheme, combining a basic per-user charge (for the maintenance part of support) with a per-contact charge for the support piece per se. The benefit of per contact pricing is that customers have an incentive to minimize the number of technical contacts, which in turn may increase the technical ability of the contacts. And you can more easily impose certification or other conditions on the contacts.
• by site. The idea behind this scheme is to create a custom quote for the customer, estimating their global usage for the year. This is typically done only for large customers and in conjunction with a site license arrangement for the product. Customers like site deals because it gives them complete freedom to add users.
• by transaction. This is not a common scheme (yet) but I believe it will develop as a value-add pricing scheme over time. The idea here is that instead of paying per user or per system the customer pays per useful things that can be accomplished with the product. So for instance if the product is a CRM system perhaps the customer could pay per case. The more cases logged the higher the bill.
• by incident. In contrast to the previous scheme this one is very old: you call, you pay. Very common with consumer products.

Are you using other schemes? Please post a comment and share your experience.