Usage-based revenue models are increasingly mainstream but painful to manage
Selling ‘software usage’ rather than ‘software access’ (e.g per seat) isn’t new, but has recently become all the rage. Usage-based revenue models are embraced by an early adopter contingent that includes 40% of ScaleVP portfolio companies, up from 19% in 2019.
But there is still a surprising lack of automation products in use to support these revenue models. Instead:
Startups calculate revenue earned through batch downloads of usage data from the data warehouse, which is applied to a pricing plan in Excel.
Scaled companies will cobble together a billing engine with various automation scripts, often resulting in a frankenstein product that requires up to 50 engineers to maintain.
Both approaches are painful, inefficient, and error prone.
The ‘innovators’ and ‘early adopters’ of usage-based revenue models, who have pushed through this pain out of necessity, sell software that falls into one of two categories:
Products below the application layer (like APIs). Per seat models cannot work when there is not an application (though recurring enterprise licenses can).
Products best sold through product-led-growth. PLG requires a no or low entry-level price that is expanded on with upsell. Usage-based revenue models remove friction from the upsell process.
These categories have grown substantially, so tools built for usage-based revenue models now face a venture scale market. And a number of companies are approaching this buyer set, looking to make metered billing implementation plug-and-play (--just as per-seat billing has been for the last decade).
It’s an opportunity that rhymes with ‘Zuora’
The foundational opportunity to serve usage-based companies is in ‘metered billing automation’. That means helping customers with two things:
Knowing who owes them how much. (=Metering and pricing plan design)
Billing and collecting those amounts. (=The accounting stack... invoicing, payments, and revenue recognition)
This might sounds familiar — because Zuora [NYSE: ZUO] solved these problems for per-seat companies a decade ago, when adoption of the subscription revenue model was in crescendo. But despite similar business-user painpoints, billing automation for per-seat and metered products are very different technical problems. What separates ‘metered billing automation’ from Zuora is:
A more nuanced metering integration with the underlying software product
A more granular atomic unit of pricing.
Comparing this category to Zuora
Per-seat billing automation (Zuora):
Zuora integrates at the ‘identity layer.’ The identity layer is the software equivalent of a security guard checking for a ticket to an event, asking “are you authorized to enter?”
A seat and the features it can access is the atomic unit of pricing. The rate card will typically have one dimension (an agreed-upon price per seat) in addition to a platform fee.
Metered billing automation (new category):
The security guard granting access is replaced by a utility meter. Like an energy company’s meter in your home measures the voltage sent through its AC supply endpoint, a software metering engine observes a given service’s endpoint for usage (e.g. API calls). The operative question is “How much work have we done for you?”
A usage “event” is the atomic unit of a metered billing program. And just as an energy company applies tracked voltage to a billing plan that might have different daytime and nighttime rates, a software billing rate card (against which usage is priced) likely consists of credits, buckets of usage, or a volume-driven discounted rate.
Metered billing automation is a big problem to chew on, given flexibility and reliability demands.
Flexibility: Off-the-shelf metering infrastructure must be flexible enough to fit any monetization metric and pricing plan devised by a customer.
Reliability: Since failures of metering infrastructure will cause either revenue loss or overbilling, reliability is a key concern. The nitty gritty of reliability includes handling duplicate events, identifying and binding aliases for a single customer, and resilience to network issues.
Companies approaching metered billing automation include: Amberflo, Aqueduct, Kable, m3ter, Metronome, Monetize360, Octane, Orb, Ordway, and Subskribe.
What comes after metered billing automation
Metered billing automation is not the only opportunity in this world. Myriad downstream functions are entirely new or require an overhaul. While some will be consumed by the billing automation system, others might yield venture-scale outcomes as well. Some examples:
Revenue projections: revenue-by-customer is much harder to forecast in a usage based model and often requires sophisticated ML models.
example: Greenshoe
By-customer profitability analysis: multi-dimensional pricing plans make customer profitability more challenging to understand.
example: [looking for one!]
Deal desk/CPQ: usage based revenue models can have many dimensions of pricing, while traditional SaaS is platform + per-seat. CPQ products must also be an effective workspace from which to push a customer to ‘live.’
example: RevOps
Sales compensation: sales compensation must be managed differently where future revenue is less predictable and upsell a more important part of revenue growth.
example: Palette
SaaS metric management: Standard SaaS metrics are now critical for software executive to fly-by-instruments but more complex to calculate for a usage based revenue model, given that annualized revenue is not the same as ARR.
example: Subscript
Pricing experimentation: with many more vectors for pricing than just platform + per-seat, business teams will want to run pricing and packaging tests
example: Wingback
The base case & the upside case
Serving API and product-led companies (the early adopters of usage-based revenue models) is the base case for the category. Enterprise-focused application companies are a prospective early majority and present real upside potential.
Most application-layer companies have avoided the headache of implementing metered pricing and stuck to per-seat pricing to date. It’s less headache, but they leave money on the table with power-user customers who are charged no differently than a typical customer. Usage-based revenue infrastructure will enable application companies to easily monetize a value metric as well as seats. If well chosen, this metric will be high for the most engaged customers (who are willing to pay more), and lower for others. (Zapier offers a great example, charging both on buckets of seat count and buckets of live automations, “Zaps.”) As customers become more comfortable with usage-based components to software pricing, it’s easy to imagine this model proliferating further.