Usage-based pricing terms explained: A quick guide to get started

Usage-based pricing has quickly become one of the more sought-after pricing models for businesses today, and it's not hard to see why. It lets revenue track actual consumption rather than a flat guess made once a year. If your organization is setting one up, or is somewhere in the middle of the process, there's a fair bit of terminology that comes along with it, and knowing it properly makes the rollout smoother.

Public companies running a largely usage-based model post a net dollar retention of around 122%, compared to 109% for companies with no usage-based component at all, according to OpenView Partners' SaaS benchmarking data. That gap along with the unmissable AI revolution is why so many industries are experimenting with metered pricing.

Here's a quick look at the terms that come up most often, and what they actually look like in practice.

Usage-based pricing (UBP) vs. Usage-based billing (UBB)

While they are used interchangeably, there is a minute contextual difference.

Usage-based pricing is the strategy: Figuring out a way to balance the value delivered to the customers and the costs to deliver and finalizing a model that fits your demography and revenue goals. This is where the product and go-to-market (GTM) teams are highly involved.

Usage-based billing is what carries out that strategy: The metering, invoicing, and reconciliation happening behind the scenes that makes sure whatever strategy was planned before is executable on a day-to-day basis. This operational aspect is mostly the responsibility of the finance and IT teams.

Unit economics 

Unit economics asks one question, applied to a unit of whatever the business sells: Does that one unit make you enough money once you subtract what it actually costs to deliver? It looks at one sale in isolation, rather than the total revenue number, to check whether the business is actually profitable at the smallest scale it operates at and determines the strength of its sustainability.

Ride-hailing platforms check this on every single trip, weighing the fare collected against the cost of that specific ride. For example, if a food delivery startup is charging a flat $3 fee per order, when fulfillment actually costs $4, it loses money on every order it processes. So, scaling up, while looking good on the growth side, it just multiplies the loss. Now, when applying this to high-usage centric businesses with complex costs and offerings, such as AI solutions, getting the unit right decides sustainability.

Value metric

While unit economics is the science behind arriving at the value, value metric is what you arrive at after figuring that out for your business. It is simply the unit your business chooses to charge on, whether that's per user, per GB, or per API call. Getting this right matters more than almost anything else in pricing, because if the unit being charged on doesn't line up with what the customer actually gets value from, the price stops feeling fair no matter how reasonable the actual rate is.

MongoDB Atlas bills primarily on compute consumed (hourly costs) rather than per user, because that's what actually reflects what a customer gets out of a database. Slack, on the other hand, has stuck to active users as its core metric, since collaboration value scales with headcount rather than message volume.

Pay-as-you-go (PAYG)

PAYG is usage-based pricing with no upfront commitment attached to it at all. There's no minimum spend and no contract locking a customer in, they simply pay for whatever they used in that period and nothing more.

Twilio built much of its early growth this way, letting developers send a single SMS and get billed for exactly that, nothing more. Picture a small agency wanting to test an email tool for one campaign alone. A vendor demanding a monthly subscription would likely lose that account before it even started, whereas paying only for the 2,000 emails actually sent removes the pressure entirely. It's often these small, low-stakes customers who turn into the biggest accounts a year down the line.

Metering

Metering is just the counting part, tracking how much of something a customer has actually used, whether that's GB stored, API calls made, or seats occupied.

Raw usage event

A raw usage event is just one single thing that happened: one API call made, one SMS sent, one file uploaded. It's the smallest piece of activity a system records, before it ever gets added up or turned into anything billable.

Say a customer's system fires off 50,000 API calls in an hour. Each one lands as its own individual event first. It's only later, once all those individual events get added together and matched against the pricing model, that a business actually knows what to bill for that hour.

Real-time data aggregation

Real-time data aggregation is what takes all those individual raw events and keeps adding them up continuously as they happen, instead of waiting until the end of the billing cycle to total everything up at once.

A customer running close to their monthly API limit benefits directly from this. Aggregating usage as it happens means both sides can actually see consumption climbing in real time, rather than finding out only once the invoice lands with a number nobody saw coming.

Entitlements

An entitlement is simply what's already included in a customer's plan before any usage-based charges even come into play, say 10,000 API calls a month, or 1,000 wallet credits to spend across different things.

Feature gating

If entitlements are referred to as the "commercial" gate, feature gating is coding those limitations with the product natively. It locks a specific feature behind a paid plan, rather than limiting how much of the product a customer can use. A customer could have unlimited usage of the core product and still not be able to touch one particular feature until they upgrade.

For example in Loom, free and lower-tier users can record and share videos without any usage ceiling, but features like custom branding stay gated behind paid plans. The gating isn't about how much of the product gets used, it's about which parts of it a customer is even allowed to explore.

Credit rollover and expiry

When a business sells usage as prepaid credits, one question comes up almost immediately: Do unused credits carry into the next period, or do they expire?

Say a customer buys 100,000 credits for the year but only uses 40,000 by December. This is where you decide what happens to the rest of 60,000 credits. They can expire immediately, or they can be rolled over to the next billing cycle. You can also decide how they get used.

Drawdown 

Drawdown is what happens when usage gets deducted straight from a prepaid balance, instead of being billed separately every cycle. Every time the customer uses the product, that usage gets drawn down from whatever balance they've already paid for, whether that's credits, a wallet, or a committed dollar amount.

Say an enterprise prepays $50,000 for the year. Every month's usage draws down from that balance automatically, and once it's fully drawn down, the customer either tops up, moves to metered overage billing, or waits until the next contract term kicks in.

For today's AI businesses, this has become almost a necessity. For $100 credits, one can associate multiple offerings with different value, such as SMS at $0.005, a minute at $0.05, and many more. Throughout the billing cycle, the charges are drawn down accordingly from the single wallet, without having to set up multiple plans for each offering.

Overage charges 

Overage is what a customer pays once they've used more than what's included in their plan. Zapier bills this way. Once a customer runs past their monthly task limit, the additional tasks get charged on top of the base subscription.

A logistics company on a plan covering 5,000 shipment-tracking calls a month might suddenly hit 12,000 during a holiday surge. With overage pricing already built in, that extra usage bills automatically at the end of the cycle, rather than forcing an awkward mid-crisis conversation about upgrading right when the business can least afford the distraction.

In order for a usage-based pricing model to succeed, both strategy and operations need utmost attention. Because unlike strategizing for the other models, which require minimal one-time effort with occasional revisits, a usage-based pricing model requires constant adjustments to capture the market. And operations should keep up with it: accurate metering, fair entitlements, credits that behave the way customers expect them to. Once the foundation is laid, the bigger question arrives—whether the billing system underneath can actually execute all of it without falling apart the moment usage starts scaling.

If your business is exploring consumption-based pricing, Zoho Billing is built to handle metering, entitlements, and credits without the operational headache. Reach out to our experts to see what a rollout could look like for your business.