A founder I worked with last year sent me a Slack message at 11pm. "We're switching to usage-based pricing next quarter. The board loves it. Can you make sure the CRM is ready?" Two weeks later the pricing page was live. Three months after that, their finance lead was rebuilding every invoice by hand in a spreadsheet because the billing system charged on seats, the product metered on API calls, and HubSpot still thought every account was worth its old flat subscription. Nobody could answer a simple question: what is this customer actually worth right now?
That gap is the whole story of usage-based pricing in B2B SaaS. The pricing page takes an afternoon. The plumbing underneath it takes a quarter, and almost nobody budgets for the plumbing.
I have spent ten years in RevOps and I am currently the founding GTM engineer at Peec AI, so I see this from the data side, not the slide-deck side. This post is about what actually has to change in your stack before you flip the switch, why hybrid pricing beats pure consumption for most teams, and where the forecast quietly breaks.
What usage-based pricing actually is
Usage-based pricing, sometimes called consumption pricing, charges customers for what they use instead of how many seats they buy. API calls, rows processed, messages sent, active agents, gigabytes stored, tokens consumed. The meter runs, the customer pays for the meter.
It has gone from a niche model to the default conversation. Around 67% of SaaS companies now run some form of usage-based pricing, up from 52% three years ago, according to Culta's 2026 analysis. The AI wave pushed it harder. When your cost of goods is GPU time and tokens, charging a flat seat price means a heavy user can burn your margin while a light user overpays and churns. Cursor, Anthropic, OpenAI, and most of the AI tooling layer price on consumption because their own costs are consumption.
The reason it spreads is simple. It ties what the customer pays to the value they get. Companies on usage-based models report 120%+ net revenue retention on average, against roughly 110% for subscription-only peers (Ordway). When the product is sticky and usage grows, revenue grows without a renewal negotiation. That is the dream the board is buying.
That last number matters. Median net revenue retention across B2B SaaS dropped to 101% from 108% in earlier benchmark periods. Expansion got harder for everyone. Usage-based pricing is one of the few levers that still moves NRR up, which is exactly why the pressure to adopt it is real and not just hype. The risk is doing it badly.
The part the pricing deck skips
Here is the uncomfortable truth. Usage-based pricing is not a pricing decision. It is a data engineering decision wearing a pricing costume.
Seat-based pricing is easy to run because the number of seats barely changes and your CRM already knows it. You sell 40 seats, the contract says 40 seats, the invoice says 40 seats, and the forecast multiplies 40 by a rate. Everyone agrees on the number because there is only one number.
Usage-based pricing replaces that one stable number with a stream of events that changes every hour. To bill it correctly and forecast it honestly, you need four things working together: a meter that captures every billable event, an entitlements layer that knows what each customer is allowed to use, a billing system that turns metered events into invoices, and a CRM that reflects current account value instead of a stale contract figure. Break any one of those and you get the 11pm Slack message.
Build the meter before you build the pricing page.
The model is only as good as the events feeding it. If you cannot trust the usage data to the cent, you cannot bill it, forecast it, or put it in front of a customer. Get the pipe clean first.
Most teams do this in the wrong order. They announce the model, design the packaging, ship the pricing page, and then discover the product was never instrumented to count the thing they now want to charge for. So they bolt on rough event tracking, the numbers do not reconcile against the invoice engine, and finance spends two quarters cleaning it up by hand. I have walked into that exact mess more than once.
Don't go pure usage. Go hybrid.
The single most useful opinion I can give you: do not move to pure pay-as-you-go. Use a hybrid model with a committed floor.
Pure consumption sounds elegant and it wrecks two things you care about. It makes your own revenue unpredictable, because a customer who pauses a project for a month pauses your revenue with no warning. And it makes enterprise procurement nervous, because no buyer wants to sign a contract with no ceiling and no floor. A hybrid model fixes both. You set a committed minimum the customer pays regardless of usage, then charge for consumption above it.
This is what most of the market actually does. Around 60% of companies with usage-based components run a hybrid model rather than pure consumption, per the same adoption research. The committed floor gives you a predictable base to forecast against. The usage layer gives you the expansion upside. You get most of the NRR benefit without betting your runway on customer behavior you cannot control.
Pick the meter that tracks value, not cost. This is the other place teams trip. Charging per API call feels logical because that is what costs you money, but the customer does not buy API calls, they buy an outcome. If your product helps a sales team book meetings, a meter tied to meetings booked or accounts enriched will feel fair and grow with the customer. A meter tied to raw compute will feel like a taxi meter the customer wants to switch off. Charge for the thing the customer is happy to see go up.
The rollout sequence that actually holds
When I help a team move to usage-based pricing, the work runs in this order. Skipping a step is how you end up reconciling invoices in Excel.
Step 01 is where I spend the most time and where most projects underinvest. The meter has to be accurate enough that a customer disputing a bill loses the argument. That means event capture you trust, aggregation at the billing interval, and a reconciliation job that compares metered totals against raw product logs. If those two numbers ever diverge, you have a billing dispute waiting to happen and a finance team that stops trusting the system.
Step 04 is the one that lands on my desk most. Your CRM was built around a static deal value. The moment revenue floats, the CRM number is wrong the day after signature. Reps quote renewal off a stale figure, CS does not know which accounts are about to blow past their floor, and leadership forecasts off a number that no longer means anything. The fix is a sync that writes live usage and current run-rate value back to each account, usually through reverse ETL or a direct billing-to-CRM integration. We get into the wider plumbing in our CRM and RevOps work.
The tools you will actually touch
You do not need to build metering and billing from scratch anymore, and you should not. The category got good.
For metering and usage-based billing, the serious options are Metronome, Orb, and m3ter. They capture events, rate them against your pricing, handle proration, and push invoices. Chargebee and Stripe Billing cover hybrid setups well if you want subscription and usage in one place. The right pick depends on event volume and how weird your pricing is, but the build-versus-buy math almost always says buy.
For the data layer that connects all of it, that is normal RevOps work. Clean events flow from the product to the billing engine, billing pushes value back to the CRM, and the CRM feeds the forecast. The glue is automation, whether that runs in n8n, a reverse ETL tool, or a billing platform's native CRM connector. We build this kind of pipeline as part of our AI and automation work, and the principles overlap heavily with how you keep a CRM honest in general.
One thing I will say plainly: do not run usage-based billing through spreadsheets past your first ten customers. It works at five accounts and it collapses at fifty. The hand-reconciliation phase is the tax you pay for shipping the pricing page before the pipe.
Where the forecast breaks, and how to keep it honest
This is the part finance feels first. With seats, you forecast by multiplying a stable count by a rate. With usage, that math lies, because the count is a moving curve and last month is a poor predictor of next month.
The fix is cohort-based forecasting. Split every account into two streams: the committed floor, which you forecast like a subscription, and the variable usage above it, which you model by tracking usage growth curves per customer cohort. New cohorts ramp differently from mature ones. A customer in month two behaves nothing like a customer in month twenty. Average them together and you get a number that is wrong for everyone.
Mature usage-based companies forecast within about 10 to 15% accuracy at a quarterly level, which is looser than a clean seat-based forecast and that is just the cost of the model. Plan for the variance instead of pretending it is not there. Build a base case, a downside, and an upside off different usage growth assumptions, and report the committed floor as your floor. If your team already struggles with forecasting accuracy on seats, fix that before you add usage volatility on top, because usage will expose every weakness in your current process.
This is also where usage-based pricing changes how you read net revenue retention. Expansion stops being a renewal event you can point to on a calendar and becomes a slow drift in the meter. That is great for the number and confusing for anyone trying to attribute it. Tag the expansion source so you can tell organic usage growth from a deliberate upsell, or you will not know which of your motions is actually working.
When you should not do this yet
Usage-based pricing is not free and it is not always right. Skip it, or wait, if any of these are true.
Your product has no natural usage meter. If the value is not tied to a thing that goes up and down, you are inventing a meter the customer will resent. Some software is just worth a flat fee and that is fine.
Your usage does not correlate with customer value. If heavy users are your unprofitable accounts and light users are your champions, a usage meter punishes exactly the wrong people.
You cannot instrument the product reliably in the next quarter. If engineering cannot give you trustworthy events, you are not ready, and no pricing page will fix that. This is the same discipline as any pricing strategy decision: the model has to fit the business, not the trend.
There is no shame in staying on seats or moving to a simple tiered model with usage limits instead of usage billing. That gives you some of the value alignment with far less plumbing. Half measures are underrated here.
Switching to usage-based pricing and worried about the plumbing?
Book a free 30-minute audit and we will map the metering, billing, and CRM gaps before they turn into hand-built invoices.
Book an audit →The short version
Usage-based pricing earns its reputation. It aligns price with value, it pushes NRR up, and in an AI-cost world it is often the only model that protects your margin. But the pricing page is the easy 10%. The hard 90% is a meter you can trust, an entitlements layer you own, a billing engine that reconciles, a CRM that reflects live value, and a forecast that respects cohorts. Go hybrid so you keep a floor. Build the meter first. Get those right and the model pays you back. Skip them and you get the 11pm Slack message.
FAQ
What is usage-based pricing in simple terms?
It is charging customers for what they consume rather than a flat fee or a fixed number of seats. The product meters a billable action, like API calls, messages, or rows processed, and the customer pays for that usage. Most teams pair it with a committed minimum so revenue stays predictable.
Is usage-based pricing better than seat-based pricing?
It depends on whether your value scales with usage. When it does, usage-based pricing tends to drive higher net revenue retention, around 120% versus 110% for seat-only peers, because revenue grows as customers grow without a renewal negotiation. When value does not track usage, seats are simpler and fairer. Most teams land on a hybrid of both.
What does RevOps have to change for usage-based pricing?
Four things have to connect: a meter that captures billable events accurately, an entitlements layer that defines plan limits and the committed floor, a billing system that turns events into invoices, and a CRM sync that reflects live account value. RevOps owns the data flow across all four and the forecasting logic on top.
Why is forecasting harder with usage-based pricing?
Because revenue is a moving usage curve, not a fixed seat count, so you cannot multiply one number by a rate. You forecast the committed floor like a subscription and model variable usage separately by customer cohort. Mature usage-based companies forecast within roughly 10 to 15% accuracy at a quarterly level, looser than seat-based.
Should a startup adopt usage-based pricing early?
Only if the product has a clean usage meter, that usage correlates with customer value, and engineering can instrument it reliably this quarter. If any of those is missing, stay on seats or use simple tiered limits. Do not run usage billing through spreadsheets past your first ten customers.
Get the plumbing right before the pricing page
We help B2B SaaS teams build the metering, billing, and CRM pipeline that usage-based pricing actually needs, so the model works on day one instead of after two quarters of manual cleanup. If you are planning the switch, talk to us and we will show you the gaps first.