The problem of pricing software is tricky when it comes to accounting for relevant costs which must be considered in order to maximize profit. Most pricing literature assumes software costs as sunk costs and hence models pricing software as a pure selling problem. While this may be true for packaged software products for the consumer market such as computer games, financial accounting software etc., when it comes to enterprise software there are many other costs which become relevant for the pricing decision. Enterprise software, unlike most other products, is never finished. It must continuously be maintained, supported and changed to account for changing technological infrastructure, business and legal requirements. Corporate decision making, when it comes to buying a software product, is greatly influenced by the product roadmap the software publisher has and its ability to support future technologies, business and legal needs. The life of current version of any enterprise software product is relatively short and hence special consideration needs to be given to the timing of revenue and associated required product enhancements and selling costs in order to fully account for the relevant costs for pricing decisions.
Software Development Process
The Engineering Team
Software development is always a team effort. In a typical enterprise software there could be from tens to several hundred software engineers involved for many months to many years. The entire product team consists of various functional groups such as core development, testing, release and quality assurance. Within each of these teams there are smaller divisions based on the nature of the software modules and the required expertise. For example, if the software prints a custom report, there would be a team responsible for taking care of various aspects related to printing. This team would have detailed knowledge about printer drivers, device interfaces, graphics routines and other related functions. If the final product has to support multiple operating systems and hardware platform, there could be more than one team responsible for developing and testing the printing functionality of the software. There may also be a porting team needed whose sole responsibility would be port the software to multiple operating systems and hardware platforms and to ensure that the software works as expected on the supported platforms and environments. In today’s global market, it is highly likely that these teams are distributed across cities and countries and communicate via e-mail, online chat and phone.
Sales, Marketing and Support Teams
All sales teams have one of more sales managers supported by one or more sales engineers. The sales engineers provide pre-sales support. They are the key link in the selling process. They talk to customer’s technical folks to understand their unique needs and suggest appropriate solutions, which could include one or more products from the software publisher and/or its partners. They provide crucial feedback to the marketing team about customer’s current and future requirements. The sales manager is the overall coordinator of the selling process and may call upon other folks from within the organization to serve during and after the selling process. He may, for example, assign a technical project manager for an engagement. This project manager may either be one of the sales engineers or a technical marketing person or sometimes, for extremely important or strategic customers, a senior member or manager of the development team. The sales team also consists of business development managers who are responsible for establishing strategic relationships with other software publishers, whose products and services are complementary to their products and services. Some times these business development or ISV managers are part of the marketing organization but they work very closely with the sales team so that they can put together all the partnerships needed to serve any market segment. The marketing team consists of one or more product managers, who are responsible for defining various modules of the software and work closely with the engineering team to define the roadmap and release dates for various software releases. There is always and group product manager (also called the director of marketing some times) who is responsible for the overall product release cycle including market introduction, marketing campaigns and pricing strategy. The director of marketing has one or more public relations personnel in his/her organization who work with outside public relations firms and other service providers for managing companies press releases, trade show participation and other outbound marketing message decimation.
Software Vendor-Customer Lifecycle
The Selling Process
Enterprise software is almost always sold via sales people. While the actual delivery of the software may be via a web download, a CD/DVD shipment or e-mail attachment, there is no true e-tailing for enterprise software. A typical sales cycle could be any where between three months to a year long. During this period, the prospective customer holds several meetings with the software vendor and tries to get as much information as possible. A trial version of the software may also be obtained and installed to test drive the software. The trial software installation may involve a visit by the vendor’s sales engineer. During these meetings and visits, the prospect communicates with the vendor about its own unique requirements and tries to find out how much of those requirements can be met by the off-the-shelf product and how much customization would need to be done. Then the issue of who pays for the customization in the short term comes up. The prospect would like to see that the vendor make as much customization to the product as possible before they make a firm buying decision. The vendor of course would like to sell the current version as is and promise the customizations for the next version upgrade. In reality it is a combination of both which happens. Some features are added to make the sale, while others are pushed for the next version upgrade.
Life after Sale
The thing which is important to note here is that unlike most other products, an enterprise software sale leads to a long term relationship between the vendor and the customer. There is always something more the customer wants in the existing product and the vendor may come up with additional value added and compatible products that could be of use to the customer which may lead to additional product sale. This also implies that there has to be a continuous communication between the vendor and the customer. This makes selling additional products to an existing customer different than selling to a new customer. This also prompts vendors to choose their customers carefully. Many a times, a vendor may not pursue an eager customer due to the costs associated with the engagement process, both pre and post sales, unless the vendor can determine that in the long term the relationship would be a profitable one.
The Support Cost and Response Time
The single most important thing that an enterprise software customer worries about is the quality of support after a purchase has been made. This is where the vendor has an opportunity to prove to the customer that theirs was the right decision. Most of the time the license cost includes support costs for a certain period of time and an extra fee is charged if the customer wants support beyond that point. If the customer wants onsite support then there is always an extra cost associated with that. One of the things which is sometimes negotiated is the response time and it’s pricing. If the customer wants response within a few hours a premium is charged vs. if a response time of 48 hours or more is enough. Many software vendors charge a fee upfront which guarantees a certain number of “immediate” support incidents. It is like buying an insurance policy. The customer understands that the software is a very complex product and that it cannot be tested against all possible deployment scenarios and hence it is bound to fail under certain circumstances. And when it does fail to behave as expected, it can lead to disruptions in the company operations. Depending on how critical the software is to the business, the customer would be willing to pay varying amount of money for this kind of assurance and support guarantee.
Impact of New Laws and New Technologies
Most enterprise software users have operations in more than one location many a times in more than one state and/or country. Once a business process has been implemented using software, the ability of the company to comply with changes in the local, state or federal laws and regulations gets very dependent on the flexibility of the software package and to the extent the company relies on the software to comply with them. For many companies, there may not be anyone on their staff who is conversant with the relevant laws and can provide alternatives for them to comply while the software vendor is making the relevant changes which will make them comply with the new laws and regulations automatically. For such companies having access to priority support is of great concern and so is the viability of the software vendor. For the software vendor, there is immediate cost for changing the software to comply with new regulations.
Theory of Pricing for profit maximization
In this chapter we will look at the theory of pricing based on the supply-demand theory. Portions of this chapter has been adapted from “The Strategy and Tactics of Pricing: A Guide to Profitable Decision Making” by Thomas T. Nagle and Reed K. Holden (3rd Edition, Prentice Hall © 2002) and from lecture and course materials by Professor Heineke of SCU (some diagrams and text are copyright © Professor Heineke).
The Basic Criterion
The profit maximizing price (P0) is the price on the supply-demand curve corresponding to a market demand (Q0) where Marginal Cost (MC) = Marginal Revenue (MR).
In practice, since a precise demand function and a total cost function of product/service being priced is not known it is not possible to directly use the MC = MR criterion and read the profit maximizing price off the supply-demand curve. A more practical approach for making pricing decision is to perform a breakeven sales analysis and to plot a break even sales curve for varying product prices. Following is a plot of supply/demand values for a product where average product cost remains fixed in the range of the quantities being considered. The two plots correspond to a price decrease and increase respectively.
For maintaining status quo with respect to profitability i.e. Дπ = A + B = 0:
ДPQN + (P0 –c) ДQ = 0 => ДP(Q0 + ДQ) + (P0 –c) ДQ = 0 => ДPQ0 + (P0 + ДP – c) ДQ = 0 => ДPQ0 + CMN ДQ = 0 where CMN is the contribution margin at price PN.
Dividing both numerator and denominator or RHS by PN we get:
In a more general case where the product cost (c) varies as quantity (Q) changes:
Setting Delta Pi = 0 and solving for (Delta Q)/Qo yields:For real life cases, the change to avoidable fixed cost ( Delta FC) due to a change in sales volume ( Delta Q) must also be taken into account and the above equation changes to:For enterprise software products, the incremental cost of producing one more unit of the software being sold is practically zero and the above equation reduces to the following:Hence the most important parameter for making pricing decisions for enterprise software is accurately quantifying the changes to the avoidable fixed cost due to the change in the quantity sold. In order to do this right we must understand the relevant costs.
In this chapter we will look at various costs which a software publisher must incur and classify them into relevant or irrelevant for pricing decisions.
The Pricing Decisions
Clearly there are two different scenarios for a new sale. The sale is either to an existing customer or to a new customer. Before we go into the details of the relevant costs for each of these scenarios, let’s first take a brief look at what are the various pricing decisions the vendor has to make. Here is a list of potential pricing decisions items: 1. Licensing model of the base software. Price per user, price per server, price per site or geographic location, price per functional module, price per user application, price per server if the application is available from multiple locations etc. 2. Licensing model for add-on modules and products and their prices. 3. Amount of post sales support included in the base price and the mechanism of providing the support, e-mail based, web based, phone based or onsite visits. Price for additional support. How is it broken down? Is it per incident, per month/year, per user, per site or as a percentage of the product sale/list price? 4. Product upgrade fee for existing customers who currently have a support and maintenance contract and for those who don’t.
The Determinants of Level of Activity Variable cost is defined as a cost that varies directly as a result of a change in level of activity. Given this definition, we would then need to define what a “level of activity” is. For a software business, level of activity would include the following cost drivers: 1. Number of current customers This may or may not be relevant to a pricing decision. It certainly has an impact on the cost structure of the vendor. Current customers have support contracts and require regular bug fixes and updates. While the vendor can charge a separate support and maintenance fee, most product prices include at least some level of support included for some period after the sale. If the number of customers who currently have an active (paid) support contract is large, the incremental cost of providing support or update to a new customer for the same products and modules would be low and hence can be kept out of the pricing decision for a new sale. On the other hand if the product being sold contains a module not being used by many others, the incremental cost of making a sale must include the direct cost of providing the support to the new customer. 2. Number of current customers asking for new features or support for additional platforms. This becomes relevant for a new sale if the prospective customer is asking for something different. The vendor must decide how to balance the demands from existing customers vs. the new customer. Should the vendor ask for a one time non-recurring engineering (NRE) fee from the new customer? This decision will of course depend on the choices the prospect has and pros and cons of going to another vendor from an overall product/support point of view. 3. Number of prospects currently evaluating product for a potential purchase. While this certainly has a direct impact on the level of activity for the vendor, it is not directly relevant to the pricing decision. The field sales force must carefully manage the evaluators and say no to prospects who are likely to ask for features or platform support not inline with vendors current offering and are not likely to pay NRE fees. 4. Number of prospective customers asking for new features or support for additional platforms. More the vendor wants to grow its market share, more it has to listen to prospective customers. A decision must be made with respect to pricing for each new platform or feature that the vendor must add to make its product attractive to a prospect. The costs associated with making these additions to the product must be recovered from future sales to new and old customers. The cost for these product changes can be amortized over the entire set of prospects who have shown interest in those changes but a vendor must decide how many of the prospects currently asking for the changes will actually purchase the product when it is ready. How many of the prospects are ready to pay a portion of the license fee or NRE upfront? Which of the features/platform support should the vendor add to its normal product portfolio and which ones should remain custom offerings and at what price? 5. Number of platforms currently supported. This has direct impact on costs associated with adding additional features and fixing bugs. As soon as a change is made to the software for one platform, it must be compiled and tested on each of the supported platforms. The supported platform matrix can be very large since there could be several possible combinations of operating systems and their versions, hardware platforms and support software such as web browser, database server, application server, single sign on server, web server etc. provided by third parties (and their various versions etc.) which the enterprise software uses or interfaces with. 6. Number of current software partners for which additional integration/testing needs to be performed before each incremental/major release. The decision to integrate a product with any third party software must be made keeping in view the incremental revenue it will bring and costs associated with making the integration. Vendor can negotiate with its partners about how the integration and the subsequent testing are to be done and how the costs are shared. The costs borne by the vendor become relevant for making the feature/bug fix decision and affect the product costs over its entire life. When a software partner comes out with a new version and customers want to use the latest version of that product, the enterprise software vendor must decide how to recover the costs associated with the additional testing and potential product modifications which must be done in order to guarantee interoperability with each partner’s products. Such events are very normal for any enterprise software and must be taken into account for pricing both product licenses and support/maintenance contracts. 7. Decision to drop support for one or more previously supported platforms and corresponding activity of helping customers affected by this decision move to one of the supported platforms. Such decisions certainly increase the level of activity for the software vendor (and the customer) but are not relevant to pricing decision for a sale to a new customer. It is relevant to a new sale to an existing customer which has been affected by such a decision. The customer may need to buy new products in order to replace the unsupported products and may want the vendor to provide substantial discounts for these products (or ask for free replacements). The vendor must show the additional features and benefits the replacement products provide and hence justify its price. 8. Average number of support incidents per user and the total number of users of the product. In general more the number of users of a product there are, more will be the total number of support incidents. The number of support incidents per user depends of a number of factors such as how well the product has been documented, whether training was provided or not and how mature the product is. Such support incidents lead to increased level of activity for the software vendor. The support costs are always relevant to the product pricing decision if the initial license includes at least some support. The vendor must estimate the cost associated with providing support and factor it in the product price. The support costs associated to additional sale to the same user group would be lower than those to a new user group. This implies that a sale to the same customer should be treated like a sale to a new customer if the user group is different. The support costs are not variable cost for each sale. For example if one support engineer can handle up to ten new support incidents per day and there are ten support engineers currently on staff, the vendor has a capacity to handle up to one hundred new support incidents per day. If the current average new support incident rate is only ninety per day, the support team has excess capacity allowing for additional sale without affecting the cost of providing support. In other words, the support costs should be modeled as semi-fixed costs with each new support staff having certain capacity. Another factor to be taken into account is the fact that number support incidents per customer would be high whenever a new version of the product is released and when a new customer starts to use the product for the first time. The number of support incidents decreases as a customer gains experience with the product. This must be taken into account both when the cost of the support included with the product price is being considered and when the support services are sold as a separate item. The number of support incidents would also depend on whether the user group has undergone product training or not. The user group who has undergone training, the number of support incidents would be lower and hence they can easily be offered a discount for their support and maintenance contract. 9. Frequency at which the underlying technology/business environment is changing. Every time either an underlying technology or the business environment changes, it leads to an increase in the level of activity for the software vendor. Such activities would require the vendor to charge a higher fee for product updates and support and hence are relevant to the pricing decisions for support and maintenance contracts. Such activities are not relevant to an individual product sale since their costs are not avoidable. The vendor must adjust its products to conform to the new technological and business requirements in order to continue to be in business. This is truer with respect to meeting business requirements than technological requirements. This is because, as soon as the vendor’s product does not meet a key business requirement, it becomes obsolete and is no longer usable. For technological changes, the customers can choose to wait and synchronize their platform shifts with vendor’s planned releases etc. 10. Number of industry consortiums the company must participate in order to ensure proper product compatibility. The software industry is continuously evolving and hence there is a need for making new technologies work with the older ones and with each other. In order to accomplish this interoperability goal, software vendors form industry consortiums where they discuss and agree on various standards that they each must follow. There is a plethora of such industry consortiums present today in the market. Each product vendor must actively explore all related industry consortiums and standards body and them decide and participate in the ones it finds relevant. In some cases, the vendor may propose a new consortium to address issues currently not being addressed. Such activities can take up a lot of company resources. While involvement in each of these industry consortiums leads to higher level of activity for the vendor, such costs are not relevant for the pricing decision for a new sale. The vendor can however sell separate compatibility modules as an add-on product to its base product if the compatibility being asked for is not a key requirement for the base product. The level of involvement in the industry consortiums has a direct impact on the amount of interoperability testing the vendor must do for each of the product releases and hence such costs must be taken into account when a support and maintenance contract is being negotiated. 11. Amount of training and support required at various stages of customer engagement. This is a function of the complexity of the software and the sophistication level of the customer. The issue that needs to be considered is how much of the vendor resources needs to be spent before a form buying decision is made by the customer (and hence call it cost of selling) vs. the amount to be spent after a sale is made (and hence call it cost of support). Since the customer will typically not pay for any support/training provided before he/she has chosen the software vendor, the post sales support and/or the base product price must account for the presales support costs. 12. Number of sales channels required: direct vs. VAR vs. Distributors Most enterprise software is sold via direct sales force. For certain market segments, where the vendor lacks resources it uses other third parties which fall into the categories of either a Value Added Reseller (VAR) or a Distributor. A VAR is a typically another software product/service vendor which has a complementary offering and decides to offer the bundled product/services as a higher value added proposition to its customers. The VAR may also take on pre and post sales responsibilities for the software vendor. The issue of pricing the software for the VAR is then always a question of offering discounts off the list price based on the level of support the VAR plans to provide. The distributor is typically used to reach out to new geographical locations where the vendor either cannot cost justify a direct sales force or other cultural factors (such as in Japan, one must have a distributor in order to be perceived as a real business) mandate having a distributor for interfacing with customers. 13. Amount of time a typical customer takes before making a decision to buy the product. It increases the cost of selling and hence is relevant to the pricing decision for sale to both new and existing customers. Vendors may choose to offer discounts if they believe it can lead to a faster decision making by the customer. Most of the time such discounts are not offered since it sends a different message to the market about the product quality being inferior. 14. Number of state and federal government regulations and laws the software must help its users comply with. It is directly related to the number of states and countries in which the customers have operations and want to use the product. This is relevant to a new sale if the prospective customer has offices in more than one geographic location and wants additional (i.e. not already included in the base product) modules to comply with local laws and regulations. If the vendor already has support for all the locations the customer is looking for, it is not very relevant to product pricing for this sale but it becomes relevant as soon as there is a change in the laws of any of the supported locations and such support was included in the product price. If the customer is asking the vendor to add support for an unsupported location, the vendor can typically ask for an NRE or require the customer to prepay for a certain number of user/server licenses for that location. Support contract pricing should treat this as relevant cost. 15. The number of contract modifications needed for each customer engagement. Since the software license agreements are fairly complex legal documents and can be tens of pages long with ongoing modifications over the life of the customer-vendor engagement, there is a direct cost associated with entering into these contracts and subsequent maintenance activities. While the vendor can’t typically ask the customer to pay for these costs directly, it can however, offer different pricing to customers based on its assessment of the costs associated with the contractual activities. Conclusions Based on our discussions in the previous chapters, we conclude the following: 1. Carefully calculating the changes to the avoidable fixed cost due to the change in the quantity sold is the key determinant for pricing decisions of enterprise software. 2. In general the real cost of selling one more copy of enterprise software is not zero. It depends on how the relevant fixed costs are affected by the sale. 3. The pricing for an existing customer can be very different than pricing for a new customer due to different impact on overall fixed cost a new customer can have as compared with an existing customer. 4. Each customer is unique and a thorough analysis of total impact a customer will have on the overall fixed cost is required before pricing can be established for any specific customer.