Why do buyers get nervous the moment they see usage based pricing?
Because they cannot answer the one question their finance team will ask, which is what this costs next quarter. A seat price is a number they can put in a budget. A consumption price is a forecast, and you have just asked a person who has never used your product to make one. That is the whole problem.
I price my own work on a fixed fee, with most projects landing between $1,000 and $10,000, and I do that for exactly this reason. The buyer knows the number before they commit. Usage pricing can be better for both sides, but only when the communication does the work that the fixed number used to do.
This is a messaging problem far more than a pricing problem. Most companies I see with a consumption model have priced it sensibly and explained it terribly.
What does a well explained consumption model actually look like?
It answers four questions in order. What is the unit. What actions consume units and what does not. What happens when you run out. And what a realistic month looks like for someone like me. Miss any one of those and the buyer fills the gap with pessimism.
Zapier's pricing page is a useful thing to study here, because it addresses all four in plain language. It defines a task as counting whenever Zapier successfully completes a unit of work for you, and states that failed actions are not counted. That second half matters enormously to a buyer, because a nervous buyer immediately imagines paying for their own errors.
It also says what does not consume units. Triggers, polling for new data, and Zapier built in data tools do not count as tasks. Publishing the exclusions is more reassuring than publishing the inclusions, and almost nobody does it.
What is the single most important thing to define?
The unit, and specifically whether one visible action equals one unit. Buyers assume it does. If it does not, and they find out from an invoice rather than from your pricing page, you have permanently damaged the relationship over something you could have written in a sentence.
Zapier is explicit about this. Its pricing page says many actions cost more than one task, and that the amount depends on step type, AI model tier, and number of tool calls. That is an uncomfortable thing to publish. It is also the honest thing, and publishing it is what lets a buyer trust the rest of the page.
If your unit is fuzzy, fix the unit before you fix the copy. No amount of good writing rescues a metric that customers cannot count for themselves. The test I use is simple: could a customer, looking only at their own dashboard, predict this month's bill within ten percent? If not, the unit is wrong.
How should you handle the overage question?
Say what happens, in one sentence, above the fold of the pricing conversation. There are only two honest answers. Either you stop, or you keep going and charge more. Both are fine. Refusing to say is not.
Zapier states both paths. If pay per task billing is enabled you automatically switch to it when you exceed your plan's task limit, and if it is not, usage stops once you reach your task limit until the next cycle. It also publishes the overage rate, which its pricing page gives as 2.5 times the base rate on monthly plans and 1.25 times on annual plans.
Notice what that pair of numbers does. It prices predictability. The annual customer, who has committed, pays less for going over than the monthly customer, who has not. That is a defensible piece of logic a salesperson can explain out loud, and it is far stronger than an unstated policy.
Should you show a calculator, or is that a trap?
Show one when the buyer can already estimate their own inputs. Do not show one when the calculator asks for a number the buyer will only know after they have used the product for a month. A calculator that demands unknowable inputs converts curiosity into anxiety, which is the opposite of the intent.
The better pattern for most B2B software is a small set of named profiles. A team of five sending this much, a team of fifty doing that. Buyers self identify faster than they calculate, and a profile lets you show a real total rather than asking them to produce one.
If you do build one, build it so it can be maintained by the person who owns pricing rather than a developer, because the numbers will change. I have written a walkthrough of building a pricing calculator on Webflow CMS for exactly that reason. The technical part is easy. Keeping it truthful for two years is the hard part.
What do hybrid models get right that pure usage models do not?
They give the buyer a floor. A seat price plus usage means there is a number finance can commit to, and a variable component on top that scales with value delivered. The floor is doing psychological work out of proportion to its size.
Anthropic's published pricing for Claude shows this structure clearly. Its page lists a Team standard seat at $20 per seat per month billed annually, or $25 monthly, with a premium seat at $100 per seat per month billed annually, or $125 monthly. For Enterprise the page states $20 per seat with usage cost that scales with model and task.
The consumer plans make the same point differently. The Max plan is listed from $100 per month and described as letting you choose 5x or 20x more usage than Pro, and the page notes that usage limits apply, with paid plans able to turn on usage credits to keep working at standard API rates. The buyer always knows the shape of the ceiling and what lies past it, which is the entire trick.
Which words make buyers anxious, and what should you say instead?
Three offenders. Unlimited, which nobody believes and which forces you into fine print. Starting at, when there is no realistic ceiling attached to it. And contact sales, placed where the buyer expected a number, which reads as a refusal rather than an invitation.
Replace unlimited with the actual limit, because a stated generous limit is more persuasive than an unstated infinite one. Replace a bare starting at with a range, or with a typical figure for a named profile. And if you must route to sales, say why and say what the buyer will get, so the click feels like progress rather than a toll gate.
The same discipline applies to the number of tiers you present. I have argued before about how many pricing tiers B2B software should actually have, and a consumption model does not exempt you from that discipline. If anything it raises the stakes, because each tier now carries a second variable.
How do you explain this to a buyer who has to get finance approval?
Give them a document they can forward without editing. That means an annual figure, a stated worst case, and the mechanism that prevents a surprise. Your champion is not selling your product internally, they are defending a number, and you should arm them for that specific fight.
The worst case is the part most companies omit, and it is the part finance cares about most. If there is a hard cap, say the cap. If there is an overage rate, state it and multiply it out at a plausible high volume so nobody has to. A buyer who can see the ceiling stops imagining one.
This also matters when you change pricing later, which you will. Existing customers on a consumption model experience a rate change as a bill change, immediately and without a renewal conversation to soften it. I have written about handling a pricing and packaging change with existing customers, and the commitments you make today are the ones that constrain you then.
What should you do next?
Open your pricing page and answer the four questions out loud: what the unit is, what does not consume it, what happens at the limit, and what a typical month costs someone like your best customer. If any answer takes more than one sentence or lives on a different page, that is your edit for this week.
One caveat on everything above. I am quoting Zapier's and Anthropic's published pricing pages as they read today, as examples of clear structure rather than as a price list. Both companies change pricing, so check their pages before you cite a number, and check yours before a buyer does.
If you are moving to a consumption model and want someone to read your pricing page the way a nervous buyer would, reach out. That is a short conversation and usually a useful one.
Get found, cited and the back office automated
Let's make your site the source AI engines quote and wire up the systems behind it.
Read more blogs
Let's get your website found and cited by AI
Tell me what you're working on, whether AI search is skipping your product, your back office is buried in manual work, or you need a build that does both.