Thought Leadership

2022: The year Usage-Based Pricing goes mainstream

January 6, 2022

3 main startup theses to watch in 2022

The year Usage-Based Pricing goes mainstream

A recent article from TechCrunch discussing 3 main startup theses to watch in 2022 caught our eye and provided additional validation that our own thesis at Amberflo is resonating. The article names the following theses for 2022: 

  1. Open Source will become the de facto startup model;
  2. Start-ups will partner with other startups outside of their obvious category for more hybrid applications/use cases; and
  3. The majority of SaaS companies will adopt usage-based pricing.

Naturally, the third section by Anna Heim was most exciting to us at Amberflo, as it lines up neatly with our own thesis that usage-based pricing will become the de facto monetization model for technology companies (not only SaaS, but PaaS, edge applications/infrastructure, and everything in between) because it delivers the most natural, fair and transparent consumption model for customers.

Heim cites this year’s annual report from OpenView Partners, 2021 State of Usage-Based Pricing, as evidence for the claim, where 45% of the 600 companies surveyed have already adopted usage-based pricing, 11% are planning to test it in the next six to 12 months, and another 23% plan to do so from 2023. 

Subscription pricing is dead

We have written about this very topic before here, but we’d like to zoom in on some technological facets of the issue. Clearly, seat-based or subscription pricing is on its way out. Customers have realized that the value of a solution depends on more than simply the number of users, and in fact can be inversely related. 

Consider the example of an RPA (robotic process automation) solution that is integrated with marketing and CRM technology to automate lead capture and qualification, and then push action items to sales users in the CRM depending on the quality of the lead. Since the value of the RPA solution is based on reducing the manual tasks involved with capturing/qualifying a lead to drive engagements with sales, the number of users permissioned to use the RPA solution could be very small - maybe, only one or two system admins to define the workflow and troubleshoot if errors or updates occur, so this isn’t financially viable to the vendor. On the other hand, permissioning every sales/marketing user who benefits from the system with a license for the RPA solution would likely be financially unfeasible to the customer and would certainly seem unfair, leading to a greater likelihood of churn. 

In this case, the most fair and financially sensible solution is to price based on activity or usage of the RPA solution, such as the number of qualified leads and the number of sales meetings set from the automated workflow. This way the customer is paying a transparent rate that can be directly tied to the value derived from the solution, and the vendor can define a rate plan for the different price factors in its solution to ensure a sufficient return for the service while increasing customer trust and satisfaction. 

This is just one example, however business applications are becoming increasingly integrated as business itself becomes less siloed by factors such as departments and geography, and businesses increasingly align around cross-functional, end-to-end processes (such as the move toward integrated customer experience (CX) versus isolated sales, service, and marketing technology stacks).  As this trend continues, it will only become more and more difficult to justify subscription pricing models, which is likely why we see such a stark acceleration in UBP adoption from 2019 to present day.


Proliferation of microservice-based architectures

Another factor contributing to the proliferation of UBP among SaaS vendors is the rise of microservice-based architectures. Cloud-native SaaS applications are increasingly made by cobbling together loosely coupled services that communicate with each other to coordinate complex tasks via APIs. This dramatically simplifies development, as it reduces the need to re-write code over and over, and different modules or functions can easily be developed, tested, and implemented in parallel. The strategy lends itself to SaaS for several reasons, namely: ease-of-development as described above, the potential to isolate faults without compromising the entire system, more granular scalability - each service can scale up or down as needed to optimize both performance and cost, and faster recovery - in the event that a service goes down, it doesn’t take the entire application down with it. 

Interestingly, the architecture also lends itself naturally to a usage-based pricing model. As each of the services complete discrete, predefined tasks, it is an intuitive next step to define pricing for each service or task. Since the services communicate with each other via API, it is also natural to leverage those API calls to define meter events and track usage as it occurs. As we see this strategy becoming the status quo in SaaS development (for good reason), it follows that a new pricing model optimized for that architecture would come into vogue. Enter usage-based pricing. Look for the momentum to grow even more through 2022 and beyond. 

Our platform is designed from the ground up to serve as the underlying scalable and durable architecture for enabling usage-based monetization models and processes. 

Our fully-managed, Metering Cloud Service operates independent of pricing and billing, and can process billions of usage events in real-time and automatically transform, aggregate and group events to provide actionable insights to all teams on product usage - what was used, by whom, when, where, and how much. 

Our fully-managed Billing Cloud Service integrates with Metering Cloud to pull in accurate and real-time usage data and enables build out of modern Usage-Based Pricing Plans, on-demand metered Invoicing and Billing, Price Modeling, Credits, and more.

Subscribe to our Newsletter

Delight customers with on-demand metered invoicing and billing.
Oops! Something went wrong while submitting the form.