From product to cash in just six weeks

Okay, so you’ve decided to go with Usage-Based Billing, and you’re even thinking about using m3ter to do it. This blog will walk you through a lean solution that you can deliver in just six weeks — integrated to Stripe, Salesforce, and Salesforce CPQ. This post is dedicated to those of you who are looking to quickly automate a usage-based billing product, or are trying to rapidly bring new products to market — turning your consumer’s behaviors into cash as efficiently and quickly as possible. 

There’s an ongoing joke amongst product managers about the trifecta of Good, Fast, and Cheap — the joke is to pick two and then select the accompanying problem. Something that is Good and Fast will be expensive; something that is Fast and Cheap won’t be performant; something that is Good and Cheap will take forever to implement. But I have good news! You can quickly and scalably turn your product events into bills by being savvy about how you connect your tooling. The sequence is roughly as follows:

I’ve highlighted subscription management in blue, because it’s optional but beneficial to consider as part of your stack at launch. Let’s go through each element one at a time and then we’ll look at a calendar of events to understand how to sequence delivery. 

Product to Cash Systems

Product Data

This is the responsibility of your product and engineering teams — the event data for which you intend to charge a customer. For usage-based billing, you need enough telemetry to stream every product event you want to eventually charge for into m3ter, but you do not need to pre-aggregate or transform them! You can do that directly in m3ter, on ingest. 

m3ter

m3ter is your pricing, billing, and analytics tool for those product events — it’s where your usage-based pricing comes to life. The product events that stream into m3ter are aggregated and priced based on the plan you’ve created. m3ter also manages committed spend balances for usage-based billing, which we’ll get to in more detail in a moment.

Payment Gateway

many SaaS providers use Stripe to handle their credit card payments, but they have also developed capabilities around invoicing, tax, and fraud that are super useful for this use case. 

CRM

m3ter provides integrations to both Salesforce and Netsuite, and API access to outputs of its aggregations for other providers. There is a tremendous advantage to using the metering data inside of these tools, which I’ll explore a little bit more in my last two blogs. I’ve left ERP out of this diagram, because many startups have not had the time to bring accounting fully in house yet, or may not have finished a Netsuite implementation at the time that they’re trying to bring their product to market. Some companies may prefer to start with the Netsuite integration first, which is fine! Just imagine it in place of Salesforce in the scenarios I describe. 

Subscription Manager

I’m using this term to refer to software that helps your sales teams establish and update contracts — the function the applications will provide in the context of this implementation. There are a lot of tools in this space, and they all tackle the problem a little differently, so it’s important to assess them carefully to decide which is the best fit for your business. You can implement usage-based billing without them, but they provide great benefits for enterprise, usage-based deals where you are selling the customer a balance. I’ll use Salesforce CPQ in this blog as an example, and will cover why when we get into the implementation schedule below. I will mention that implementation of some of these tools can be complex, so if you are on a tight timeframe, working with an implementation partner is a great way to reduce delivery risk. 

The Delivery Schedule

What’s nice about m3ter is that you can split effort between Engineering and IT teams: think of it as the race to build the continental railroad, with each team meeting in the middle. Because I’ve listed a CPQ implementation, I’ve included it in my timeframe. Note that there is a first release at six weeks, and another release at ten weeks in this timeline: 

In this scenario, your IT teams and Engineering teams share responsibilities in m3ter and in your payment gateway. IT may be configuring tax and invoice structures in Stripe while your engineering team configures the actual payment registration and attaches it to product. And while Engineering will be administering aggregations, plans, and prices, IT will be most involved with the m3ter integrations to tools like Salesforce and Netsuite. Make sure you define the boundary areas and your handoffs — they’re important to ensuring a smooth end to end process. 

The first release in this flow happens at six weeks and covers your ability to collect ongoing, usage-based payments from your pay as you go customers. The second release happens afterwards and enables your ability to sell committed spend deals. This is because this blog is written for a start-up audience launching a new product, and in these scenarios there is not usually a waiting backlog of annual deals for products that have yet to release in a month-to-month format. 

Let’s break down each sprint. Note that you won’t be implementing by yourself! m3ter’s team stays deeply engaged to ensure your launch is a success and can help guide your engineers every step of the way.

SPRINT #1: CONFIGURING M3TER AND SALESFORCE CPQ

As I mentioned, you don’t have to have CPQ to make this process work, but it has benefits that show up later in the committed spend deals we’ll review in later sprints. In this sprint, you want to lay down the frameworks for both tools — you want your engineering team to stream product events to m3ter, aggregate and price them, and set up the plans your customers will buy. Your IT team should be configuring opportunities, products, subscriptions and renewals inside of Revenue Cloud. This puts the fundamentals in place to let the two systems talk to each other, which brings us to …

SPRINT #2: INTEGRATIONS

At this point, your engineers should be connecting product to the payment gateway of their choice. m3ter has integrations to Stripe and Chargebee, as well as the capability to send bills into Netsuite, so whatever you choose, the primary goal is to get m3ter’s bill data into that payment gateway for invoicing and payment. However, realistically, you also have to integrate that payment gateway into product, since you need a way to capture a customer’s payment details — and probably don’t want to store that yourself. On the IT side of things, you’ll be working with m3ter’s support team to configure the m3ter to Salesforce integration, which ingests all of the m3ter objects as custom objects in Salesforce. If you want, use flow to convert those to opportunities to record all of your bookings in one place. If your goal is to have a single place to record bookings, you can also use the Stripe to Salesforce integration to ingest payment status. 

SPRINT #3: PAY AS YOU GO TESTING

By sprint 3, bring both teams together for end to end testing on a real-life scenario: ingest product events into m3ter, and check the usage that is generated as a result. Make sure it’s gone to Salesforce and that bills make it to your payment gateway. It’s likely that you’ll find and need to fix a few bugs, so make sure you leave space to quickly triage and respond to any problems.

At the end of sprint 3, you’re ready to release your pay as you go process — you’ve ingested and priced usage, metered it, and sent it to your payment gateway and your CRM. Congratulations!

SPRINT #4: GET READY FOR COMMITTED SPEND

Most companies choose to accompany a usage model with some kind of credits. These credits are then sold in annual agreements, either billed in arrears or up front. Sprint 4 connects the sales-led opportunities your IT team focused on in Sprint 1 to m3ter — takes balances your sales team sells, and provisions them as balances or commitments. If you’ve been using an implementation partner to work on CPQ, you should be testing your add-ons and renewals — ensuring that they add incremental balances in m3ter for your customers and that your subscriptions update in CPQ as expected. 

SPRINT #5: COMMITTED SPEND TESTING

Like with pay as you go, you’ll want to leave two weeks for testing your integrations and fixing any bugs. But once you’ve done that you’ve made two very robust initial releases to price, meter, bill, and collect payment for your new usage-based product. 

There are unique requirements for every business and this is just a quick overview of one way to implement. Hopefully it at least demonstrates a pattern to simplify what can be an overwhelming process: configure your fundamentals in m3ter, your CRM, and payment platform, then integrate, then test. There are so many other things to worry about when you launch a product: consumer experience, product-market fit, security, performance, scale. Taking a streamlined approach using technologies that handle the metering, pricing, and billing for you will not only help you get to market faster without sacrificing the customer’s experience, but will also help you get to market with more focus on the things that make you different: your product, your vision.