An owner with a ten-person team sits at her kitchen table on a Tuesday morning, two competing AI quotes open on her laptop. One charges twenty pounds per seat per month. The other charges per million tokens consumed. The numbers are close enough that she cannot tell which will cost less by year-end, and each sales rep sounded equally confident their model was the cheaper option.
This is a choice more buyers are quietly getting wrong in 2026 than any other in AI procurement. Not the brand, not the feature set, not even the demo. The pricing model. Per-seat and usage-based are the two dominant shapes, and the one you pick shapes total cost of ownership over twelve months more than the per-unit rate does. Get it wrong and the bill can double without anyone noticing until renewal.
The Plain-English AI explainer on what-is-per-seat-vs-usage-based-pricing covers what each model actually is. This piece is the decision-guide layer on top.
Why does this choice matter more than the headline rate?
The pricing model decides how your bill responds when something changes, and something always changes. The headline rate is one input. The model is the formula that turns operational decisions into cost. A per-seat tool at twenty pounds a head and a usage-based tool at a penny a token can produce identical bills at one usage pattern and a three-fold gap at another, with no warning before the gap opens up.
The structural difference is what scales with what. Per-seat pricing assumes value follows headcount, every user creates roughly proportional value, so cost follows the same curve. That assumption held for CRMs and email tools where each user added records, ran queries, and consumed storage in bounded ways. It breaks for AI products because the AI does the work, not the human, and a single AI agent can resolve more tickets in an hour than ten staff handle in a day. Charging for seats while the AI does the work means you pay twice.
Usage-based pricing fixes the alignment problem but introduces forecasting volatility. Bessemer Venture Partners’ AI pricing playbook makes the case clearly, charging for actual consumption means revenue and cost move together. The complication is that consumption is volatile in ways headcount is not. A marketing team planning for one hundred thousand API calls in a month can land at four hundred thousand the week a campaign launches.
When does per-seat pricing actually fit?
Per-seat pricing fits when usage is bounded by human time and headcount is stable. A firm with a settled team of twelve, deploying an AI writing tool that humans use interactively for marketing briefs and email drafts, sits in the sweet spot. Each writer has a working day with a ceiling on how many briefs they produce, the bill is the same every month, and finance can budget twelve months out without a spreadsheet model.
The pattern works well for tools that augment humans rather than replacing them. Support agents using an AI ticketing tool, financial analysts using an AI research assistant, designers using an AI image generator. Each person can only use the tool so much in a day, and per-seat captures that ceiling cleanly. Andreessen Horowitz’s rule of thumb is useful here, per-seat fits when the end user is a person, usage-based fits when the end user is another piece of software.
Where per-seat starts to hurt is in two predictable places. The first is partial adoption, when only four of your eight seats actually use the tool. You still pay for all eight, because few vendors pro-rate for non-use. The second is true-up cost. Per-seat contracts charge immediately for any new seat at the monthly rate, but cutting a seat later does not refund. A ten-person firm that hires two more in month six pays an extra half-year of those seats. The asymmetry favours the vendor.
When does usage-based pricing actually fit?
Usage-based pricing fits when consumption is variable, driven partly by software rather than humans, or when value sits in outputs rather than seats. A backend automation calling an AI model thousands of times a day, a support operation where an AI agent resolves seventy per cent of tickets, an engineer’s workflow that can burn more API calls in an afternoon than the rest of the firm uses in a week. None fit a seat count.
The case for usage-based in those patterns is value alignment. You only pay for the work the system actually does. If usage is light one month, you pay less. If usage scales because the business is doing well, the bill scales with it, but so does the revenue that justifies it. Bessemer’s playbook and Forrester’s pricing research both land in the same place, usage-based is the right shape when the value driver is consumption rather than access.
The cost of that alignment is forecasting volatility. Metronome’s 2025 survey found that finance teams adopting usage-based pricing reported budget variance widening from plus or minus five per cent to plus or minus thirty per cent within the first year. Stripe’s research on usage caps documents repeated cases of bill shock, invoices five to ten times higher than expected because an engineer deployed a workflow in a tight loop and nobody checked the dashboard.
The hybrid pattern many vendors now offer
Hybrid pricing is the model the market has converged on, and the one you will frequently be asked to sign. Metronome’s research puts hybrid at sixty-one per cent of SaaS contracts as of 2025. The shape is consistent across vendors. A base per-seat charge, an included usage allowance per seat, and per-unit overages above the allowance. HubSpot, Intercom, Salesforce, Notion, Microsoft, and OpenAI all sell something close to this structure for their AI products.
On paper hybrid is the best of both worlds. You get a predictable base, value alignment for the variable component, and an allowance that absorbs normal monthly variation. In practice the hybrid pattern is only as good as the contract terms around it, and vendor defaults tend to be vendor-friendly. Unused monthly allowances are commonly forfeited rather than rolled over. Allowance is rarely pooled across the team, so one heavy user pays overage while a light user wastes their bundle. Overage rates tend to be flat rather than tiered. Hard monthly caps are rarely offered without being asked for.
Tropic’s research on negotiating usage-based contracts lists the terms that matter, and they are the same for hybrid contracts. Hard cap, allowance pooling, rollover, tiered overage rates, and the right to adjust spending up or down on a monthly basis. None of these are standard. They need to be asked for, and they are commonly granted to anyone who asks. Buyers who sign the vendor’s default contract are usually signing the worst version of hybrid pricing without realising it.
What to ask before you sign anything
Four questions decide a contract, regardless of pricing model. They are not what the sales rep wants asked first, which is why asking them early is useful. Get clean answers on each one before discussing the per-unit rate. The headline number is the last conversation, not the first.
First, is there a hard cap on monthly charges? A hard cap means usage stops or alerts trigger when you hit the budget you set. Without one, a single workflow can produce an invoice you cannot explain. Second, can usage be pooled across the team? A pool of ten thousand calls across five seats is more useful than two thousand each, because real usage is uneven. Third, do unused allowances roll over? Forfeited allowance encourages waste at month-end and penalises conservative use. Fourth, are overage rates tiered? Tiered rates reward growth and protect against bill shock, flat rates do neither.
The honest answer for many owner-led firms is that they do not yet know enough about their usage pattern to model either pricing structure with confidence. The fix is not to guess. Run a thirty to ninety-day pilot at whatever the vendor offers as a trial or starter tier, measure actual consumption, then negotiate the annual contract with real numbers. The cost of signing a twelve-month contract on the wrong model can run into five figures for a ten-person firm.
If you want to think this through with someone who has bought, built, and rebuilt AI tooling inside owner-led firms, book a conversation.
