MODULE 4 · LESSON 3
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolPricing When Cost Scales With Usage
The models, and how each fails
There is no correct answer, only trade-offs against your usage distribution — which is why module 4's first lesson insisted you model it before pricing.
The practical middle
Most successful AI products land in a similar place, and it is worth knowing the shape rather than rediscovering it:
A per-seat or per-tier price that covers typical usage comfortably, with a generous fair-use bound, and paid overage or an upgrade path above it.
Three things make this work:
The bound must be genuinely generous. Set it where perhaps 95% of users never approach it. A bound that normal users hit produces support tickets, resentment and churn, and it suppresses the engagement you need for the product to succeed.
Communicate it as a bound, not a quota. "Includes up to 500 documents a month" reads differently from "500 document limit", and the difference is not cosmetic — one describes generosity, the other describes restriction.
Never hard-stop. A user blocked mid-work is an outage from their perspective. Notify, offer the upgrade, keep serving, and settle it commercially. The cost of serving a few hundred extra requests is trivially less than the cost of a lost customer.
Pricing on outcomes
The most appealing model and the hardest to operate. "Pay per resolved ticket" or "pay per successful placement" aligns your revenue with customer value perfectly, which makes it attractive to buyers and a strong differentiator.
Three problems to solve before committing:
Attribution. Was the ticket resolved by your product or by the agent who edited its draft? Customers will dispute this exactly when the bill is large.
Definition drift. "Resolved" turns out to mean different things in different customers' workflows, and each variation is a negotiation.
Exposure. Your cost scales with attempts; your revenue scales with successes. A period of poor performance costs you twice — you serve more requests and bill for fewer.
Outcome pricing works best where the outcome is unambiguous, recorded in a system both parties trust, and where your success rate is stable and well understood. That is a high bar, and it is usually reached after some time on a simpler model rather than at launch.
Falling prices, and what to do about them
Inference prices have fallen substantially and repeatedly while capability has risen. Assume that continues, without depending on it.
The implications are asymmetric and worth thinking through:
Do not build a business that only works at today's prices. If your margin requires a price cut that has not happened, you have a hope rather than a plan.
Equally, do not price on tomorrow's costs. Committing to a price that only works after an expected reduction is a bet on a third party's roadmap.
Falling costs are most valuable as margin recovery, not as price cuts. When unit costs fall, the instinct is to pass it on. Consider instead absorbing it — into better margin, into a more capable model at the same price, or into raising the fair-use bound, which improves the product experience without changing the price.
Price on value, not on cost. This is standard pricing advice and it applies with extra force here, because cost is volatile and value is not. A product saving a professional five hours a month is worth a proportion of five hours regardless of what inference costs this quarter.
A pattern worth avoiding by anticipation, because the fix is almost entirely in the launch decision.
A team launches at £30 per user per month, unlimited use, because it is simple and competitive. Adoption is good. Eighteen months later, heavy users have grown from 3% to 14% of the base, and the blended margin has fallen from healthy to marginal — not because anything went wrong, but because the product succeeded and usage deepened.
Now every option is bad:
Introduce limits. Existing customers experience a takeaway. Even a generous bound is read as a reduction in what they bought, and the customers most affected are the advocates.
Raise prices. Defensible, but it lands on everyone including the light users who were always profitable, and it invites re-evaluation of the whole purchase.
Absorb it. Margin stays poor, which constrains everything else and eventually forces the decision anyway.
Grandfather existing customers. Two pricing models to maintain forever, and the unprofitable cohort is exactly the one that never churns.
The cheap version of this problem is solved at launch: model the usage distribution, set a generous bound from day one, and communicate it as inclusion rather than restriction. Customers who join with a bound in place never experience it as a loss, and the bound can be raised later — which is a gift rather than a takeaway.
The general principle: it is far easier to give than to take away, so launch with the structure you will need at scale and improve it, rather than launching maximally generous and retreating.
Why should an AI product avoid hard-stopping a customer who exceeds their usage bound?
The five pricing models
Click to flipFlat per seat, per seat with fair-use bounds, usage-based, tiered by volume, and outcome-based. Each fails differently, and the right choice depends on your usage distribution.
Click to flip backEvery pricing model fails somewhere, and which failure you get depends on a usage distribution you must model before launch. Most successful AI products settle on a seat or tier price with a genuinely generous fair-use bound and paid overage — communicated as inclusion, and never enforced by a hard stop. Outcome pricing aligns with value but needs an unambiguous, trusted, stable outcome measure. And price on value rather than cost, because cost is volatile while the value of the hours you save is not.