by
Sandeep Jain
June 26, 2022
This is a question we get asked often. The information regarding the right RevOps architecture for SaaS with usage-billing is sparse leaving engineering and RevOps teams to figure this out on their own. Here's a way to think about this problem.
You will need a CPQ (Configure-Price-Quote) tool that your sales teams can use to quote the usage product that you will be selling.
If you have a CPQ already, then it will need to support usage quoting. Most exiting tools support only basic usage quoting and not enterprise-grade usage quoting. e.g.,
Typically, minimum commit applies to just one usage product but when you are selling multiple usage products, it is much simpler from customer point of view to have a single commit that applies across multiple products.
You might be thinking what is so complex about this requirement as one possible way is to have above information written as plain-text (e.g., in the Terms and Conditions section) of the quoting tool. The challenge with this approach is that you won't be able to operationalize this data i.e., you won't be able to add any approval rules, this information if synced to your CRM will need to be manually interpreted by your billing/support/customer success teams etc., As a general rule of thumb, any billing or pricing information should never be encoded as plain-text in the Quote. Instead, the quoting tool should provide a first-class abstraction for any pricing model.
Enterprise deals usually include a ramp i.e., instead of everything being constant over the contract period, some aspect (quantity, discount, etc.,) changes/increases over the period of the contract. In this particular case, the minimum commit changes over the period of the contract either on a monthly, quarterly or even on an uneven term basis. The premise behind ramp in this case is that the usage will grow as the business is growing so it is best to bake in this growth over the period of the contract in exchange for better discounting. This helps both your end customer (they get a better deal) and you (you get a confirmed and growing ACV)
Businesses are never static; even with the pre-programmed ramp, it is likely that your customers come back and ask to revise the ramps anytime during the contract period. Both the quoting tool and the downstream billing system would need to support it. Also, is this process completely manual or is it automatic? Note that your existing customers will expect any changes to happen real-time; due to proration and invoicing changes involved in this workflow, with the existing tools it usually takes a few days!
This is a non-trivial exercise taking both time and money and most important, this is not just a one-time exercise; every time a new GTM iteration is undertaken that involves any packaging change, this integration will need to be revisited.
One of the business use cases of usage billing is to offer it on the self-serve / web channel. Usage offerings on self-serve are typically simpler but a self-serve quoting is still required. Existing CPQ tools don't offer good APIs, which implies that you won't be able to use the product catalog of the CPQ tool; instead you will have to build a completely different experience with its own product catalog. You will also want to enhance this offering in the future e.g., by providing add-ons which means more of your engineering resources go in building this self-serve quoting tool. Public companies like Atlassian that offer a mature self-serve checkout process had to build this internally.
All usage solutions have a bare-bones billing system which means that your finance team will have you invest in a separate billing tool (like Stripe). Note that a fully-functional billing solution should provide things like credit/debit notes, flexibility to process invoice runs, anomaly detection in invoices, ability to understand charges on the invoice, multi-currency support, invoices that abide by the rules of the recipient country etc.,
If you already have a billing tool, even though it may natively support a simplistic usage billing model, chances are that your usage offering will grow complex over a period of time in which case you are forced to do #6 below.
You will also need to build a separate integration with the Billing tool and all the pain points described in #2 apply.
Later, as your company matures, you will outgrow Stripe as the billing tool and will very likely need to invest in a separate enterprise-grade billing tool e.g., NetSuite which adds yet another tool for which an integration needs to be built. The worse part of this natural evolution is that existing enterprise-grade billing tools do not support flexible usage-billing invoicing which means that the finance teams will have to resort to a lot of manual work.
In summary, you will need to buy 3 additional products and/or build 3 duct-tape integrations and your GTM will become the least common denominator of 3 disparate product catalogs which implies that any GTM changes will end up taking several months; yes, months. It will become the single biggest challenge of your GTM which is when this becomes a CEO/Board level problem.
Keep in mind that how you set up your GTM stack ends being a very strong competitive advantage or disadvantage so any decisions with respect to your GTM systems need to be taken carefully i.e., by keeping your future needs in mind.
With MonetizeNow, you get all the three (CPQ, Usage, Billing) in one system and more important the system is enterprise-grade which means you will never outgrow the platform. The reason we started MonetizeNow was to abstract away all the complexity mentioned above and allow product/marketing teams to launch new pricing/packaging without any friction.
There are several ways in which you can use MonetizePlatform depending upon your current state.
In this case, you can use our platform for all the three functions - CPQ, Billing and Usage. No painful integrations. Everything works seamlessly across all sales channels (self-serve and sales-led).
If your company is a little further along, usually the billing tool will already exist but no CPQ. There are two options available in this case:
2a If the current billing tool must be used to generate the final invoice, you can use the APIs from MonetizeNow Platform to get the charge for a given time period which can become an invoice line item in the existing invoicing system. Depending upon number of customers, a manual approach can also be taken. In either case, in the longer term, it would beneficial to replace your billing tool with MonetizeNow as your existing billing tool would unlikely support complex enterprise billing scenarios.
2b Use MonetizeNow as the billing solution.
If your company is more further along, it is likely that both CPQ and Invoicing solutions exist. Following options are available in this case.
3a Some of our earlier customers are choosing to replace their CPQ as part of implementing Usage solution. This implies MonetizeNow Platform is used as both the CPQ and Usage solution. Sales teams benefit from using a blazing fast experience for quoting both the new and amendment deals. From an architecture perspective, this provides the best solution as now the data is clean from the get-go (our system syncs all the information cleanly to your CRM) which can then be used any downstream system.
Also, these customers plan to use their existing billing and MonetizeNow Billing in parallel (think of it is an active-standby configuration) and cutover from their existing Billing to MonetizeNow in the future. The goal is to completely automate the Quote-to-cash process.
3b To limit the change management, some customers choose to use MonetizeNow as just the usage solution and build integration with their existing CPQ and Billing tools. However, as a long term approach, this will create friction in the sales process as you will now be on the hook for connecting 3 different product catalogs (CPQ, Usage, Billing).
Our early customers realize this challenge and choose us over other usage solutions with the desire to replace first the CPQ and then later the Billing tools over a period of time. The underlying desire is to completely automate the Quote-to-Cash process and remove any friction in this workflow.
Subscribe for Blog & Product Updates
