Usage-based pricing has become the dominant model for AI and infrastructure SaaS. Done right, it accelerates land-and-expand and aligns revenue with value.
Usage-based pricing charges customers proportionally to how much of the product they use — API calls, transactions processed, GB stored, tokens consumed, seats active. It has become the dominant model in AI, developer tools, and infrastructure SaaS, and it works well when the meter aligns to value the customer receives. It works badly when the meter is decoupled from value, when customer bills swing unpredictably, or when the meter is easy to game. The design of the meter matters more than any headline about 'usage-based being the future.'
Best fit: (a) usage scales with the customer's business value (more transactions = more revenue for them), (b) the product is easy to start small with (removes buying friction), (c) customer usage naturally grows over time (built-in NRR), (d) buyers are technical and comfortable estimating consumption. Common winners: developer tools (Twilio, Stripe), AI APIs (OpenAI, Anthropic), data infrastructure (Snowflake, Databricks), observability (Datadog). Common losers when usage is applied to businesses where it doesn't fit: HR software, project management, CRM — where seats or workflow value make more sense.
A good meter has four properties: (1) proportional to value the customer receives (not to your cost of serving), (2) predictable enough that customers can budget, (3) hard to game without also reducing value, (4) simple enough to explain in one sentence. Common meters: API calls, seats, MAU, transactions, GB, compute hours, tokens. Composite meters (some seats, some usage) usually fail on the 'explain in one sentence' test. Meters proportional to your infrastructure cost (bandwidth, compute) rather than customer value produce customer backlash — customers feel they're paying for your inefficiency.
Usage-based pricing without guardrails produces the surprise-bill problem that kills renewals. Table stakes: (a) usage dashboards updated in near-real-time, (b) budget alerts customers can set (email/Slack when they hit 50%, 75%, 100% of a monthly threshold), (c) hard caps as an option (customer chooses cap and gets throttled instead of billed), (d) rollover of unused commitments in annual plans, (e) proactive outreach when usage spikes suggest an unusual event. Companies that skip guardrails see 15-30% renewal loss on customers whose usage grew unexpectedly.
The dominant enterprise model is commit + overage: customer signs an annual commitment for a specified usage volume at a discounted rate, pays overage at a higher rate above that. This gives the vendor predictable ARR, the customer a discount for commitment, and the incentive structure to grow usage. Overage rates typically 20-50% above the commit rate — high enough to encourage upsizing the commit, low enough not to feel punitive. True consumption (no commit) models remain common for SMB and self-serve motions but rare above $100K ACV.
Usage-based creates revenue recognition complexity: bookings vs consumption, deferred vs recognized, ARR vs current run-rate revenue. Standard framing: 'committed ARR' (annual commits under contract) + 'consumption ARR' (recent-period usage annualized). Investors want to see both. NRR calculated on the base of committed customers, tracking their consumption growth or contraction. Get RevOps and finance aligned on a single set of definitions early; usage-based companies with sloppy definitions can't tell whether they're growing or shrinking on any given month.
Investor directory · Fundraising library · Articles A–Z · Company funding database