Though usage-based models are not new—having first been championed by AWS (2005) and Twilio (2008) — there’s been a notable increase in their adoption in recent years. This trend continues to accelerate as the landscape for usage-based models quickly evolves. In 2019, 19% of the Scale portfolio operated usage-based revenue models. Today, that has climbed to a significant 40%.
AWS and Twilio first launched usage-based models to enable below-the-app-layer products (with no seats to sell) that were also initially most resonant with startups (whose small size made them poor fits for term licenses).
Since then, usage-based models have been much more widely adopted – first by a growing number of similar developer APIs and utility-like products, but also by a broader set of application-layer companies. Most app-layer companies previously used a seat-based subscription model when it was the best choice in town for reflecting value (versus term licenses), but acceptance of charging on different metrics can be a game changer. Consider Zapier, an application-layer product where the value is best reflected by a usage metric (number of automations created) as opposed to by seats (number of users creating automations – usually no more than a handful). Zapier’s go to market motion is built around low cost adoption, with growing ticket sizes with customers who built a lot of automations – often through one or a handful of power users.
We’ve spent a lot of time as a firm helping our portfolio understand the differences between operating a usage-based revenue model versus a traditional, subscription-based SaaS model. In an April 2021 conversation of our portfolio CFO working group, we together identified four particularly challenging areas for the FP&A teams of usage-based companies: revenue forecasting, customer usage projection, enabling ARR-derivate SaaS metrics, and appropriate compensation of sales teams. Our CFOs have continued to evolve their approach to these problem areas, but have noted a lack of established ‘rules of thumb’ and benchmark best practice vendors.
These pain points called out by our CFOs make clear the opportunity to sell tools that enable the implementation of usage-based revenue models — tools that are reminiscent of (and potentially bigger than) those developed by Zuora, Chargify, and peers as the SaaS industry first matured. We are particularly excited about the scale of this opportunity for those companies addressing the pain points of usage-based revenue infrastructure.
Metering usage and calculating revenue are the primary tech primitives that companies tackling this problem space are focusing on today, though we expect this to enable and expand into tools for sales compensation, cost analysis, and forecasting as the pervasiveness of these challenges persists.
Following our April 2021 discussions, we saw a clustered launch of both specialist metering solutions and products that sit downstream of such metering (but often have built in metering functionality today).
A lookback on software monetization models
Before SaaS (in the 80s and 90s), business software was a shrink-wrapped product sold in a perpetual license model and owned by the customer. The only practicable method of getting software code to its destination was by physical means (e.g. floppy disk, CD, or hard drive). Once it was in the customers’ hands, it remained theirs. Without the capacity to gate access to the product on an ongoing basis, a software company could only entice additional revenue through software updates, new versions of the product or billable support services. In this world, software billing was not particularly a concern. There was no need to link ongoing billing systems to the product, and standalone invoices were easily generated from the ERP.
By the late 1990s, increased roll-out and accessibility of high-speed internet carved out a new path for software delivery. This innovation was pioneered by Application Service Providers (ASPs) — a category of some 300 companies that hosted third-party applications and first “rented” software . Soon, the first SaaS companies would emerge by iterating on this model with proprietary, cloud-native software.
Third-party application providers accelerated their revenue by simultaneously hosting the software they facilitated subscriptions to. The first ASPs controlled restrictable and revocable access to the software at a primary level — enabling the subscription revenue model at its core. By simultaneously hosting the software being accessed, an ongoing cost structure was created which ASPs also controlled and benefitted from. This ongoing cost structure acted as a catalyst for the profits of the subscription-based revenue model that ASPs were still busy establishing. The subscription model also created new challenges surrounding its execution. racking billing and revenue recognition events (on a separate schedule from sale events) were two primary pain points. As the subscription model permeated, ‘subscription management software’ that enabled its implementation began to emerge.
The earliest tools were built for telecommunications and would later be repurposed to charge for SaaS (Monexa, Aria Systems, and Vindicia). They were later followed by SaaS-specialist tools from Zuora (2007) and Chargify (2009). Early blog posts from Zuora — which discussed the initial pain points around subscription-based models — are similar in tone to the discussions around usage-based models happening amongst our CFOs now.
“One of the big disconnects in the on-demand market has been the constraints on product packaging imposed by billing systems. The on-demand model takes a product and renders it as a service, but existing billing systems more or less still bill for the service as if it were a product. Confused? Think of it this way: Conventional software sells product by the seat in a one-time transaction, while on-demand currently sells by the seat each month. For most situations, that works pretty well, but it works largely because it’s the only game in town. What happens, for example, if you negotiate a different seat price? Conventional product-oriented billing systems would have issues with that.” – CRMBuyer.com, May 2008; reposted on the Zuora blog; Link.
Zuora has since become the leading name in subscription management software, and excels in serving FP&A. Their functions — such as invoicing, collections, and recognition of subscription revenue —all reflect a primary focus on the billing and processing of recurring payments. Engineering organizations have never been a core constituency for Zuora and peers, for whom a historic depth of integration into product is the identity layer that keeps billing in sync with access.
Despite the recent proliferation of usage-based models, execution remains painful and an unsolved problem. The motivated solution-buyer in FP&A (–and their peer in engineering) cannot turn to the same subscription management providers that orchestrated billing at her last SaaS companies. These solutions were built for subscriptions and are too rigid to effectively integrate any deeper than the identity layer.
Enterprise level companies have resorted to building in-house billing infrastructure that tackles this issue. Twilio and Snowflake both employ 50 engineers on such internal products. Among more early-stage companies, exporting this data to Excel is common but a source of anguish.
When usage data is demanded in the CRM, CPQ, ERP, data warehouse, and customer dashboard Excel operations begin to buckle at the knees. These tedious, manual exports draw employees away from high-value work. Mid-market attempts to recreate the in-house systems created by Twilio and Snowflake often fail given the unprecedented and “submerged” complexity of the problem.
The architecture of a usage-based billing system
The architecture of a usage-based billing system consists of three fundamental components: event metering, aggregation of those events to billable metrics, and alignment of billable metrics to a customer’s pricing plan. It’s in the details of those three components that submerged complexities begin to unravel.
- Event metering: The core of any usage-based metering platform is an API that captures usage events as JSON objects and uniquely identifies the customer, timestamp, event type, and provides any explanatory details of the event that may be necessary to downstream consumers of this datafeed. An event is any discrete measure of usage that could result in a charge (e.g. an API call or a daily snapshot of storage used). In its API docs, Metronome paints the picture of a gate agent at a theme park equipped with a tally counter when explaining the tracking of such events.
- An event metering function must accurately ignore duplicate events, bind together aliases for a single customer, and be resilient to common failures such as network issues. A loss in revenue may result from any shortcomings in these areas. Building a standardized framework that intelligently defines discrete events as ‘usage metrics’ ” is the biggest challenge the usage-based model faces as a differentiator from incumbent SaaS billing providers. However, if successfully developed this model will provide a broad flexibility that will challenge the rigid, out-of-the box SaaS subscriptions that have enjoyed monopoly over software billing until now.
- Aggregation to billable metrics: granular usage events must be convertible to predefined billable metrics. While it’s possible to charge customers per API call, a tiered, volume-based, or stair step billing model may be more feasible.
- Usage-based billing platforms must be capable of applying pre-constructed billable metrics to usage data. Logic functions and arithmetics to carry out such conversions would need to be developed to do so. Combinatively, those functions and their successful interpretation of robust usage data will result in successful event metering functionality.
- Pricing: pricing plans should produce final billable amounts from such metrics, formulae and processes.t. Billable metrics may not be an infinitely fixed unit — active revision by engineers is possible and will enable the flexibility that is essential to the usage-based model. Pricing engines should enable flexible pricing plans that are based on approved, consistently monitored billable metrics. A pricing plan’s relationship to the cash cycle must also be defined i.e. whether charging is based on prepayment credits, or charging to an AR tally.
With these three functions, metering products enable the construction of flexible pricing plans, credit prepayment plans or payment determination processes. Go-to-market teams may be freed from the constraints of predefined pricing plans in the prospective stage of sales and marketing. Careful collaboration across the firm will be needed as finance, engineering, sales, and product attempt to unlock the unprecedented benefits of usage-based billing.
In order to overcome the pain points that Scale CFOs have highlighted to us, usage-based revenue systems must federate all of the relevant data detailed above into the cornerstone financial systems of the company. The billable metrics and events — and their summary pricing plans and corresponding transactions — must be translatable to central systems across finance (the ERP and forecasting tools), sales (CRM and CPQ), customer success (Gainsight and challengers) and customer dashboards. It’s our expectation that the current pioneers of these functional areas of usage-based solutions are well positioned as the solution to this increasingly broad, and high-value problem.
Acknowledgements:
Thank you to my teammate Alex Niehenke, Partner at Scale. He was instrumental in creating this post.
