Usage-Based Pricing for SaaS: When to Use It

The pricing model you choose is not a finance decision — it is a growth decision. It determines how fast new customers can get started, how automatically revenue expands as customers succeed, and how exposed your finance team is to variability every quarter. Usage-based pricing gets each of those dynamics right in specific contexts and completely wrong in others.

This guide covers what usage-based pricing actually is, when it fits and when it does not, the NRR upside and the revenue predictability trade-off that comes with it, how to design usage metrics that customers trust, and why most mature SaaS companies now run hybrid models rather than either extreme.

What Usage-Based Pricing Actually Is

Usage-based pricing (UBP) — also called consumption pricing or pay-as-you-go — is a model where customers pay in proportion to how much they use the product. The billing unit varies by product category: API calls made, data processed, messages sent, compute seconds consumed, agents run, tokens generated. The underlying logic is the same across all of them: you pay for what you use, not for access to a license.

The contrast with seat-based pricing is instructive. Under a seat model, a company buys 50 licenses. Ten people use the product actively; forty have accounts but log in occasionally. The company pays for all 50 regardless, because the pricing unit is access, not consumption. Under a usage model, that same company pays for what 50 people actually do — and if usage grows because the product becomes more embedded in their workflow, revenue grows proportionally without any sales conversation.

The model is not new. Twilio has charged per SMS and per voice minute since 2008. Stripe takes a fixed percentage of each transaction processed. AWS bills compute by the second. What has changed is adoption: according to OpenView's annual SaaS benchmarks research, 38% of SaaS companies now incorporate some form of usage-based pricing, up from 27% in prior years, with 59% of software companies expecting consumption-based revenue to grow as a share of total revenue.

When Usage-Based Pricing Is the Right Model

UBP works well in specific structural conditions. It fails — or at least underperforms — when those conditions are absent.

Strong Fit: Infrastructure and API-First Products

The clearest signal that a product is suited for usage-based pricing is that value delivery is direct and proportional to consumption. Twilio delivers value per message sent; Stripe delivers value per transaction cleared; Snowflake delivers value per query executed against data. In each case, the customer experiences value at the moment of consumption, and the pricing unit maps cleanly to that moment.

API-first products — where the customer integrates your capability into their own product and ships it to their end users — are natural UBP candidates. The customer cannot predict their usage volume in advance because it depends on their own growth. Charging them per unit consumed rather than forcing them to buy a seat count that may be wrong in six months is a better deal for both parties.

Strong Fit: Products with Natural Expansion Loops

If your product's value grows as customers use it more — and that increased usage directly generates more revenue without requiring a sales intervention — UBP creates a compounding growth loop. Datadog's monitoring platform charges per host. As customers scale their infrastructure, they add hosts, and Datadog's revenue grows in step. The expansion motion is entirely product-led. This dynamic is why Datadog sustains net revenue retention well above 100% quarter after quarter despite having no formal upsell process for its core product tier.

Weak Fit: Access-Based or Collaboration Products

Products where the value is primarily about access, communication, or coordination across a team are poorly suited to pure usage pricing. A project management tool delivers value through the discipline it creates — teams use it more, not because they get more measurable output per action, but because it organizes their work. A CRM's value is the single source of truth it provides across the revenue team, not the number of contact records updated. In these contexts, usage-based pricing creates complexity without clarity — customers feel unpredictably billed for collaborative behavior they cannot easily quantify.

Fit Assessment: Three Questions

Before committing to a usage-based model, three questions determine whether the structure fits:

• Can customers predict and control their bill? If the answer is no — because the usage driver is opaque, tied to system behavior they do not control, or subject to sharp spikes — the model will generate support escalations and trust erosion regardless of its pricing intent.
• Does the usage metric correlate with the value customers receive? If customers can consume more without receiving proportionally more value, they will resist paying more. The metric has to make intuitive sense to the buyer, not just the billing engineer.
• Is your organization equipped to handle variable revenue? Finance, sales compensation, and ARR reporting all require adjustment for consumption models. If your finance team cannot forecast cohort-level usage trends, the operational overhead of UBP will exceed its strategic benefit.

The NRR Upside

The most compelling financial argument for usage-based pricing is what it does to net revenue retention. NRR measures the revenue retained from existing customers after accounting for expansions, contractions, and churn. A company with 120% NRR is growing revenue from its existing customer base even without adding a single new logo.

Usage-based pricing embeds the expansion mechanism directly in the product. Customers who grow their business, process more data, send more messages, or run more compute workloads generate more revenue automatically. No QBR required. No commercial negotiation triggered. The growth happens at the infrastructure layer.

