Product-led Growth (PLG) has gotten much focus over the last few years. However, the change in the economic environment means that PLG will likely become even more critical.
While many SaaS businesses have embraced the Product-led Growth motion, the supporting technology has not kept pace.
Billing for this model, in particular, can be a considerable challenge.
Looking at history in the last 20 years, the first company to develop a subscription platform - not an invoicing or a payments platform but an actual subscription platform - was Zuora.
Zuora enabled the ability to build subscriptions, plans, customer, and payment objects and let you put them together.
It's like Salesforce, meaning you get the Lego blocks, but you've got to put it all together.
But Zuora and other incumbents were built in a different time when SaaS pricing was largely built around the standard subscription pricing model with a focus on predictable, recurring revenue.
But we no longer live in that time.
Pricing for SaaS has expanded well beyond monthly or annual subscriptions and, with the advent of PLG, incumbent players in the Billing technology space have not adapted quickly enough.
To better understand the challenges inherent in billing for PLG, let's take a look at how we define Product-led Growth (PLG):
What is Product-led Growth (PLG)?
Product-led Growth, or PLG, is a Go-to-Market strategy in which the methods of acquisition, retention, and expansion are built around the product. In this model, the end-user experience is the driver of Growth through every stage of the funnel, from awareness, consideration, and then finally to decision.
Key components of this strategy include accelerating the customer's time to value and self-sign up or freemium version of the product.
Source: RevOps Framework for Supporting Product-led Growth (PLG)
Let's look at an example scenario of a company building out a PLG motion:
To leverage PLG, the company decides on a free trial. At first, the company goes with a 30-day trial but quickly decides a 14-day trial would be more advantageous.
After a while, it's clear that 14 days is not a good fit, and they decide on moving to 60-days.
On paper, those decisions seem easy. However, changing the mechanics in your application requires code changes and engineering resources.
In addition, if you want to change how your trial mechanics work, you must change the entitlements in your billing system. Not to mention all the code that goes into building your Billing integration.
All that work means you end up being locked into your Billing vendor, which is one reason Billing has historically been such a challenge.
The last few years have seen the introduction of newer pricing models beyond free trial and freemium, compounding the challenges inherent in the incumbent Billing providers.
All of this adds to the fact that businesses need to do their due diligence when considering a Billing solution, especially if they plan to include a PLG motion in their Go-to-Market strategy.
RevOps enables businesses to easily create proposals for Usage-Based Pricing with built-in overage rates, allowing for a seamless transition to Usage-Based Billing and invoicing.
When researching billing solutions, there are several areas in which you have to pay particular attention.
Let's run through some of them and discuss their importance to Billing in a PLG motion.
A typical scenario for a PLG company is when a customer hasn't paid, and the company must take action to collect.
If the customer doesn't pay upfront or automatically, there needs to be a process in which you find a way to collect that payment.
This is known as dunning.
What is Dunning?
Dunning is the process of collecting failed, declined, or unpaid payments.
When researching a billing system, it is essential that you include support for dunning in your search criteria. Otherwise, you will have to do this yourself, which is an expensive operation on your team.
As you grow your business, a large volume of purchases through your platform. When that happens, the amount owed to your payment provider will also increase.
To help optimize your revenues, you will want to look at ways you can reduce your payment fees.
Knowing how much of that money is going out versus coming in is super important; if you need to negotiate better rates, you have to have better insights into your cashflow.
This is a great way to help you consider whether you want an external payment system, such as AdYen, or an all-in-one billing solution that includes payments like Stripe.
If you want the ability to have the insights needed to identify potential reductions, you should consider moving to more of an agnostic platform that supports multiple payment providers.
One example of this kind of provider is Chargebee.
As you increase the variety of plans you offer, the difficulty in managing the Billing for those plans increases as well.
You have to consider the ease or difficulty of managing plans at scale.
Once you start moving from "good, better, best pricing" and begin to offer more customized Pricing for contract customers, or you start to deal with different versions of Pricing as you grow your business, you need a system that supports those other models.
Things to look for include version management, looking for and distinguishing between a Price, Product, and Plan objects - it's essential to draw a line between those objects and differentiate between them.
A particularly challenging plan is based on usage, otherwise known as Consumption-Based Pricing or Usage-Based Pricing.
What is Consumption-Based Pricing (Usage-Based Pricing)?
Consumption-Based Pricing, also referred to as Usage-Based Pricing, Metered Pricing, or Pay-as-you-go Pricing, is a pricing model in which you only pay for the number of units consumed over a period of time. For a software product, that could be anything from user licenses to data or storage.
To execute on a consumption-based model, you need to be able to track a customer's level of consumption. In addition, you must be able to feed that data correctly into your Billing and payments.
You must have the infrastructure to do that kind of tracking.
This is not only relevant to the usage of a product in terms of data, hours, storage, etc., but also licenses. Often, a contract will dictate the cost of a set of user licenses and the fees per license of "overage."
You have to have a system to track these overages to correctly bill your customer without leaving money on the table.
There are two tiers of solutions to track consumption:
There are well-known solutions available in the marketplace that support the more basic use-cases for tracking and billing against usage. These include:
If you need more complex calculations and have a high degree of data to process to measure and bill against the consumption of your product, a more advanced solution might be necessary.
Some of these solutions include:v
The more advanced your use case, the more likely you'll need m3ter and its highly specialized focus on metering.
The more real-time you want your tracking to be, the more likely you'll want to separate billing from metering.
What is Churn?
A customer is considered Churned when they decide to end their paid plan for a product. As a business metric, Customer Churn, or Customer Attrition, is the percentage of lost customers compared to that of customers who renewed.
When it comes to Churn Management, the scenario in which someone "Churns" from your paid plan but maintains a free license is relatively common in the world of PLG.
It's essential to have robust reporting around this area so that you can measure Churn and decide what to do with the information.
You must support the different upgrade and downgrade motions with your customers when you want to manage these plans at scale.
Let's look at a relevant example:
A customer signs a 12-month contract spanning January 1st through December 31st, buying 10-seat licenses.
On June first, they decide they want an upgrade - adding another 5 seat licenses added to their original agreement.
This poses a challenge for more rigid systems in which the payment period is fixed.
In this agreement, built with RevOps Agreement Builder, we generated a contract with 5 seat licenses, pro-rated at a six-month price that has been co-termed to their original agreement.
With this in place, the calculations are already done for the upgrade and, if you have the right billing solution, you have avoided additional headaches further down the line.
If you have a billing system that automatically calculates this for you, it reduces billing errors and avoids headaches further down the line.
Invoice Management is a more straightforward concept and quite common across all platforms, whether PLG or contract-based customers.
Invoice management often becomes difficult when choosing a provider when it comes to the ability to produce the information necessary for your customers' Accounts Payable teams.
You have to be able to produce an accurate invoice with all the necessary information so they can pay you appropriately.
Ideally, this information is generated and sent automatically.
Most modern platforms do this for you today, but if you want to evaluate the best solution in this area, Chargebee and Stripe Billing excel when it comes to this type of capability.
There are multiple discounting models to consider, but let's start with the most common model for PLG, which is trials.
A standard PLG motion has trials based on periods or credits. With time-based trials, you can develop a plan and decide to put customers on a 30, 45, or even a 14-day trial.
A billing system needs to have the ability to set those trial periods up so they can be billed starting at the correct time.
A free credit trial is an option best suited for products billed based on consumption in which you offer new users a certain amount of free credits; this is called balance-based credits.
An example of a free credit trial would be providing a trial user with $30 for free credit up front. Then, charges will automatically incur based on your billable amounts when that balance runs down.
These are great concepts, and you will find them supported on the most common "all-in-one" platforms out there.
But if you're looking for something that works well in a bottoms-up motion, this is where Stripe Billing shines.
Consumption-based (or Usage-Based) pricing models have come into their own in the last few years.
While the tried and true model for SaaS, championed by early players like Salesforce, was a subscription model based on licenses, Usage-Based Pricing enables users to only pay for what they use.
There are some core concepts in the way usage is billed that we should cover.
They include:
These four concepts represent the building blocks of nearly all Usage-Based Pricing.
Top-Up Billing
Top-Up Billing is an essential form of "pay-as-you-go" pricing. A simple example of this model would be calling cards in which you purchase a card with a set limit of minutes. Once that limit has been reached, you have the option to add more by "topping up" minutes to your card.
Twilio was an early disruptor in how tech companies price because they leveraged this model to great success.
True-Up Billing
In a True-Up Billing model, a price is set for an agreed-upon amount of usage for a given billing cycle. An overage cost is also set in terms of that contract and is billed at the end of the billing cycle.
A more familiar example of True-Up is how electricity and gas are often billed.
At the end of your billing cycle, you will receive a true-up statement that reconciles all costs associated with your usage against the credits you have paid for.
If there's a discrepancy, you are billed the cost of those overages.
For many, this can lead to surprise and unexpectedly large bills that were unplanned. In addition, while most of us know our baseline usage for a given season, it's impossible to fully account for long stretches of cold or heat waves that will increase electricity usage.
A concern that exists within the SaaS space as well.
Metered Billing
Metered Billing has set costs based on levels of usage. It differs from a True-Up model as the overage fees are metered based on the quantity above the agreed-upon limit.
Let's look at an example of a sales agreement that includes a Metered Billing element:
In this Sales Agreement, built using the RevOps Agreement Builder, there is a flat fee for access to the platform, which includes 1,000 sessions.
However, this contract also outlines the costs for going over that initial quantity of 1,000 in tiers of usage. As you can see, the first 500 sessions above 1,000 will be charged at $0.10 per unit. Once those are exceeded, the cost per session decreases as the quantity increases.
This metered structure helps alleviate some concerns of wild spikes in usage as it lays out exactly what the costs will be.
In addition, as the sessions increase, the marginal cost will eventually decrease to become a mere $0.05 per session.
The final concept to consider is Minimum Usage Commitment which can be an alternative to a metered contract.
Due to the difficulty in accounting for spikes in usage, a standard metered pricing structure is not ideal when moving upmarket. Instead, a minimum commitment model should be considered, in which a customer prepays for a committed amount of usage and price.
As you move upmarket, higher commitments on volume should be sought, enabling the customer to pay upfront at a price that would be more desirable to them than a true-up.
All of these models create a level of difficulty for product managers and other stakeholders to decide the usage variable they want to charge against.
You now have more companies building a greater variety of credit units, which makes Billing even more complicated because now you need to develop the glue for the motion of PLG.
Not to mention, you also have to track all that information.
Speaking of tracking, Product Analytics is critical when it comes to charging based on usage.
The universe of Product Analytics tools has greatly increased over the last few years.
Businesses can now leverage tools like Customer Data Platforms; potentially using them to stream usage data into their Data Warehouse.
Or, they can look at more modern systems like m3ter, which enables you to easily calculate an invoice, making it more straightforward to integrate and export this information into invoicing systems.
Tools like m3ter move information collection from what has historically been hard into a much simpler data pipeline.
It's exciting; it's the evolution of the ecosystem in which you will see more and more businesses charging less and less by just the seat license, and more and more will be doing add-ons based on other kinds of resources.
"Infrastructure as a Service" is not going to be used everywhere; it's going to be used in places where you have a cost basis that matters, or you want to do a value-based pricing model on a per-unit basis that the user doesn't make sense for.
But if you're in a traditional ecosystem, either on-prem or moving into the cloud, these models might be complicated for your buyers to understand.
There's now a lot of buyer education and more traditional selling motions for the cloud that might be more dated but are still applicable. You have subscription platforms that are very well-formed and tackle that.
That same basic technique that Zuora did many years ago is now much simpler and easier to work with.
Chargebee, Chargify, and some other platforms like Stripe Billing enable you to plug and play.
However, if you have a developer or an operator on your team, you might choose a different platform for another purpose. That has taken away what has been historically difficult and turned it into more of a one-stop-shop solution for your subscription Billing.
Now you get dashboards you can share with your customers, where they can sign in and see their invoices, and you have to build a new product for brandable emails and notifications.
While Billing presents a particular challenge, at least when it comes to some incumbent solutions, optimizing it for PLG is not enough.
The "Quote-to-Cash" process encompasses each deal stage, starting from the configuration of an agreement through recognizing revenue.
To succeed with a PLG motion, you have to optimize for each stage of this process, which requires reconsidering your entire revenue engine.
.png)