The Ultimate Guide to Smart Software Pricing Strategies

Introduction

This article looks at designing a software pricing strategy that maps to the product architecture, and, of course, to the market opportunity. Ownership of the responsibility for pricing may differ dramatically in a company. In some cases, sales, deal desk, or marketing may own pricing, in others, product management may own it. Regardless of where the core responsibilities lie, the product must be able to provision, track and report against the selling meters considered in a pricing structure.

Designing an effective pricing strategy and business model is one of the most important jobs in a go-to-market plan. It is not an exact science, but a process of constant negotiation, market validation, operational validation, industry competitiveness, and customer acceptance.

Section 1: Explore Software Pricing Models

The goal in any pricing model is to entice customers to purchase with minimum controversy. Be clear on the logistics relating to measuring usage in order to have a viable and sustainable model.

Licensed Software

Licensing software implies permission for someone to use your software–either as an individual or as an application that would be tied to the equipment on which it is installed. Product Managers define the terms of usage. The legal team will help define the legal rights that will be tied to the end user license agreement (EULA) and any channel/partner agreements. In this model, pricing is often accompanied by setup or installation (or provisioning) fee and a maintenance fee.

The upside of software licensing pricing models is that revenues are received up front–a one-time boost to the bottom line. The downside is the risk of not having a strong relationship with clients. To get new revenues from the same client often involves a longer sales cycle. For the client, often licensed software is a significant cost, and their preference may be to pay monthly or to be able to manage their cash flow more effectively.

Subscription Software

Software-as-a-Service (Saas) or cloud models imply that a subscriber will “rent” the service–so the EULA would be replaced with an end user services agreement (or similar terminology) that defines access permissions and terms of use associated with using the service. It is important to define the method on which the systems will count and charge for services.

Subscription services should be measured as a value of usage metering over time. Various models may be used for a services agreement, including:

• Freemium: Often used as a “loss leader,” a freemium model implies that the service received is free of charge. When designing freemium models, the expectations are that it is a very simple version of the offer and that the vendor would expect most users to graduate to a paid version. Limitations would typically be based on the volume of usage. For example, an expense and invoice management Freemium package may only allow a customer to have 3 active invoicing accounts, may not include payroll processing, etc. But for “nominal monthly fee” customers would be able to “turn on” the additional features.
• Usage fees: Usually a recurring fee for the services being rendered in the SaaS model. Various meters may be required for usage rate calculations. Consider these carefully, as the more complex the rate, the harder it will be for customers to estimate their consumption (for budget purposes) and the more complex the contract negotiations will be. Keep it simple. Some meters to consider:
  • Transactions per Second (TPS)–a simple count of concurrent transactions in each second, as an average over time. This meter is often used in telecom services (i.e. SMS messages). Some systems will measure every 5 minutes, then divide by 300–as a method of calculation. Then, from a billing perspective, the highest number of TPS (Peak TPS) is the meter on which any royalties or fees are calculated. If the pricing is calculated with usage breakpoints against volume discounting, traditionally usages would be rounded up to the nearest Peak TPS category
  • Number of transactions (i.e. API calls) in each period–or as a block that, when used up, must be renewed
  • Megabit per second (Mbits/s, Mbps do not confuse with Mbits/sec which would be millibit per second) — or Gigabit per second (Gbits/s, Gb/s or Gbps)–also used for data transfer measurements, often in high-speed networks
  • Storage meters–used as a static count of how much storage was used in each period
  • Number of subscribers–measuring unique identities that are allowed access to the service; simple count
  • Number of concurrent subscribers–measuring the maximum number of concurrent subscribers–think of this as a pool of licenses that can be shared; this meter is not used often in SaaS/cloud services anymore, as it can lead to complex auditing
  • Minutes or seconds–used often with telecom applications; a count of time on which to meter charging