The data supports this. Snowflake achieved NRR above 158% at its peak — a number that reflects customers scaling usage dramatically as their data operations matured. Datadog has sustained NRR above 120% for multiple consecutive years, driven primarily by the host-based expansion model. Research from OpenView's SaaS benchmarks program indicates that companies with hybrid pricing models — combining usage elements with subscriptions — report 38% higher NRR compared to pure subscription firms.

For operators managing revenue operations, this NRR difference is not cosmetic. A company with 115% NRR grows revenue from its existing base at 15% annually before counting any new business. A company with 95% NRR shrinks its base by 5% annually and must acquire new customers just to hold flat. The pricing model is one of the structural levers that determines which trajectory you are on.

Understanding where this expansion revenue is actually coming from — which cohorts, which products, which usage patterns — is the kind of operational visibility that Fairview is built to surface. When your revenue architecture includes variable consumption components, you need to see the signal beneath the aggregate number.

The Revenue Predictability Trade-Off

The honest counterpart to the NRR advantage is forecast volatility. Pure usage-based pricing removes the revenue floor that seat-based contracts provide. A customer who commits to 50 seats at $200 per seat generates $10,000 per month with certainty. A customer billed entirely on API calls may generate $7,000 in a slow month and $14,000 in a high-volume month — and your ability to predict which month you are in, three quarters out, depends entirely on your ability to model their usage trajectory.

This is not a theoretical concern. According to research published by Ordway, 73% of SaaS companies with usage-based models actively develop variable revenue forecasts specifically because the standard ARR model does not reflect their revenue dynamics. Finance teams at pure UBP companies must forecast based on cohort usage trends, customer growth rates, and product adoption curves rather than contracted seat counts. It is a harder forecasting problem.

How Companies Manage Predictability Risk

The standard toolkit for managing UBP revenue volatility:

• Minimum commitments: Customers commit to a baseline spend per month or quarter. Usage above the minimum is billed at standard rates. The minimum provides a revenue floor; the overage preserves the expansion upside. This is how most enterprise UBP contracts are structured.
• Prepaid credits: Customers purchase a block of credits upfront, consumed against usage over the contract term. Revenue is recognized as credits are consumed, providing advance cash flow while giving customers flexibility in timing their usage. Stripe, Twilio, and many API-first companies offer credit packages at volume discounts.
• Annual contracts with usage overages: The customer commits to an annual usage level at a discounted per-unit rate. If they exceed the commitment, overages are billed at a standard rate. This structure shifts the risk profile substantially — research suggests 80–90% revenue predictability on annualized UBP contracts versus 60–70% on purely monthly variable models.
• Hybrid seat plus usage: A platform or seat fee provides the revenue floor; usage-sensitive features layer consumption charges on top. This is the most common structure for mature SaaS companies running mixed go-to-market motions.

Designing Usage Metrics That Work

The choice of usage metric is where most UBP implementations succeed or fail. A technically valid metric that customers experience as arbitrary, unpredictable, or decoupled from value will generate billing disputes, CSM escalations, and eventual pricing pressure regardless of how sound the underlying model is.

Properties of a Strong Usage Metric

A usage metric earns trust when it has three properties simultaneously:

Correlated with value received. The metric must reflect something the customer experiences as valuable. API calls work for Twilio because each call is a delivered message — value is synchronous with consumption. Gigabytes stored works for Snowflake because more data stored enables richer analytics. If you can charge a customer for more units without them receiving proportionally more benefit, the metric is misaligned and customers will eventually notice.

Observable and controllable. Customers need to see their usage in real time and have levers to manage it. Stripe's dashboard shows transaction volume as it accumulates. Twilio provides usage dashboards that update in near real time. Datadog surfaces per-host billing breakdowns inside the product. When customers cannot see what they are consuming until the invoice arrives, bill shock is not a billing problem — it is a product failure that will manifest as churn.

Predictable as the customer scales. The best usage metrics grow linearly with the customer's own growth. Hosts added, transactions processed, active users — these are inputs the customer controls and can predict. Internal metrics like "compute units processed" that vary based on your infrastructure's behavior rather than the customer's deliberate actions create unpredictability that erodes trust over time.

Pricing Structures for Usage Metrics

Once the metric is chosen, three billing structures are available:

