Most Common Enterprise Software Pricing Models
by admin
Open-Source
Open-source software is free software. Usually, this means that it’s both free like beer and free like speech.
Open-source software is created by communities of volunteers, and businesses that create code and release it into the public domain. Open-source software is theoretically more secure than closed-source software since vulnerabilities are easily spotted and fixed, and it’s harder for vulnerabilities, back-doors or other unpleasant code to be hidden or swept under the rug.
However, open-source projects lack the resources and professionalism of larger for-profit software companies with dedicated staff.
Companies can make money by releasing open-source software, and then charging money for customization and support services.
Package Pricing
Package pricing is popular amongst cell phone companies. It arranges features into groupings in such a way as to de-commoditize the offering and prevent prospects from effectively comparing the offering to those of other competitors.
In the enterprise software space, this approach is typically done by interviewing the buyer and asking lots of questions. Then, a custom-tailored package will be put together, and the end-user gets a single price for a bundle consisting of many different elements. (Licences, additional services, SLA clauses, etc…)
Bundling packages in this way also helps the provider in the negotiation process, since any attempt to modify the original package will usually have a high cost for the prospect.
However, this approach also has a number of downsides.
Due to the complexity in obtaining a quote, the software provider may turn away a lot of potential customers that didn’t want the hassle of answering questions and bartering.
Due to the unstructured and inconsistent nature of these package quotes, different clients may get different pricing for the same service. When this happens, the company’s reputation may suffer.
Modular Pricing
With a modular pricing model, you purchase components or functionality and add them on like building blocks.
This is similar to encyclopedia salesmen who would sell you the first volume for a dollar, then charge $25 for each additional book.
Often, the software provider will offer the base package for free, or at a very low price in order to attract clients. And once the customer is locked in, there is a high price for upgrades and additional functionality.
Transaction-Based Pricing
Transaction-based pricing attempts to align product pricing with the business value that the customer gains as a result of the software.
For example, a database application may stop working and require an upgrade after 50,000 records. Or the software may be billed at a few pennies per entry.
Although this sounds good in theory, it’s somewhat less than practical in reality.
To see what I mean, imagine the case of a manufacturing company that relies on a commodity like steel. Because the price of steel goes up and down every day, the company must constantly change the pricing for its widgets. And this pricing confusion trickles down and makes life harder for wholesalers, retailers and consumers of the widgets.
A better approach would be to enter into contracts with futures traders who can provide steel at a stable price.
Likewise, imagine what would happen to a company that was paying per web site visitor if they were subject to a sudden DDoS attack. They could eat through a whole monthly budget in a single evening.
Also, buying software in this way adds an extra burden to the IT manager, who must now constantly monitor the use of each system.
Per-Machine or Per-User Licensing
With this approach, you pay for each machine on which the software is installed, or for each user account that has access to the system.
One a per-machine basis, this pricing model becomes harder to enforce as the concept of “a machine” becomes fuzzier.
And when billing on a per-user basis, you’re adding much more work for the – already overworked IT – department. For this reason, it’s not recommended for on-premises installed software.
The per-user billing model is best-suited for SaaS applications, where the cloud host is in a better position to monitor and bill on a per-user basis.
Another approach would be to bill based on the maximum number of simultaneous users that can access the system at a single time. Theoretically, the system could handle an unlimited number of user accounts, as long as they didn’t all try to use the system at once. This approach makes much more sense when we’re talking about installed software.
Per-Processor Billing
Because virtualization has changed our definition of what an “individual computer” is, many software vendors have taken to billing on a per-processor basis. Although this might sound like an elegant solution, it also has its own challenges.
Some would argue that a multi-core processor is only a single chip that’s been optimized for maximum efficiency. While others believe that each individual chip inside a multi-core should be counted as a single processor in the license agreement.
In other words, the kind of processor you select could quadruple the purchase price of your software. And selecting a single-core processor could help you save on software costs, but you’ll be penalized with higher energy and cooling bills. Both of these scenarios seem needlessly wasteful.
Another problem with this pricing model is that you often end up paying for processors you never use. You might be running a server with 10 processors, but a particular instance of an operating system is only set to run on 2 of those processors. That doesn’t matter, because the software license bills you on the number of processors you HAVE as opposed to the number of processors you USE.
Related posts:
