Pricing OperationsDec 16, 2024

Introducing m3ter’s reference architecture

Today, we're excited to introduce our Reference Architecture! In this blog, we break down the key principles behind it and provide a high-level overview with a handy diagram.

Griffin Parry, Founder m3ter
Griffin ParryCEO and Co-Founder, m3ter
John Griffin, co-founder m3ter
John GriffinCRO and Co-Founder, m3ter

m3ter’s core vision has remained consistent since inception. What has changed is our levels of confidence that our point of view is distinctive and right. Over hundreds of sales engagements we’ve built conviction about how lead-to-revenue stacks should be configured, and captured this best practice in ‘blueprints’ that cover the detail of implementation. These were initially developed as internal resources, but now we’re ready to share them more widely.

Today we’re launching our Reference Architecture. This blog summarises the points of view that underpin it and shares a high level diagram. The detailed artefacts are private to customers and prospects, but in the New Year we’ll release a series of practical ‘how to’ guides that are derived from them. [Can’t wait? Reach out to get early access.]

The challenge

Our core insight is that B2B software companies are often 'lop-sided'. They have fantastic product capabilities but their monetization capability - aka their lead-to-revenue stack - is less developed. To date it hasn’t needed to be particularly sophisticated because business models have been simple - mostly recurring subscriptions. But now business models are going through a period of rapid change and becoming more complex, with a shift towards usage-based pricing strategies. The obvious driver is the disruptive impact of GenAI, but other powerful trends include those towards automation, APIs, PLG, and more demanding customer expectations around attributable value.

That leaves companies with major challenges as they try to adapt their monetization capability to changing circumstances. They struggle to support new business models at all - in particular they find it hard to develop solutions for capturing and rating product usage data, and for distributing data about usage and billing continuously throughout the organization (to Sales, to CS, to the BI stack etc). They worry about automation - without it they have low productivity, and high fragility (meaning errors and revenue leakage are endemic). And they worry about dynamism - in fast-changing market conditions the quote-to-cash or billing systems are often a bottleneck that choke innovation around GTM and pricing.

But they are also highly committed to foundational tooling. For successful companies, these systems have been laid down in the growth phase, with many processes and workflows subsequently built around them. There are two key pieces. The Sales CRM (e.g. Salesforce), which is owned by and critical to Sales and SalesOps. And the ERP (e.g. NetSuite), which is owned by and critical to Finance. There’s very high inertia - nobody wants to give up control of these systems, let alone rip them out.

The solution

So what to do? There’s a lot of clutter in the space between the CRM and ERP, and to cut through it you need a third foundational piece that emphasises enablement and connection. This completes and unifies the stack by performing two key functions. Firstly, providing the missing metering and rating infrastructure required for complex pricing - processing usage data, continuously calculating bill amounts, and distributing them to wherever required around the organisation. Secondly, automating data flows between the CRM, ERP, BI stack, and the product itself.

Once this third leg of the stool is in place, it creates a framework that everything else can ‘snap into’. For specialist tasks (for example CPQ, tax calculation, revenue recognition, invoicing) you have your choice between best-in-class point solutions or products in the CRM and ERP suites. Teams work in the environments they feel comfortable in - ie Sales work in the CRM ecosystem, Finance work in the ERP ecosystem. And the overall lead-to-revenue system can support complex business models with a high degree of automation and easy adaptability to change.

The m3ter way

This is why we built m3ter - to be that third leg of the stool - and formed strong opinions about how to ‘wire it in’. Because we were solving a problem that we were well acquainted with from our previous company and at AWS, we thought what we were doing was obvious. But over time we realised our point of view was often surprising and profound. We saw this in the reactions of our customers - experienced operators who said ‘a-ha!’ and then proselytised about our approach to others.

So having developed confidence that we have distinctive know-how, we’ve now codified it in our Reference Architecture. This is both a vision about the capabilities that the lead-to-revenue stack needs to support, and a series of detailed blueprints about how to achieve these in practice. We hope it works as a roadmap and enabler for all those operators working in B2B software companies who struggle with their monetization capabilities.

This is available privately to our customers and prospects, but to give you a taster we’re sharing a high level ‘wall chart’ here (see diagram) that shows how processes, responsibilities, systems, and datasets should be aligned. The third key foundational piece - what m3ter is designed to do - is the cross-functional horizontal bar. We’ll be following up in the New Year with a series of artefacts that dive deeper into various aspects of the architecture, along with practical ‘how to’ guides about the detail of implementation.  Feel free to reach out to get early access.


Find out how your business can automate usage-based pricing today

See a demo, get answers to your questions, and learn our best practices.

Schedule a demo