9.3 Pricing
9.3 Pricing
Pricing is an important issue in any supplier-customer relationship, and one where economics offers many useful insights. Software is most frequently licensed rather than sold outright (see section 8.1.3), resulting in licensing revenue but not precluding licensing to other customers or charging again for future upgrades. The large supply economies of scale make pricing a particular challenge for software suppliers—unit costs offer minimum guidance, since they decrease rapidly with market size (Shy 2001). This and many other considerations admit a wide range of pricing strategies with an equally wide range of consequences. Some considerations are how revenue is spread over time, how different customers are treated, terms and conditions, who pays, and bundling.
Some commonly used pricing options for software are listed in table 9.1. All options shown are available whether software is sold as a service (its features accessed over the network) or code-licensed (provisioned and operated by the user or end-user organization). Although subscription or usage pricing are most often associated with the service model, these options are available with code licensing as well. Software is different from material and information goods in that it can be self-aware and can thus self-enforce (through monitoring and billing) the terms and conditions of sale (see section 9.2.4).
 |
| Option | Description |
|---|---|
| | |
| Individual license | Fixed price for one individual to install and use an application; may or may not allow installation on two or more computers. Typical of consumer applications. |
| Site license | For a fixed price, unlimited right to install and use within a given organization. The price is usually based on organization size, is often individually negotiated, and is predicated on the organization's taking responsibility for provisioning and operation. |
| Seat or host license | For a fixed price, unlimited right to install and use on a specific computer without regard to who accesses that computer. Often a pricing schedule offers a volume discount for larger number of seats. Pricing can be predicated on the capacity of the host, based on measures such as the number and speed of processors. |
| Floating license | For a fixed price, right for a certain maximum number of users to be using the application concurrently. Typically installation on a larger number of computers is permitted, and a license server monitors and limits the number of concurrent users. |
| Subscription | Similar to a site, seat, or floating license, except that there are fixed recurring payments as long as the application is used and all version releases are included. |
| Usage- or transaction-based license | Similar to site, seat, or floating license, except that the payments are based on some direct objective metrics of usage, such as number of user hours or number of e-commerce transactions successfully conducted. |
|
9.3.1 Spreading Revenue over Time
As outlined in section 5.1, creation of software entails not only initial development but also ongoing maintenance (repairing defects), upgrade (providing increasing capabilities or meeting changing needs), and customer support. If software is sold as a service, there are also costs associated with provisioning and operation. How is the revenue from an individual customer to be spread over the life cycle of the software, recovering these costs and making a profit? Is the strategy to front-load the revenue, even it out over time, or offer the initial product as a loss-leader, recovering the costs late in the life cycle? The total revenue will depend on the revenue from an individual customer and from a growing customer base.
The three example approaches shown in figure 9.4 illustrate how revenue accumulates with time. In the individual, site, seat, and floating licenses users are charged explicitly for upgraded versions, so that revenue arrives at discrete points (see section 5.1.2). Typically a new version has improved features, quality, and performance, and is offered at a discount to the initial purchaser. This discount recognizes that the biggest competition for a new version is the installed base of older versions, that the new version may offer a lower incremental value than the initial acquisition, and that the new version may have been cheaper to create. This pricing strategy front-loads the revenue from each customer and depends on a growing customer base to expand total revenue. New versions bring in revenue from existing customers and help make the software more attractive to new customers. Any switching costs expected when the customer moves to an alternative supplier can be taken into account in setting the upgrade price.
Figure 9.4: Several ways to spread revenue from a single customer over time. Note that the supplier cost structures for these pricing options may be distinctly different, particularly as provisioning and operation move from customer to provider responsibility.
In the subscription option (see figure 9.4), the customer makes regular payments, spreading revenue more evenly over time. Some customers appreciate knowing costs in advance (which helps budgeting) and recognize the time value of money. The subscription is particularly appropriate where provisioning and operation are bundled with the software (as in the application service provider model; see section 6.2) because operational costs spread out more evenly than development costs. (Note that when the supplier handles provisioning and operation, its costs may be considerably higher, so revenue is not the total picture.) The upgrade and subscription models can be combined, for example, by offering maintenance and operation by subscription while licensing the software separately through charging for upgrades.
The usage-based option (see figure 9.4) may be attractive to customers who consider value to be directly related to usage and to a confident supplier who is sure the software will be used a lot. A disadvantage to the supplier is that revenue may be slower to develop—it tends to be back-loaded—or may never materialize. The individual, seat, and floating licenses are crude approximations to usage, tending to increase revenue from a given customer as usage grows.
Late in a software product's life cycle, it may become a financial burden to its supplier. The user community can dwindle to the point that revenues do not justify upgrades, or the supplier may want to replace the software with an innovative new variant. Unfortunately, terminating these investments in upgrades will alienate existing customers by stranding them with deteriorating (and eventually unusable) software, or by stranding investments they have made in complementary software.
Example Stranding existing customers has been an issue in operating systems. Customers typically make major investments in applications, so offering a more modern or more widely accepted operating system often means the supplier assumes the financial burden of supporting two operating systems with considerable costs but with little compensating advantage. Examples include Digital VMS and Ultrix (a kind of UNIX); Hewlett-Packard, HP-UX (a kind of UNIX) and Windows; IBM (MVS, OS-400, OS-2, AIX (a kind of UNIX), Windows, and Linux; and Apple, classic MacOS and new MacOS X). Microsoft, although not a computer supplier, is another example: the initial market split between Windows 95 and Windows NT remained intact until the introduction of Windows XP; a separate Windows CE line continues as well.
Component technologies (see section 7.3) offer a smoother transition strategy, provided old and new versions of a component can be installed side-by-side.[4] Then older versions can be phased out slowly, without forcing users of the older versions to move precipitously to the new version. Replacing layers in an infrastructure while allowing older versions to remain is a variation on this strategy.
9.3.2 Different Prices for Different Customers
A second general issue in pricing is how different customers may be treated differently. Pricing is considered nondiscriminatory when the prices charged to different customers are based wholly on the marginal costs they create for the supplier; that is, the difference between price and marginal cost is the same for each customer.[5] In this case, the supplier is expected to make up for the large fixed costs of software creation and maintenance in this fixed difference. For software, this issue is complicated by the presence of provisioning and operation intermediaries: the customers may be these service-provider intermediaries or users or end-user organizations. The issue is also complicated by group sales; particularly for sociotechnical applications, software is often sold to an organization for the benefit of its internal users.
Some major sources of marginal costs in all stages of the supply chain for software (see section 5.1) are listed in table 9.2. Other important business functions like marketing, sales, and administrative overhead that are not specific to software are not listed. The implications of these marginal costs to pricing depend on the industrial organization. For example, the costs of customer support and how they are reflected in pricing depend on who the customer is—customer support of a service provider doing provisioning and operation is a much different from customer support of individual users.
|
| Function | Marginal Costs |
|---|---|
| | |
| Analysis | Generally these are fixed costs; however, meeting the needs of a new type or category of users can create marginal costs in understanding their distinctive needs and capturing them in requirements. |
| Development | Generally these are fixed costs; however, as with analysis, expanding the requirements to satisfy new types of users can create marginal costs. |
| Maintenance | These are largely fixed costs related to identified defects in the software itself and thus largely independent of the market size; however, more adopters may uncover more defects earlier, creating added marginal costs. |
| Upgrade | Costs of creating upgraded versions have similar characteristics to costs for analysis and development. If the upgrade expands the market by accommodating a new type or category of users, then marginal costs may be assigned to those new users. |
| Customer support | Some types of customer support costs (e.g., telephone agent salaries) may increase with the number of adopters. For that reason, it is important to minimize these marginal costs through rapid service releases, online problem databases, and other means. |
| Provisioning | Typically, a provisioning organization serves groups of users. The recurring costs (salaries and professional services) will largely be fixed for each group but will grow with the number of groups. Capital facilities costs (network, server) will be related to the number of users and their usage. Viewed in the large, these are predominately marginal costs. |
| Operation | Similar to costs for provisioning. Viewed in the large, predominately marginal costs, but it is important to contain them through good customer support and administrative software tools. The cost of security tends to grow with the user population, in part because a more popular application attracts more crackers. |
|
A strong competitive market may force nondiscriminatory pricing and very low margins (excess of price over marginal cost), but this creates a problem in recovering fixed costs, principally the creation costs of analysis and development, maintenance and upgrade. These are substantial costs for software not reflected in nondiscriminatory pricing that must be recovered entirely in the margins. Suppliers thus try hard to minimize direct competition and increase margins by differentiating their software products and by exploiting market mechanisms like switching costs and network effects.
Another way to help recover the high fixed costs of software creation and maintenance is through price discrimination, pricing that is somehow decoupled from marginal costs (Varian 1992). Assuming the supplier is able to substantially differentiate a product, its most extreme manifestation is value pricing, where prices are based entirely on customer willingness to pay rather than on costs (Shapiro and Varian 1999b), sometimes referred to by customers as "charging what the traffic will bear". Value pricing is complicated by a wide range in willingness to pay among different consumers and thus requires price discrimination.
Forms of price discrimination include individualized pricing, based on customers' value or willingness to pay, customer segmentation pricing, based on different groups of customers with different willingness to pay (e.g., educational pricing), and versioning, in which customers self-select their most attractive price-quality trade-off from among alternative versions of the product (Shapiro and Varian 1999b). Price discrimination may mean that customers operate under (or self-select) different pricing schedules but not necessarily.
Example A pricing schedule may include a usage-based component. If the customer is doing its own provisioning and operation, then the software supplier's costs are, to first order, independent of usage. The usage component is therefore related to the customer's value rather than to the supplier's marginal cost. On the other hand, usage-based pricing for an application service provider may (at least to first order) reflect that provider's marginal costs of provisioning and operation.
The user's willingness to pay depends on many factors (see section 3.2). Some of these, such as usage, quality, and fidelity, can vary over time for the same user. While the common pricing strategies shown in table 9.1 certainly offer opportunities to price-discriminate, this is predominately based on crude usage metrics. Other value factors that may differ significantly from one user to another may be reflected in prices determined through individualized license negotiation or selective discounting from catalog prices.
The business model and pricing strategy can have a significant effect on supplier incentives and targets for investment. For example, usage-based pricing provides an ongoing revenue stream even without new versions and puts the emphasis on maximizing usage.
In the versioning approach to price discrimination, a portfolio of software variants is created that offers different levels of value (e.g., features, quality, performance) (Shapiro and Varian 1998; Varian 2001). (The meaning of version differs in economics and in the software field; see section 5.1.2.)[6] Customers will select a variant with the most attractive combination of value and price, and this can increase total revenue. The voluntary nature of this discrimination is relatively popular with customers and with suppliers, who avoid having to conduct individualized price negotiations. Frequently, a basic variant is offered free, either for a limited-time trial or indefinitely, while more capable variants are sold. The free offering bears little marginal cost to the supplier and serves to familiarize customers with the product in the hope that they will move to a paid variant.
Example The business model of many suppliers of software for the Web has been to offer the client viewer for free download and sell the server software to information and service providers. Examples include Adobe Acrobat and Real Network's RealPlayer. Adobe and Real Networks also offer for sale a variant of the client with added features.
The key to success in versioning is pricing higher-value variants so that customers with a higher willingness to pay will not be tempted to save money and opt for a lower-value variant. This is done by adjusting the consumer surplus (willingness to pay minus price) to be equal or higher for the higher-value variant. For example, with two variants, the difference in value (willingness to pay) must exceed the difference in price. In the absence of versioning, typically the higher-value variant is the biggest revenue opportunity, and adding a lower-value variant reduces the price that can be charged for the higher-value variant but increases total revenue and makes the product available to a larger audience. Economic theory further suggests that the value of the lowest-price variant should be set lower than even price-sensitive consumers would be willing to pay in order to encourage less price-sensitive consumers to opt for the higher-value variant.[7] It is common to offer a third, even higher-value, variant, because experience suggests that consumers are psychologically biased toward a middle-of-the-road choice.
Versioning is particularly appropriate for software because the marginal development cost of offering variants is low—it is a matter of developing the highest-value variant while building in the flexibility to turn off certain features or degrade performance. This does, however, have to be anticipated early in the development. At the architectural design, modularity should ensure that modules can be added or removed, resulting in a coherent addition or removal of features. During development, configuration options can be included that allow certain capabilities to be substituted or bypassed. As these options are difficult to retrofit, the business model and pricing strategies should be established early, and developers should take into account pricing strategies as well as the needs of users.
9.3.3 Bundling
Another issue related to pricing is what is bundled in the sale. Beyond the software code itself, options include future service releases, future new versions, customer support, and even provisioning and operation. The several common business models discussed in chapter 6 amount to different bundles.
While different bundles are often associated with specific pricing strategies, presupposing pricing options is not a good way to differentiate bundling options because software pricing is so flexible (see section 9.3.1). A better approach is to consider the range of skills required to supply the bundle, the effect on transaction costs, and the advantages or disadvantages from a customer perspective.
Example While code licensing and customer installation are usually associated with site, seat, or floating licensing, networked software can communicate with a license server to offer subscription or per-transaction pricing. Software sold as a service is usually associated with subscription pricing but can also be sold at a fixed price. A more important consideration in comparing these bundling options is whether it is the supplier or the customer that bears the burden of provisioning and operation.
Suppliers often bundle complementary pieces of software, or software and hardware, in order to offer a full systems solution to the customer.
Example Historically, the manufacturers of voiceband data modems (such as Hayes) bundle the hardware with a communication application, such as terminal emulation. One reason is that the modem is useless without the communication application and vice versa. Bundling removes the burden of having to choose and purchase two products. A similar approach is followed now by suppliers of full-featured sound cards and DVD drives, who bundle software to make the added value of these products more evident to the customer or more demonstrable in the retail store.
Bundling can help deal with the dispersion of customer demand (Shapiro and Varian 1999b), which makes it challenging to set a revenue-maximizing price.
Example The office suite (usually including a bundle of word processor, spreadsheet, presentation, e-mail, and database) is a good example. Some users may want the word processor badly but have only occasional need for a spreadsheet, and others may use a spreadsheet intensively but only occasionally use a word processor. The supplier can set the individual prices of the word processor and spreadsheet high enough to derive maximum revenue from the intensive users while disenfranchising the light users, or set the price low enough to attract the light users while forgoing the higher price the intensive users would be willing to pay.
The dispersion in demand is often lower for a bundle than for its constituents, increasing total revenue when the supplier is forced to set a single price.
Example Suppose there are 100 customers, half of them willing to pay $1 for product A and $3 for product B, and the other half willing to pay $2 for product A and $1 for product B. If product A and B are sold separately, the revenue-maximizing price for product A is $1 (revenue $100) and for product B is $3 (revenue $150), for a total revenue of $250. However, if A and B are sold as a bundle at a single price, then half the customers are willing to pay $4 and the other half $3, and the revenue-maximizing price is $3, for a total revenue of $300. The bundle has less dispersion in willingness to pay ($1 versus $3).
Bundling is particularly natural for software, where the incremental cost of bundling other pieces of software is very low. Since costs are not much of an issue, the objective of bundling is to maximize revenue (as in the example). There is an opportunity cost for not selling that software separately, but often it is just the opposite: greater value can be derived by adjusting the price for the bundle rather than by selling the constituents separately, as the example illustrates. Another way to view bundling is as a strategy to derive some incremental revenue from a product that the customer is unlikely to buy separately by bundling it with a product the customer does value greatly.
The value of a bundle can be increased through the composability of the constituents (see section 3.2.12).
Example Suppliers of office suites enhance the capabilities of the constituent applications to share information, such as directly translating a spreadsheet into a word-processing table. They carry this further by allowing one application to manage objects embedded in a document managed by another application, e.g., the presentation application managing a figure in a word-processing document.
To reiterate, the variants of a piece of software are almost direct substitutes but offer different baskets of capabilities, features, and performance. The customer is expected to want only one variant, the one that maximizes his consumer surplus. Bundled pieces of software are not substitutes and may even be highly complementary—the expectation is that the customer wants them all. Both versioning and bundling address dispersion in demand using different techniques in different circumstances.
9.3.4 Terms and Conditions
Another issue surrounding pricing is the terms and conditions of sale. As with other goods and services, there is typically a coupling between these terms and conditions and the price that can be charged. One set of conditions relates to how payments are spread over time and the future obligations for payment (see in section 9.3.1). Terms and conditions also include any warranties on correct functioning and any commitments to provide support and future maintenance, possibly associated with payments.
Another important issue is the upgrade policy. Is the supplier obligated to provide future versions as well as to maintain the software in the future? Is the customer obligated to purchase later versions? If customers are not required to use the latest version, how long does the supplier agree to maintain and support older versions? A common (but not necessary) provision of the service provider model is automatic upgrades to the latest version, but this may be problematic for some users who have to change versions at times not under their control. By maintaining a range of supported versions (sometimes called a window), customers are not forced to upgrade in lock step.
Another issue is performance and availability parameters. Sometimes an agreement is entered to achieve specified performance and availability characteristics, called a service level agreement (SLA) (Hiles 1993; Koch 1998). An SLA for licensed software in isolation doesn't make sense: very few if any service qualities are a property of software alone. Rather, these are system properties affected by software, the operational environment that includes infrastructure software and equipment, and the skill level of the operating organization. Thus, SLAs are most common for the service provider model, including networking and application hosting. SLAs for customer-operated software are possible but need conditional clauses that require the customer to obey rules, such as dedicating a server to the software.
Other terms and conditions relate to standard business relationships not unique to software. For example, how often is the customer billed, and how fast is payment expected? Software does offer more options for billing and payment (as illustrated by superdistribution; see section 9.2.4) than material goods or many other services.
9.3.5 Who Pays?
Another set of pricing issues relates to who pays. As is typical of many information suppliers, software suppliers (or more often service providers) are supported by third-party payments in return for advertising made possible by the low marginal costs of software distribution. For the application service provider subscription model, advertising can be tailored based on user profile, taking into account the application context and the specific user activity. For this revenue model, the determinant of value to the advertiser is user attention rather than the direct value of software features and capabilities to the user. Unlike traditional media, advertisements in networked media can be tailored to the user and updated dynamically, and can include hyperlinks to the advertiser's Web site, where unlimited information can be offered. This revenue model is one source of dispute over privacy policies, particularly where personal information is shared with advertisers or marketers (see section 5.3.2).
All the dimensions of pricing previously discussed are often interdependent. Usage-based or per-use pricing inherently requires periodic billing, a prepayment and debit system, or a pay-before-use infrastructure (such as digital cash). A supplier should not promise new versions (with the attendant ongoing development costs) unless they are purchased separately or there is ongoing subscription revenue. Similarly, an application service provider should expect subscription revenues to offset operational costs.
[4]The NET Framework is an example of a platform that supports side-by-side installation of multiple versions of a component.
[5]To be sensible, this definition of pricing nondiscrimination requires referencing "customer" to some common unit of use, like individual user or an e-commerce transaction. It wouldn't, for example, make sense to compare the gross margins of a sale to a large organization against an individual user.
[6]The difference is that in the software field the whole point of versioning is for customers to select from among a set of product variants based on their willingness to pay. Typically, only one software version is sold at a time, although there may be older versions still in use.
[7]This supplier strategy suggests that the complaints of airline customers about coach class are justified; in part, coach class must be unpleasant enough that less price-sensitive customers would not be tempted to fly coach.
EAN: 2147483647
Pages: 145