Vendor clients often ask me about pricing. Everybody knows that there usually are:
- A low-quantity list price.
- A standard volume discount (typically 50%ish, assuming negligible cost of goods sold).
- The real negotiated price.
But the whole process has to start with some concept of a single-unit price.
What kind of price? Well, for appliances, you usually should just charge a one-time fee for whatever is in the carton, plus annual maintenance; most alternatives are gimmicks. But for packaged software, there are numerous choices. The easy part is timing:
- All software can be charged for on an annual license.
- Some can be sold on a perpetual license as well. (Exceptions include: Open source, SaaS, and perhaps other software whose main competition is reasonably-priced subscriptions.)
- Annual maintenance is usually 20-22% of the perpetual license fee.
- When there are both perpetual and annual options, the annual fee is usually 40-60% of the perpetual one.
Tougher is deciding what kind of “unit” you should price by. My standard advice has become:
- There should be 2 or more simple pricing algorithms, so that …
- … the price for any given customer is the lowest of those choices.
Generally one pricing algorithm will be suited for most of your customers, while the others will be meant for minority or edge cases.
By “simple pricing approaches” I primarily mean the usual-suspect proxies for valuable work done, such as:
- So much per unit of computing capacity (server, core, virtual machine, etc.).
- So much per user (named, simultaneous log-on, whatever).
- So much per unit of data (amount of raw data, capacity of RAM, volume streaming through).
Alternatively, some pricing schemes focus more on development effort averted — e.g., ETL vendors may charge according to the number of different databases you connect to.
- You could price business intelligence software:
- Per server core to most of your customers.
- Per virtual machine to those who virtualize it.
- You could price sophisticated analytic software:
- Per named user to most of your customers.
- Per server, for those few organizations who want widespread/occasional access to it.
- Premium (i.e. expensively) either way.
- You could price database software:
- Per terabyte stored …
- … but with a per-server cap that keeps you competitive with appliances even when a database is highly compressible.
- You could price ETL software:
- Per database connection …
- … with a per-server cap …
- … and a per-megabyte option that probably only makes sense for a few awkwardly sharded cloud deployments.
Virtues of such approaches include:
- Simplicity. Your salesman on the account should be able to quickly determine which pricing approach will apply. The prospect should be comfortable that there won’t be hard-to-foresee “gotcha” charges.
- Fairness and match to use case. For any particular prospect, there probably will be a pricing scheme that fits well.
- Competitive flexibility. Nothing in this strategy puts much of a floor or ceiling on your pricing. You can do whatever you think is economically best.
My advice is similar for SaaS (Software as a Service), for similar reasons, with variations such as:
- There’s no natural concept of a perpetual license.
- There may be more choices (with appropriate quantity discounts) for length of term.
- Pricing could be by unit-of-work — e.g. transactions or other operations.
In most cases, there’s a whole other dimension of pricing complexity — you want to carve your offering into tiers, e.g.:
- Paid product/free trial version.
- Base product/chargeable options.
- Full feature set/limited features for casual users.
- Good support/best support.
I’m not going to address those in detail now, but I’ll leave you with one cardinal rule:
Don’t provide anybody with software that gives them a bad experience.
Even your crippleware should be good.
- Pricing choices by many specific vendors