by
Sandeep Jain
February 28, 2022
One question we often get is how are we different from all the other vendors in this space which is filled with several standalone CPQ (Configure Price Quote), standalone Billing and now, even standalone Usage-Billing vendors. The answer is we are all of the above i.e., we are an integrated platform that does CPQ, Billing and Usage natively.
The most natural question then is - Why? Is this just a self-chosen architecture or is there a deeper meaning behind it.
It is our contention that to address the Go-To-Market Requirements of a Modern B2B SaaS Enterprise, the only architecture that works is that of a unified platform. Let’s examine this further by understanding the evolution of the Enterprise selling model.
One-And-Done-Sales: Traditional Enterprises were characterized by one-and-done sales executed by a sales team — a classic low-volume and high-dollar transaction workflow. The sales team needed to send Quotes to end customers while the finance team needed a way to send Invoices. Two different needs, two different buyers and consequently, two different products --CPQ came about to serve the needs of the sales teams and the Billing product came about to serve the needs of the finance teams.
One-way flow of information: Furthermore, since the deals were one-and-done, there was no need for these systems to be tightly integrated with each other — it was a one-way flow of information from the CRM to the CPQ to the Billing and eventually to the Accounting system.
Different Product catalogs: Another artifact of those times was that since products were primarily hardware or hosted solutions, the new product launch frequency was at best yearly or at worst several years i.e., the product catalog changed infrequently. As such, even if the CPQ and Billing systems had completely different catalogs, it wasn’t much of a pain.
Overall it was a low-volume / high-dollar business, and it was practically and economically feasible to hire people to solve any issues. In fact, it was actually a perfect world. It couldn’t get any better than that.
And Then SaaS happened and every single aspect of traditional enterprise sales motion was thrown out of the window.
Self-Serve: First, a new sales channel emerged i.e., self-serve. This is the predominant channel for the product-led-growth enterprises and even sales-led enterprises have strong self-serve requirements (e.g., upgrades). To serve this channel, both CPQ and Billing solutions are needed. Since traditional CPQ tools were tethered to the CRM, to support any kind of configuration selection to enable "buy now" experience meant first replicating the product catalog and building home-grown duct-tape. Traditional billing systems also don't support the concept of "free" users. Following is what a Billing vendor recommends in their public documentation - "<Vendor> recommends administering endless free trials (non-paying customers) outside of <vendor>". What that means is you need to either build your own billing solution or buy another billing solution that handles self-serve. This means yet another disparate product catalog. If you are a business professional / product manager reading this, you now know what causes "launch will take months" syndrome - disparate product catalogs across different systems all need to change to support even minutest of GTM motion. If you are a finance professional reading this, you now understand why revenue recognition is such a massive pain (it is a data problem). Anyways, I digress.
Land-and-expand: Second, deals were no longer one-and-done instead they are now land-and-expand. This was probably the biggest change with SaaS. Land-and-expand deals are characterized by subscriptions (i.e., they have a payment period) with the flexibility to add more (upgrades), or drop (downgrades) or buy something new (cross-sell) for the duration of the contract. The first quote (“land” part) is the easiest one. The challenge is in supporting the “expand” part which requires proration i.e., adjusting the prices to account for the remainder of the contract term. This meant that the CPQ now needed to understand subscription terms, and invoices (what customers paid earlier) which requires a tight bi-directional integration with the Billing system which they were not designed for. This meant that all the “expand” quotes now needed to go to the finance team and the deal-desk creating a massive friction in the sales process.
Frequent Product Launch: Third, SaaS changed new product launch frequency from years to months / weeks or sometimes even days. The cloud nature of delivery meant companies can experiment with both pricing and packaging. This change created the biggest fault lines in CPQ and Billing as now every small iteration in GTM required a heavy dose of professional services to make sure that the disparate product catalogs across the CPQ and Billing systems can support the new packaging requirement. Worse, every such change makes this connection even more brittle resulting in very rigid architecture and making the next GTM iteration even more slower. The compounding nature of this problem essentially kills any agility in the GTM.
Usage-based billing: Fourth, a newer business model emerged i.e., usage-based or consumption-based billing. Since traditional Billing systems were not designed to consume usage data, a new breed of systems emerged that are designed to consume usage data and meter it. This meant yet another system with its own disparate product catalog which needed even more duct tape with an existing CPQ and Billing system.
As you may have guessed, the fix for above problems lies in controlling the spread of disparate product catalogs. More specifically,
We contend that this is the new RevOps architecture and we predict that the separation between CPQ and Billing will go away and instead a new class of products will emerge which we call as the Enterprise Monetization Platforms.
This is what we are building at MonetizeNow.
Subscribe for Blog & Product Updates
