For roughly fifteen years, the default pricing model for B2B software was simple: count the seats, multiply by a number, send the invoice. It worked because the unit of value was a human opening an app. When the human logged in, value was delivered. When they did not, nothing much happened either way.
AI has broken that equation. The humans are still there, but they are no longer the ones doing most of the work. A single customer might trigger millions of inference calls in a week, run overnight agents while their team sleeps, or delegate an entire workflow to something that does not need a login at all. You cannot bill that fairly by the seat, and the market knows it.
The unit of value has moved
Ask any founder shipping an AI product today what they actually sell, and you will hear a different list than you would have two years ago. Tokens processed. Documents parsed. Agent runs completed. Resolved tickets. Minutes of transcription. Successful classifications. These are not proxies for value — they are the value.
That shift has consequences for pricing:
- Consumption is lumpy and unpredictable, so flat tiers either leak margin or scare off customers.
- The cost of goods sold is real and variable. A seat costs the vendor nothing extra. A million tokens do.
- Customers want to see what they are paying for, at the granularity they are consuming it.
- Contracts increasingly bundle commitments, overage, credits, and prepaid pools in the same agreement.
Most billing infrastructure was never designed for any of this. It was designed to issue the same invoice every month with a slightly different line item.
Access-based, usage-based, outcome-based
It helps to think of pricing as a spectrum rather than a binary. On one end sits access: pay to be allowed in. In the middle sits pure usage: pay per token, per call, per run. On the far end sits outcome: pay when the job is done, the ticket resolved, the revenue attributed.
Almost no AI SaaS company lives at a single point on that spectrum. The same customer often wants a predictable baseline fee, a pool of included usage, metered overage on top, and a separate outcome-linked bonus for the most valuable actions. In the Plock data, this hybrid shape is by a wide margin the most common structure our customers land on — a subscription floor with usage stacked above it.
Designing those models is not the hard part. Running them accurately, month after month, without an operations team patching spreadsheets, is.
What a modern billing stack actually has to do
If pricing has moved from "who has a license" to "what happened, how much of it, and when," the billing system has to follow. In practice that means three things have to be solved together, not separately.
Collect usage as it happens
Traditional subscription tools run a script at the end of the month and hope the numbers line up. That cadence is a poor fit for AI products, where a spike on a Tuesday might already be the most important commercial event of the quarter. Plock leans the other way: usage is pulled continuously from the customer's own product data, shaped into named metrics, and recorded as events arrive. By the time anyone asks, the number is already there.
This is the same framing you see on our Charging page — real-time product usage data, straight from the source of truth, rather than a nightly batch.
Model prices the way the product actually works
The second piece is flexibility in the pricing model itself. A plan in Plock can be fixed or consumption-based, billed per unit or tiered, with tiers that are graduated, volume-based, or bulk. Each tier carries its own unit rate, flat fee, and usage threshold. That is not a list of pricing gimmicks — it is the vocabulary you need to describe, say, the first 100k tokens free, the next 900k at one rate, everything above at a second rate, with a platform fee on top.
If your price model cannot be described in your billing system, it does not exist. It lives in a spreadsheet, and spreadsheets lose.
When pricing can actually be modelled in the system that charges the customer, two things change. Experimentation stops being scary, because you can see the outcome of a price change against real historical usage before you ship it. And contract negotiations stop producing snowflakes that nobody can invoice without manual intervention.
Turn usage into a signal, not just a charge
The last piece is the one most billing vendors still miss. Usage data is not only the raw material for invoices — it is the earliest, cleanest signal of what is happening inside the account. A customer burning through their included pool by day ten is either a churn risk or a natural upsell, and the difference matters. In Plock, the same usage data that feeds the invoice also feeds customer health, expansion, and signal detection. One pipeline, one source of truth, used by finance and the success team in parallel.
What this looks like in practice
For teams shipping AI features, the practical implication is this. If you are still bolting usage pricing on top of a seat-based tool, you will feel the seams quickly: reconciliation drift, arguments over which export is correct, month-end that takes a week. If you start from real-time usage collection and model prices on top of that, the month-end reconciliation mostly disappears, because the ledger was already right on the 3rd.
None of this removes the hard commercial questions. You still have to decide what to meter, what to bundle, what to give away, and how to talk about it. But the infrastructure stops being the bottleneck, and the pricing conversation moves back where it belongs — between you and your customer.
If you are rethinking how your AI product should be priced, or reshaping an access-based model into something usage-aware, we would like to hear about it. You can read more on our charging solution page, or get in touch for a walkthrough on your own data.