As a seasoned software marketing and operations practitioner, I've dedicated a significant portion of my career to B2B technology, specifically focusing on billing, invoicing, and monetization solutions. For over 30+ years, I've closely observed the evolution of software billing. Now, we stand at the precipice of a significant shift that will finally deliver what customers have long desired.

From a customer's standpoint, the desire is clear–they want to be paying for a solution based on their use of features that they define as most valuable. Moreover, they need to demonstrate a positive relationship between the value derived and the price charged to use the solution. These requirements are the essence of value-based monetization and, unfortunately, a tough challenge for most software vendors to meet.

The need to understand value isn’t a new customer requirement. Otherwise, why were past sales teams always begging marketing for more ROI slides in their “decks” or wanting the website to have an ROI calculator - most of which we based on numbers we made up in the marketing department (by the way)? On the surface, proving customer value sounds simple. If you solve a problem, you can assign value to having the solution vs. not having the solution. Right? Wrong. If it was that simple, why are we just now seeing the emergence of technology that enables monetization aligned with customer value? And why have software companies repeatedly relied on billing and pricing models that are more convenient for them versus the customer? It’s helpful to look at a brief history of software billing to understand how we got to where we are today.

Ah, the Enterprise Days - Licenses Fees + Professional Services

Software companies have a long history of charging and pricing their products based on what’s most convenient or supported by product engineering. Some of you may also remember the “good old days” of huge upfront software license fees (issued via a manual invoice), followed by annual “maintenance” payments and large professional services contracts. Margins were sky-high on software licenses, vendors loved the profits, and the engineering team didn’t have to worry about billing functionality. However, demonstrating customer ROI was “thorny" and based on broad assumptions. It was a rare customer who could tie the considerable fees paid to the value received. Most professional services fees went toward customizing the software to address a customer's specific needs, further shifting the ROI equation.

Yay, it’s Saas, it's cloud-based (mostly)

With the advent of SaaS solutions in the early to mid-00s, customers were wary of off-site data storage and losing control over security and solution functionality. Boosted by Saleforce.com's initial success, software companies of all types evolved to SaaS and adopted recurring revenue licensing models to appear customer-focused. And it worked—customers felt better for a while.

Sales pitch: "We have a deal for you. It’s like pay-as-you-go, but you still need to sign a 3-year agreement."

Recurring revenue was a clever way for software vendors to bill and collect license fees in chunks, retaining a longer contract value while giving their CFO revenue recognition headaches and their investors’ financial peace of mind. Recurring revenue provided predictability for the vendor, and customers were receptive to the smaller, “budget-friendly" payments versus upfront license fees. But in the end nothing really changed for the customer, and what really matters is their ability to link what they paid monthly to the value derived.

Hello, Subscriptions! (aka “The Netflix Economy")

Close behind recurring revenue came subscriptions. Subscriptions enabled software vendors to justify the basis of recurring revenue models via “product feature packages" as they moved away from multi-year licenses. Annual contracts, however, were still encouraged via discounting.

To create “subscription-able" products, software vendors grouped existing product functionality and licensing terms based on the features the engineering team could provision independently. Many models of subscriptions emerged. However, all of them shared tiers based on their perceived value to the customer. Some of these models included:

• Subscription tiers are based on the number of seat licenses or selling groups of seats in bulk for a recurring fee.

• Grouping high-value functionality, as defined by the vendor, with a bunch of functionality that isn't needed or likely to be used in to the highest-priced tier. Other subscription tiers include smaller chunks of functionality progressively, leaving high-value features trapped in high-cost plans.
• Vendors with an “easy-to-count” or measure feature (# of emails sent, # of servers used, amount of data storage, etc.) used that basis to create tiers and lay functionality on top of it. These nascent “usage" based subscriptions tried to build on quantifiable features that may or may not be valuable to customers or were the basis of "hybrid" feature and usage-based subscription tiers.

In short, while subscriptions are more flexible, they primarily reflect a vendor-centric revenue and payment approach rather than a monetization strategy tied to customer value.

Usage-Billing: The Path to Value-Based Monetization.

Usage-based monetization is the proper pricing and product approach for software and solution vendors who wish to align billing with customer value.

Luckily, charging for a service based on consumption is not a new science. Long before software companies discovered relationaal databases, telecommunications and utility providers relied on usage for billing. Using custom-built billing solutions, telcos could count the number of phone calls you made, determine if they were local (free) or long-distance (paid), and measure how long you talked. These calls were charged according to your rate plan, and your bill was generated. Utilities did the same, measuring how many kWh of electricity or gallons of water you used during your billing cycle. As a consumer, you understood exactly how much you used and how much you paid.

As software vendors' shifted to SaaS delivery models and recurring revenue and subscription billing requirements expanded, the number of SaaS and cloud-focused billing solution providers also increased. Most of these emergent billing software vendors relied on code foundations and operational principles engineered for telecom and utilities. This approach made sense as these platforms included a foundation for plans, account provisioning, and recurring payments. However, this approach also means that to this day, billing software functionality heavily influences, and in some cases limits, how software companies can charge their customers. As a result, the migration to adaptable software consumption billing and customer-focused monetization strategies has been impeded and customers expectations are not being met.

So, what does all this mean for software and solution vendors who want to bill based on usage and value?

The good news is, as hinted above, usage-based billing isn't entirely new—it's just more complex for vendors who want to create alignment between consumption and customer value.

The bad news is that most existing billing, invoicing, and payment systems need new tools for metering in order to support value-based monetization. Metering is the key to aligning usage with customer value, but it can often confound software vendors.

In a follow-up post, I'll dive into the requirements for usage-based metering that meets the needs of customers and works with current microservices and data-centric solutions.