Seat-based pricing is easy to read: count your team, multiply. Usage-based pricing asks the buyer to predict something they've never measured, in a unit you invented. That's why metered and AI products so often have the most confusing pricing pages, and why buyers default to 'Contact sales' or a cautious free tier. This guide shows how to make metered pricing understandable with translated units, worked examples and calculators.
How should a usage-based or AI product explain its pricing?
A usage-based or AI product should explain its pricing in three layers: what the unit is, what a unit buys in real terms, and what a typical customer pays per month. Most pages stop after the first layer and leave buyers to do the rest of the maths.
The SaaS pricing page guide covers the general page structure. For metered products, the extra job is making cost predictable. A buyer who can't estimate their bill either won't sign up or will sign up and churn after the first surprise invoice.
Layer | Question it answers | Example |
|---|---|---|
The unit | What am I charged for? | Credits, tokens, API calls, minutes, records |
The translation | What does a unit get me? | '1 credit is about one generated image' |
The typical bill | What will a company like mine pay? | 'A team of 10 using it daily usually needs the Growth plan' |
The guardrails | What if usage spikes? | Alerts, caps, auto top-up rules, overage rates |
What makes a usage-based pricing page hard to understand?
A usage-based pricing page is hard to understand when the unit has no real-world meaning to the buyer, when the price per unit is shown without context, or when overage rules are hidden. Each forces the buyer to guess, and guessing about money feels risky.
- Invented units with no translation. 'Credits' mean nothing until you say what one credit does.
- Tokens without examples. Most buyers can't picture 1,000 tokens. Show what a typical request or document costs instead.
- Rates without totals. A per-unit price is a rate card, not a price. Show what a month looks like.
- Different units for different features. If generation costs credits and storage costs gigabytes, explain both, then add them up.
- Overage hidden in the terms. What happens past the limit is part of the price.
How do you explain credit-based pricing with worked examples?
Explain credit-based pricing with two or three worked examples, each showing a type of customer, what they do in a month, how many credits that uses and what plan it lands on. Examples let buyers find themselves instead of building a spreadsheet.
For example: three worked bills for a hypothetical AI writing tool
For example, suppose a writing tool charges 1 credit per short draft and 5 credits per long-form article, with plans of 500 credits for $29, 2,000 credits for $99 and custom volumes above that. The page could show:
Solo marketer: 60 short drafts and 20 articles a month, which is 160 credits. Fits the 500-credit plan with room to spare.
Content team of five: 300 short drafts and 150 articles a month, which is 1,050 credits. Needs the 2,000-credit plan.
Agency: 1,000 short drafts and 600 articles a month, which is 4,000 credits. Above the self-serve plans, so it routes to sales.
Every number here is invented for illustration. Use your own units, prices and real usage patterns.
Base the examples on real usage data from your own customers, rounded and anonymized. If you don't have enough customers yet, label them as estimates and update them once you do.
Should a pay-as-you-go pricing page include a calculator?
A pay-as-you-go pricing page should include a calculator when buyers can't estimate cost from the plan cards alone, which is true for most metered products. The calculator should ask for things the buyer already knows, not for your internal units.
Pick two or three inputs
Choose inputs the buyer can answer without research: team size, documents per month, calls per day. Avoid asking for tokens or credits directly.
Convert behind the scenes
Translate those inputs into your units using your real averages, and show the conversion in a short line so the maths is visible.
Output a plan and a monthly total
'Estimated $140 per month on Growth' is the answer buyers want. Show the range if usage varies a lot.
Show what changes the estimate
One line on what would push the bill up or down, such as longer documents or more users.
Link the result to an action
Start a trial on the suggested plan, or talk to sales if the estimate is above self-serve limits.
How should you show seats plus usage on one page?
Show seats plus usage by explaining each part separately, then adding them into one example bill. Hybrid models are common for AI and devtools products, where a platform or seat fee is paired with metered consumption.
- Put the fixed part on the plan card: the seat or platform price and what it includes.
- Put the variable part directly underneath: included usage, then the rate beyond it.
- Add one example: 'A team of 8 with typical usage pays about [total] per month.'
- Keep the billing toggle honest. Seats may be billed annually while usage is billed monthly; say so. See our guide to the monthly vs annual toggle.
- Repeat the included usage per plan in the comparison table so analysts can compare it.
Developer-focused products face extra scrutiny here, since technical buyers will check the maths. The devtools pricing page guide covers free tiers and rate limits for that audience.
How do you explain limits, overage and spending caps?
Explain limits, overage and spending caps right next to the price, in plain sentences: what happens when the included usage runs out, how much extra usage costs, and how the buyer can stop it. Fear of an unbounded bill is one of the main reasons buyers hesitate on metered products.
- At the limit: do you stop service, slow it down, charge overage or prompt an upgrade?
- Alerts: at what point do you warn the account owner, and how?
- Caps: can the buyer set a hard monthly maximum?
- Rollover: do unused credits carry over, and do they expire?
- Top-ups: can buyers add credits without changing plans?
These answers also make strong FAQ entries; our pricing page FAQ guide has templates. For AI-specific pages, the AI pricing page guide shows how to present model tiers alongside credits.