• Revenue Management: Identify the term period that will make sense for the business. What is the term? Is it a 3-year contract paid annually up front (i.e. Salesforce model)? Is it a one-year license prepaid? Is it a monthly post-paid? How will the system deal with true-ups? What about handling upgrades or migrations against contracts in the process? How about cancellations? What about incentive programs or rebates?

Spend time with the finance team with respect to the appropriate revenue recognition elements. Keep in mind that when considering revenues, also consider the sales compensation models. Success in any sales environment will mean that the sales team must be adequately and appropriately compensated to keep them selling.

Services

Often, when we think of services, we think of support services–but there are many services that can form part of the product offerings.

• Onboarding/Integration Services: Usually for B2B types of services, onboarding may also be described as set up, installation, or provisioning fee–often a one-time “get it working” fee that is used when there is proprietary system integration required. Integration may include elements referred to as operational support systems (OSS) and business support systems (BSS):
  • Connecting with a billing system for flow-through revenue management
  • Connecting with a CRM for subscription management; sharing of customer data
  • Connecting with an authentication process (OATH, Radius, Diameter, Active Directory, SAML, etc.) to ensure that only authorized users can use the system, and to track usage
  • Application connectors (i.e. connecting to a network service, a POS service, an internal database, an e-commerce engine, a catalog, etc.)
• Maintenance Services: Typically tied to licensed software, maintenance fees are NOT support services, but simply the fees associated with the right to obtain new releases, upgrades, bug fixes. Maintenance services would typically not include new feature functionality unless specifically included (legal contract) in the business relationship. In a SaaS model, maintenance fees are considered part of the subscription fees (and should be accounted for in your revenue breakdowns).
• Support Services: Typically tied to the ability to access a knowledge-base, or with someone to get help. Support services may also be associated with a service level agreement (SLA) which defines the terms under which support will be provided, along with remedies (escalation, liability) for performance. In a SaaS model, maintenance fees are considered part of the fees (and should be accounted for in the revenue breakdowns; as those departments will want to share the overall revenues).
• Customer Success: An emerging professional service–for cloud service providers, leveraging a paid customer success offering can extend the customer lifetime value (CLV); provide the analysis to continue to demonstrate value, and showcase the integrity of the company by showing that the sales commitments are being met (i.e. ROI analysis).
• Professional Services: Typically a team of developers that would be paid on a one-time basis to perform some specific services. These may include feature enhancements that would be specific to that customer, branding, product customization, etc.

Section 2: How to Price a Software Product

Getting to the right price is one of the hardest challenges for the product manager. We will be looking at various elements that must be considered, in order to get to a viable price for your business.

There are two basic initial approaches to making the right decisions. Cost-based pricing can be used as a benchmark to validate the LOWEST price that you can consider. Value-based pricing can drive the best return for a product investment.

Cost-based Pricing

Every company measures gross margins — the costs of delivering the product/service. Pricing must be established to meet or exceed the gross margins goals, based on a business plan with expected revenues. Ideally, this should NOT be a method of determining the pricing that is presented to the market.

Value-based Pricing

Take the time to determine value-based pricing, especially in a SaaS opportunity. In a value-based pricing model, apply quantitative estimates to the differentiable value of the offering against the current customer situation. Does it save them money? Does it make them money? Does it reduce risk or liability? Does it provide value? How much over what period?

There are multiple approaches to coming to a number, but as a starting point–do the market research. Find out what are the numbers that others are using. Determine if they are getting discounts, and if so, what is the foundation for the discounting? Make sure to explore what associated services are being charged for, and for what rates. Do the homework as a valuable tool in developing the confidence to defend pricing proposals.

The price(s) that are discovered from your market research will be the number on which to create viable ROI models. This is NOT the price on the price list.

With a sense of the amount that the market would be willing to pay, step forward through the business needs to come up with the manufacturer standard retail price (MSRP). The MSRP is the value that would go on any commercial price list.

Evaluate Potential Routes to Market

