While many direct consumers are accustomed to metered-based or usage-based services, many B2B businesses are just beginning to make a move to usage-based billing.
For examples of usage-based billing in the B2C space, think of utilities, produce shopping, Uber, Lyft, or filling up your car with gas. Usage-based billing simply means that customers only pay for what they use or want instead of menu pricing or subscription-based models where customers pay for a set quantity or tier of services.
From a user-standpoint, usage-based billing is preferable to paying for tiered pricing that may exceed what they expect to use (a great example is my partner’s insistence that we use ALL of the available data from our cell phone carrier). However, it’s very hard to implement usage-based billing unless the product was initially created with this billing model in mind.
When this topic came up in the RevOps Co-Op group, I was excited to talk to people who had figured out not only the mechanics. I've lived through the pain of trying to support a disconnected system and wanted to hear from the other end of that continuum.
Let’s hear from the experts.
Usage-based pricing won’t always be the right fit, but there are several compelling reasons to consider it.
Firstly, customers pay only for what they use so it feels customer-friendly and sets you up to price based on value (more of which later).
Secondly, it allows for easy organic revenue growth – i.e., growth in accounts without upsell. If you remember licensing, you sold a hundred customers, each for $10, and you received a thousand dollars in revenue, and the next opportunity to increase that amount was at renewal. With usage-based pricing, a significant share of your customers will grow because they are using more and extracting more value.
Thirdly, it allows for easy seeding. If you’re only charging based on usage, that makes it cheap to get started, and so you’ve removed significant adoption friction. You’ll get more users trying you out.
I think usage-based pricing really comes into its own when it’s combined with an inbound, “self-service” channel where people find the software online and start using it themselves. That requires pretty simple pricing design, but there’s no reason why you can’t also have more complex enterprise pricing linked to an enterprise sales model that runs in parallel. The self-service channel is good business in itself, but also generates leads for enterprise sales.
But whether you have self-service or not, a key requirement for your GTM is to be able to track and respond to usage signals. Customers can grow by themselves, but that growth can be encouraged and amplified by timely sales interventions. You need to be set up to do that.
The key to usage-based models is finding a metric that aligns with the customer’s value generated from your product. You ideally want a variable metric that grows with your customer.
When your customer is testing you out, they're paying you hardly anything to do that. You want to remove any barrier to prospects sampling your product. But if they then become committed and start rolling it out across their company, if you're billing on the right value metric, you're just going to get more revenue without a traditional upsell. They naturally see the value in what you’re providing and expect to pay more.
Value-based pricing and usage-based pricing in these cases are totally aligned. That's the goal of pricing design: come up with that perfect value metric. It’s all about the customer and what they value.
You also need to avoid complexity where you can. Some complexity is fine, but if it’s difficult for the customers to quickly understand the product well enough to predict their spend or see a clear link between that spend and the value they get, you run into problems. It’s not unusual for companies not to publish their pricing because they want to size the customer and then design bespoke pricing configurations – that’s not necessarily a problem, but if the customer has to go through three, four, or five calls before they have a feel for how much they’d pay, that’s a lot of friction.
As an overall point, usage-based pricing models are challenging to design well and getting it right makes a big difference. It amazes me how little time SaaS companies can spend on this exercise. I’ve seen it reported that SaaS companies spend an average of six hours determining their initial pricing strategy - most companies look up what their competitors do, then tweak it a little bit and publish it - and then rarely return to it. I think pricing design is something to take your time over, and then see as something to be regularly reviewed and updated.
Usage-based pricing can be a nightmare for billing. You need to meter all your usage data per customer, then you need to match it to the pricing plan for that customer (often subject to custom terms), then you need to do a complicated calculation, and only then are you ready to generate an invoice. Billing and invoicing platforms typically don’t allow for complex usage-based calculations, so most companies handcraft an integration between their product and their billing systems themselves, and it’s often expensive to maintain, or involves manual steps, or both. It’s not at all unusual to find a harried analyst battling with spreadsheets every month.
It’s something that needs to be done well, too. It’s not just that accurate bills are necessary to maintain customer trust. It’s that the customer needs to understand why they’re being charged what they’re being charged – pricing is part of the product, so they need that information on the bill, or via customer support, or ideally via an account management console.
In my experience, the secret to good billing operations is in the unification of the data. You need to meter usage reliably and then find a way to combine that data with pricing data neatly in one environment. Once that’s figured out and automated, billing becomes much simpler and can support custom calculations for each organization you onboard, if required.
There are other operations tasks that usage-based pricing makes harder.
Firstly, forecasting is tough, because it’s based on actual customer usage. This is a particular problem for valuing pipelines or new acquisition cohorts, because there is limited actual usage data yet – you need to rely on sales team estimates, which are often guesswork.
Secondly, processing and approving custom enterprise deals are hard. Sales teams will want to get creative to increase sales momentum, but you can’t rewrite your integrated billing system for each deal, and assessing terms is important because outcomes can vary hugely depending on the volume and nature of usage. You've got to put guardrails and limits in place to make sure the deals can be implemented and won’t bankrupt you.
You have to really understand your customers if you use a usage-based billing model. Eventually, you’ll design a model that projects the likelihood of renewal, and you can only do that over time through trending analysis.
If you're a startup, usage-based billing is tough to forecast, but honestly, that's pretty typical of startups, even if they use subscription-based billing models. Over time, companies profile their customers more accurately, and educated guesses become less risky. The difference between a company running off usage-based who's successful and one who's not successful, I think, is largely in part to how good you get at building an estimation engine.
I'll give you an example. We calculated usage off of data storage, but our company’s real value of the tool was not the storage. It was the added security benefits, but we were still charging per megabyte.
Someone in mining or oil and gas we knew would have gigabytes and gigabytes of files. They have big technical schematics that are dozens of if not hundreds of megabytes each. We learned an oil and gas stream is a minimum of two gigabytes to 40 gigabytes.
Then we learned someone in a SaaS company deals primarily with PDFs and spreadsheets, which were a couple of kilobytes each. You could have a $60 million SaaS business generating less than ten gigabytes worth of data in a transaction.
The muscle that we developed to help us get better at forecasting was having our sales reps profile a customer during the sales process, which allowed us to better estimate usage to customers and internally during our forecasting exercises. Forecasting is really just about understanding your customers and trying to build as much predictability as you can.
Maybe I was lucky because we did this usage-based compensation plan in Australia. The people are pretty relaxed in Australia, and they have a heftier base salary. You’ll see 60 or 77 percent base—never 50 or 40 percent. The reps were pretty chill about riding the waves with us, and it probably helped that we hit our targets and had a good product.
We didn't have to put buffers on our compensation plans. We didn't have to structure an up-front usage fee in exchange for a discount. We didn't pay them on their estimates because it would have been disastrous. They just got paid what the customer brought in.
If you've worked with usage-based pricing, sometimes a customer overspends, and sometimes they underspend. We were lucky we just had a culture that supported paying on receipt. As an American company, you would have to eat an upfront payment to your reps and hope your estimation engine is perfect.
I've seen an example where sales representatives were paid on estimates. Eventually, they had to ditch the usage-based model because sales reps were overestimating spend and the company ate the difference. Most companies can't afford to do that until they hit unicorn status. Most companies need a compensation plan that pays the rep upfront. Still, they need to put a box (or guidelines) around estimates, so people don't wildly overestimate what a customer will use.
Usage-based billing is a fantastic selling point with customers, but if you get their estimates wrong, usage-based billing can blow up in your face. Bill shock is all too common, and I’ve noticed a contrast in how companies based in different countries will handle bill shock. In some cultures, they’ll argue but eventually default to the contract. In others, they’ll break the contract even if they underestimated their usage, received overage alerts, and ignored the alerts.
In those situations, credit notes are a massive problem for usage-based billing businesses.
The estimation muscle is not just for your forecasting and your sales team and your compensation. It's about the customer experience. If you get your estimates wrong, your relationship with the customer will be terrible.
When you go to raise capital, expect a fight. All VC firms that typically deal with technology have a list of metrics they want to see. Expect to be compared to traditional SaaS models with ARR. That's a problem with usage-based billing because you can't recognize that revenue until it has occurred.
VCs want certainty. Banks want certainty. It's all about certainty. Trying to get north of $10M from a capital raise is very hard.
We had to turn into data scientists to build airtight estimation models. It took about eight months to build the model. If I had to do the same capital raise now, I could do it in a quarter. But that first time was painful. Most of the effort went into wrangling the top-level data.
Raising capital will make you question your billing model and make you wish you had platform fees or other products in the bag as well. If you get your estimate engine dialed in, your customers will love you, but you'll still have difficulty selling certainty during a capital raise.
