Solving the Puzzle: Pricing, Licensing & Business Models

This white paper is based on a “Birds of a Feather” presentation and discussion at SoftSummit 2006.
The right software licensing and pricing decision is frequently context-sensitive, so those in attendance were treated to an open-ended discussion of critical decisions rather than the usual lecture-style presentation.
Attendees were asked to think about:

Today, almost all software vendors are doing something in the SaaS arena. Salesforce.com, NetSuite, Yahoo! and Google are well-know SaaS developers, but IBM, Oracle, SAP, and Symantec are all moving that way too. Single-user desktop applications are under the least pressure, and are moving the slowest.
SaaS vs. Traditional Licensing
A basic truism for any software developer is that over time revenues and expenses have to match. One can only “borrow” against future revenues, for example by using capital inflows, for a limited time. The smaller revenue flows from SaaS applications mean that investments in Sales, Marketing and Development need to produce revenue impacts sooner rather than later.
Traditional licensing with its up-front payments more easily supports heavy investments because the revenue payoff is concentrated at the front-end of the customer relationship. On the other hand, SaaS applications require smaller initial outlays from the customer, removing a big hurdle to new customer acquisition. The vendor is provided with a smaller, but continuing, revenue stream and encourages a closer relationship between vendor and customer that may lead to better long-term retention.
Customer Considerations
Cost and Capabilities are key considerations for any software purchase. In some cases, the IT organization may have different goals from the operating units that want a specific software application.
SaaS offers a number of benefits on both the cost and capabilities fronts. These include:
Cost considerations

• Initial versus lifetime cost of the license
• Whether the software is considered a current or capital expense by the customer organization
• The cost of maintaining the necessary IT infrastructure. Big, important software applications require robust servers and people to keep them running.
• Switching costs in the event the customer later changes their mind.

Capability Considerations

• The direct and indirect costs and hassles associated with maintaining and updating the application.
• Hosted applications offer immediate access to future capabilities and upgrades.
• SaaS-based vendors are often able to offer innovative and capability-rich applications?

Organizational Considerations

• Is Corporate IT friend or obstacle? If you are trying to end-run Corporate IT, an application that requires lots of expensive, internal IT infrastructure is a non-starter.
• Faster time-to-value
• Ease and speed of deployment.

Vendor Considerations
Software vendors must consider development, support and sales considerations. SaaS offers important benefits in each area of consideration.
Development

• A single code base can support many licensing, hosting and pricing options.
• A single, hosted version reduces resources required for maintenance of older releases (bug fixes, etc.)
• The architecture employed generally supports faster development innovation.

Support

• Keeping all customers on a single release means there are no legacy users to support.
• On-going, “rental” payments help to foster a stronger, long-term relationship with customers. This often pays dividends in both sales and product development.

Sales

• Lower initial costs allow sales to reach smaller customers and customers willing to try, but not yet buy.
• Rental and on-demand models are simply preferred by some customers.

Areas of Potential Conflict

• It is not all peaches and cream, there are some areas of potential real conflict between users and vendors. While there are counter-arguments to each point, there are real issues for some organizations that are not always easy to reconcile. Key areas of potential conflict include:
  • Commitment. In the long-term, despite the lower monthly cost, “renting” may not be cheaper than “buying” a perpetual license if you are planning on running the application for a long time.
  • Depth of customization. The efficiency of a single code base inherently limits the depth of customization vendors are willing to support.
  • Hosting. Some organizations are unwilling to run critical applications outside of their firewall. Whether this is a real or perceived issue is beyond the current discussion.

  
  Setting the Price
  Pricing should be a methodical exercise. If there are constraints such as lower cost competitors, then these need to get baked into the vendor’s business model. Each component of the solution needs to carry a cost. For example, maintenance & support, license, hosting, and financial risk are all positive costs for which the vendor should charge the customer and establish a base price. Beyond this, the vendor also needs to consider elements such as: competitive parity, usage and reputation / brand. Added together, these will show the appropriate subscription price. If the vendor’s marketing or sales people feel the price–when properly justified–is unsaleable, then the product offer needs to be adjusted to bring the value in line with the price. Both the price and the offer components are in fair play for adjustment.
  
  
  The figure above shows a graphic comparison of perpetual versus SaaS fees. In this case, the vendor “breaks even” with SaaS after three years. Up until this point, the vendor generates more revenue with a perpetual license and maintenance fees. After three years, the vendor nets more revenue with SaaS. There is nothing fixed about this scenario; the vendor can adjust initial license, monthly license, maintenance, and hosting fees to make to change the slope of either or both lines. The real point here is that the vendor needs to proactively shape the pricing to deliver the appropriate value and revenue to each party.
  This whitepaper is based on a “Birds of a Feather” discussion facilitated by Nilofer Merchant or Rubicon Consulting and Jim Geisman of Market Share.

  • Tweet