Although the company may have a direct-to-customer pricing model today - be sure to consider the “what-if’s” that can change the business models at any point in time. Design for the long term.

• “What if my big customers want to resell this to their customers?”
• “What if I want to put this onto a marketplace?”
• “What if I have to give away huge discounts in order to make a deal?”

Consider the models of:

• “Sell-to”–someone that would use it for their own consumption (only their employees can use it)
• “Sell-with”–working with a partner who may want compensation with a referral fee/finder’s fee
• “Sell-through”–engaging an indirect sales team, or selling through a marketplace, where fees are paid to that partner in the form of commissions, revenue share or other variations thereof

Find out what standard compensation models are for channels and partners. Incorporate these into the pricing up front, so that when they come along the company won’t find itself at the bottom of the gross margin battle.

Consider Your Discounting Tiers

Be assured that the model will need volume discounts. Find out the largest potential customer, and calculate the meter associated with their volume and add 50%. That is the biggest discount level to start with. For simplicity (and SKU management), limit the discount levels to only 5 or 6 levels.

Look at the market. Determine where the customers are on the volume scale if the meter relates to volumes of usage. For example, in selling to a telecommunications service provider in a specific geography–and the largest service provider had 50M subscribers; (with subscriber-based price) calculate the largest discount level for 75M (50 x 1.5 = 75M). If more than 25% of the market are equally large, a discount table might look something like this:

It really depends on evaluating the target market. If this customer was an anomaly–then look at the overall customer base and determine where most of the customers will fit. For a customer base of smaller customers, it’s still important to address the larger customers, but consider that the demand for discounting will come from the smaller customers.

Design a scale to meet the requirements of the specific market. This will require a lot of discussions with the sales teams who work with these customers on a regular basis. Try to keep the levels simple. Expect a challenge with pressure to have low tier rates for everybody’s smallest customers. Find the sweet spot (the customer size that the sales teams should focus on) and identify the discounting appropriate for that market segment.

Section 3: Design an Effective Pricing Architecture

Before putting numbers into the price plan, consider the software architecture. For SaaS services, consider the model below. It represents a structure that puts data at the core — this may be the one thing that the company does not market. Apps represent the actual SaaS services that are being marketed–but there are potentially the platform access (APIs), and the microservices or data feeds that become additional revenue sources.

Price accordingly. If the desire is to leverage the core data and microservices to create more and more services, then structure most of the revenues to the platform.

Do not overlook the overall solution architecture. As a SaaS provider in a B2B scenario, consider the inputs and outputs in your pricing structure.

For example, a pricing breakdown for the pricing analysis might load the revenues towards the platform and data feeds, leaving only 20% of the revenues associated with the UI–the app:

With an organized pricing model, the addition of new Cloud Services (SaaS apps) can be priced in line with other SaaS Services. Likewise, by having the breakdown ready, it is easier to consider more creative pricing when it comes to APIs and microservices. This model supports the demand that may come from customers to “…just give me the data and I will incorporate into my own UI.”

Be assured that as the product family grows, sales, solutions engineers and customers will all want to compare new service pricing with the old. Having a structure for pricing will simplify the position and recommendations.

Before you finalize your pricing go back and look at your gross margins. Predict what the impact of growth will be in your operating costs (especially with a SaaS model), and ensure that you are within the corporate financial goals.

Section 4: Pricing Model Flexibility

Approach the pricing strategy with a mindset that represents professionalism in creating logical, reusable pricing that will survive the test of time. Be prepared to adopt new pricing, new pricing meters. The ability to adjust pricing quickly will give the company a strategic advantage over competitors.

Design the software accordingly to capture and report against logical meters that suit the current and potential service offerings.

Conclusion

When pricing software products, structure an approach that is simple to explain. Identify logical meters for the pricing strategy that can be measured and audited. Design the platform for reporting and auditing and expect pricing meters to change. Get it right and the deal desk will be able to work most sales opportunities without having to come back and negotiate pricing for each exception.