• Per-unit flat rate: Each unit costs the same regardless of volume. Simple and transparent. Stripe's 2.9% + $0.30 per transaction is a per-unit model — the rate does not change based on how many transactions a merchant processes per month.
• Volume tiers: Price per unit decreases as consumption crosses thresholds. The first 10,000 API calls cost $0.01 each; calls 10,001 through 100,000 cost $0.008 each. The entire bucket gets the tier's rate once the threshold is crossed. Rewards high-volume customers but creates step-change pricing that can feel arbitrary at tier boundaries.
• Graduated tiers: Each tier's rate applies only to the units within that tier. The first 10,000 calls cost $0.01 each; the next 90,000 cost $0.008 each. No cliff effects. This is generally more customer-friendly and produces smoother revenue growth curves.

Hybrid UBP Plus Seat Models: Why Most Companies End Up Here

Pure usage-based pricing is elegant in principle. In practice, most SaaS companies that have operated consumption models for more than two years layer in subscription or seat components. The reasons are operational and commercial, not ideological.

A platform or seat fee solves two problems simultaneously. First, it provides a revenue floor that makes the business easier to plan and less exposed to consumption volatility in any given quarter. Second, it creates a commercial relationship that extends beyond pure transactional billing — the customer is committed to the platform, not just paying per use. This matters when the product has strategic value that exceeds any single month's consumption figure.

The hybrid architecture typically looks like this: a platform fee (often based on seats, tiers, or organization size) covers core product access. Usage-sensitive components — API calls, data volumes, compute resources, agent actions — are billed as consumption on top of the platform fee. Customers get price certainty on the access layer and pay proportionally on the consumption layer. The business gets revenue predictability from the platform component and NRR expansion from the consumption component.

High Alpha and OpenView's 2025 SaaS Benchmarks research found that companies running hybrid models report the highest median ARR growth rate at 21%, outpacing both pure subscription (19%) and pure usage-based (18%) businesses. The hybrid structure appears to capture the expansion benefits of UBP while mitigating its forecast volatility — which is why 43% of SaaS companies now run some form of combined model.

Tracking this hybrid revenue accurately — distinguishing platform MRR from consumption MRR, modeling cohort-level usage trends, and connecting expansion revenue to specific product behaviors — is a materially harder operating problem than running a pure seat model. Fairview's revenue intelligence layer is built specifically for this complexity: connecting the contracted base, the usage layer, and the expansion trajectory into a single coherent operating view.

What the Leading Companies Do

The clearest illustrations of UBP at scale each carry specific lessons:

Snowflake charges for compute by the second and storage by the terabyte. There is no seat metric. Revenue expands as customers load more data and run more complex queries — which they do as their analytics operations mature. The model produced NRR above 158% and a direct line between customer business growth and Snowflake revenue growth. The trade-off: enterprise deals often include credit commitments to provide Snowflake's finance team a revenue floor.

Datadog uses a proxy metric — hosts monitored — rather than a raw compute unit. Hosts are a number customers understand, control, and can predict. As infrastructure scales, host count scales, and revenue scales. Additional product lines (log management, APM, synthetic monitoring) layer additional usage dimensions on top. The result is a cross-product consumption architecture that sustains NRR above 120% without requiring large enterprise renewal conversations.

Twilio built the first generation of API-first consumption pricing at scale: $0.0079 per SMS, $0.013 per voice minute. Developers could start building with zero upfront commitment and scale without procurement involvement. The model democratized communications infrastructure and created a growth loop where Twilio's revenue grew every time a customer shipped a feature that sent more messages.

Stripe takes a percentage of gross transaction volume — a usage metric that scales directly with customer business growth. A small e-commerce brand processing $50,000 per month generates different revenue than the same brand processing $5,000,000 per month, with no contract renegotiation required. The alignment between customer success and vendor revenue is nearly perfect.

What these companies share is not just a pricing model — it is a usage metric that makes the alignment between customer value and vendor revenue visible and intuitive to both parties.

Making the Transition

For companies considering a move toward usage-based or hybrid pricing, sequencing matters. Applying a new pricing model to existing customers simultaneously with new customers creates commercial risk and internal confusion. The standard approach: instrument usage data first, run the new model in parallel on new customer cohorts, build the forecasting and billing infrastructure before expanding, and migrate existing customers through an opt-in process with clear commercial incentives.

The internal operations piece is often underestimated. Sales compensation needs adjustment when expansion revenue no longer requires a renewal conversation. ARR reporting methodology shifts when a portion of revenue is variable. Finance forecasting moves from a deterministic model to a probabilistic one. The pricing change is the easy part; the operating model change is where most transitions stall.

For operators managing this transition, knowing exactly what your usage-based revenue is doing — by cohort, by product line, by customer segment — is the operational foundation. Relying on billing reports and spreadsheets to understand consumption trends is the wrong tool for the level of precision that usage-based revenue requires.