A study of pricing models can make your head spin. Wikipedia lists 28 distinct pricing models. In practice, for enterprise software products, we frequently have a much narrower set of basic models we want to leverage. The two models that matter most are Competitive Pricing and Value-Based Pricing. In a lot of commodity businesses and consumer package goods we also see variations on Cost-Plus Pricing.
Most companies will leverage these models along with packaging options and other factors to arrive at their strategy.
Primary Pricing Models
Before diving into the pricing models that make more sense for enterprise software, let’s first take a look a Cost-Plus Pricing. The concept is straightforward. Determine what it costs to produce, market, sell, and deliver a good as your cost basis. Then, based on business objectives set a markup percentage.
Let’s say you make and sell sprockets. It costs you $1 to produce and sell each sprocket. If you mark them up to $1.30 then you have a 30% profit. If your costs go up or down then you will adjust your price accordingly to maintain the same profit margin.
Why does cost-plus not make sense in enterprise software?
Software economics do not behave like sprockets. In sprocket production, much of the product cost is variable based on the number of units produced. This is due to costs having a lot to do with raw materials/inputs of the product.
Since software products generally have no raw materials going into the Cost of Goods Sold, this pricing model becomes driven by sales and marketing costs.
In the end, this has no relation to the value customers receive. As such, there is a high likelihood that pricing would be set far too low relative to what customers would pay and the business would be leaving money on the table.
How is this useful then for enterprise software?
If you are in enterprise software do not use this approach.
Software resellers you partner with may sometimes use cost-plus pricing. However, generally, they will look to negotiate improved cost structures with price breaks on large deals or higher volumes of business.
When developing a new enterprise software product into an existing category, it is common practice to research how competitive products package and price. For well-defined product categories, with expected feature sets, this can frequently be the model chosen.
For example, consider cloud storage providers. Major competitors in this category include box, DropBox.com, Google Drive, and OneDrive. If you launch a new product in this category, a competitive pricing strategy would be to price consistently with these market leaders.
This does not mean setting identical pricing. It does mean that you would price your product in a way that allows for easy features and billing options comparison. Then depending on your strategy, you may choose to match, to undercut their pricing to penetrate, or set a premium to encourage a higher value perception.
Example: Pricing pages for Roadmunk (top) and productboard (bottom), two popular Product Management tools. Both offer $49 and $99 monthly plans. These plans have different features and names but they are directly competing against each other. It is quite evident through a survey of products in this category that the vendors have set pricing anchored on the competition.
Competitive pricing research is easy to find for many products, but not all enterprise products. In commoditized categories, it is common practice to publish transparent pricing details for most options. However, these prices are often given limited tiers and will require a prospective customer to call for large enterprise pricing.
Further, complex enterprise applications and technology, such as those sold by SAP, IBM, Oracle, Workday, and FISERV do not display their pricing in a transparent manner. Each of their solutions may have dozens to hundreds of options making any pricing you find very difficult to benchmark against.
Where pricing information is not readily available through market research, competitive pricing is not a practical option.
For the vast majority of those in enterprise software, the ideal pricing model is value-based. In short, the concept is to understand the value the product brings to the customer, then price according to that value.
Example: Consider a supply chain management application. Assume that we can identify that it costs a manufacturer $10m per year in their current processes to manage their supply chain and our software is predicted to cut that in half. Then the business value of our offering is $5m per year. If we then sell it to them for $500K/year that yields at 10x ROI.
Selling on the basis of cost savings, increased revenue, or reduced risk is the primary way that most enterprise software is sold today. The challenge is to accurately define the value to the business that they can trust.
Once you define the value, determine how much of that value prospective customers are willing to give up in search of a solution. Not all customers will value or pay for the benefit equally.
How to effectively differentiate the value of the solution benefits? Unlike physical goods, where the product is fixed when shipped, in software, especially cloud services, there are variables in how the products get used. These variables drive both the competitive benchmarks and value resulting from the use of the product.
It is critical to identify the variable attributes that drive value to the customer. When done well, pricing can scale effectively with the value derived from use. Such variability in the pricing model typically enables a lower barrier to initial use with upside revenue as the customer expands usage over time.
In many SaaS products, we can see value centered on the number of users. For example, in the Google GSuite or Microsoft Office 365 will charge per user within some tiered breakpoints, allowing for discounts at higher tiers.
However, there exist many other value metrics that can be considered. The key is to identify the metrics that are most aligned with value creation for the customer. Here are some additional examples:
Storage Capacity for cloud storage providers
Number of Active Partners for a Supply Chain Management solution
Number of Employees for an HR or payroll system
The volume of transactions for a payment service
Number of Devices for an Enterprise BYOD security solution
Number of Active Projects for a Project Management solution
Product Packaging Options
Not every feature in your solution adds equal value to all customers. Rather than making all customers pay for and receive all capabilities, the way that features are packaged into offerings can offer additional levers to fine-tune pricing models.
These options may be ways to differentiate your offering from competitors and among the different offerings you provide.
Example: Supply chain management solution has a feature to integrate with data providers to risk scoring suppliers. This may be an option only made available in premium packages.
Beyond splitting features into different offerings, the opposite may also be valid. If you offer multiple related products, it is possible to bundle them together.
Example: A large ERP vendor can bundle multiple HR and Finance components together to create a higher total value offering.
Due to the complexities found in differentiated solutions with multiple packaging options, you will not find pricing for such enterprise products published.
In practice, enterprise software companies leverage two primary pricing models – Competitive Pricing and Value-Based Pricing. Value-Based is the preferred model today in most product categories as it most aligns with perceived value and works to ensure optimal price capture for the business.
While presented above as separate, these models are frequently acting together. Minimally, competitive pricing is often a proxy for assessing perceived market value and setting a baseline of expectations.
For example, you may start with a competitive benchmark then adjust your price up or down based on relative perceived value delivered.
Determining how to leverage these models in practice is part of your Pricing Strategy, which will be covered in the next article of the series.