At our previous startup, we experienced the challenges of implementing usage-based pricing (UBP) firsthand. Then, after selling the company to Amazon, we worked for several years at AWS, a pioneer of UBP, and saw how they coped with the same challenges - in other words, we saw what good looked like.
Benefiting from these insights, we created m3ter to help companies intelligently deploy and manage usage-based pricing. It integrates easily with existing systems and i) meters and rates usage data to eliminate billing operations pain and ii) provides tooling for Sales, Success, and Finance teams to help them sell, price, and forecast better.
We have a particular way of looking at usage-based pricing. This blog explores our perspectives and how they frame what we do.
Deploying and managing UBP requires new operational and GTM capabilities, but these are not supported by the systems typically used by SaaS companies - the leading Sales CRM, billing systems, finance systems, and analytics services. However, these systems are generally great tooling that would be disruptive and expensive to replace. So, m3ter is conceived as a ‘drop in’ solution that makes existing tooling work as needed for UBP, rather than replacing it.
We achieve these integrations via APIs, webhooks, and connectors that map data object models. These allow m3ter to ingest usage data, account details, and pricing plans easily. But just as importantly, they allow usage, cost, and spend data to be delivered wherever it is needed throughout the stack – these data sets are the lifeblood of a usage-based pricing business.
A critical destination is the billing system so accurate invoices can be generated and the books can be closed fast. But others include the SaaS platform (to support billing dashboards for customers), the Sales and Success platforms (to enable well-informed and timely conversations with customers), and analytics tools (to put the right information in the hands of leadership and Finance teams). We’re quite happy for m3ter to fade into the background and provide ‘fabric’ that enables workflows between and within these systems.
We assume that companies who want to embrace UBP – particularly in the software vertical – will also be keen on continuous integration and delivery concepts, and seek high levels of automation. Undifferentiated heavy lifting by humans should be avoided where possible – it’s slow, expensive, inaccurate, frustrating, and scales poorly.
That’s why we’re an API-first service, with all interfaces exposed via API. And why we make things scriptable and embrace ‘pricing configuration as code’ concepts.
This doesn’t mean we don’t offer great UX for non-technical users (like sales people or billing operations folk) to support their workflows – we do, surfacing these in the systems where they spend their time in (like the Sales CRM) or in the m3ter console if there is no appropriate host. But we start with the developer and put them in control.
There’s a temptation to think usage and spend data is only needed on a monthly cadence because that aligns with billing cycles – i.e., it’s only needed to create the invoice.
In reality, usage and spend data are needed much more frequently – ideally daily or better. Various stakeholders want to know ‘the score’ on a near real-time basis: how much has been used, how much spend that has driven, what the trends are, and where it’s likely to end up at the end of the month. This includes the customer, because they want to understand and control their spend, but also Sales and Success, so they can have well-informed, timely conversations with customers. It also includes Finance and Product teams, so they can manage the business effectively.
That’s why m3ter allows up-to-date usage and spend data to be served on demand to the systems that need it.
Usage-based pricing models can become very complex, very quickly. There are many potential usage vectors against which to price. There are many pricing model variants: tiered, volume, stair-step, etc. Commitments, credits, and promotions are common. And custom pricing for individual customers is often driven by Sales and Success folk adapting standard pricing for high potential accounts – emergent behaviours are often surprising!
We don’t presume to know what pricing would work best for our customers. Our objective is to put a flexible tool in their hands that allows them to find their best pricing and deploy iterations quickly. m3ter’s rating engine operates as a ‘math engine’ that is built around four key data objects – accounts, products, price plans, and usage – that can accommodate almost any billing logic, including variations on a per customer basis.
If you deploy UBP, at minimum you need to measure what you’re pricing against and capture this with sufficient granularity to support accurate bill calculations.
But measuring more than this helps you identify improvements. This starts with usage. Measuring many usage vectors allows you to see what pricing models might work best; it’s better to measure first and then decide what is important, rather than the other way around. However, you should also measure costs (meaning the variable costs to you of supporting usage) and consider spend (i.e., the benefit to you after pricing has been applied) as a data set in its own right. This is what the ‘3’ in m3ter represents – usage, cost, and spend – and pricing optimization lies in the inter-relationships between them.
m3ter records key dimensions (Who, What, When, Where) for every event, transforms them with extreme normalisation, and persists them in ‘raw’ form. We do this to deliver pricing flexibility, but also to enable data science. This focuses on forecasting and pricing recommendations, with m3ter’s rating engine allowing these to be deployed with a click.
Ready to get started? Talk to our team for a demo, answers to your questions, or to learn our best practices 1:1.
In this article…
Explore more topics
#Finance #Sales #Dev #ProductUpdates #Other #People #Product
See a demo, get answers to your questions, and learn our best practices.Let’s Talk