The access door is open. Now the customer asks the question every pricing page must answer in ten seconds: what am I paying for, and how do I know the bill will be fair? This lesson teaches billing units — the thing you count — and why charging around customer value beats exporting your cost stack as jargon.

The vocabulary, in plain language

• Pricing tier: a named package — Starter, Team, Studio — bundling features, limits, and support at one price. Tiers segment buyers by need, not by confusion.
• Seat: one paid person on the plan. Simple, predictable, and wrong whenever value does not scale with headcount.
• Usage: paying by what gets consumed — briefs generated, workflows monitored, appointments booked. Fair when usage tracks value; frightening when it spikes unpredictably.
• Credit: prepaid units spent on actions — 100 credits a month, one brief costs 10. Flexible for the seller, foggy for the buyer unless each credit maps to a visible outcome.
• Included allowance: what the flat price covers — "5 monitored topics included." The most-read line on any pricing page.
• Overage: the price of going past the allowance — per extra topic, per extra brief. Where surprise bills are born; state it before it happens.
• Metered billing: counting actual consumption and billing it, usually monthly. Powerful and anxiety-producing in equal measure.
• Unit economics: whether one unit of sale, fully loaded with delivery cost, leaves money behind. If each brief costs more in model calls and support than its share of the price, volume makes things worse.

The Stripe recurring pricing models catalog how real products combine these pieces; the Stripe Billing documentation shows how seats, meters, and overages are implemented. Read both after you choose the unit — mechanics serve the decision, not the reverse.

The principle: charge for value the customer already counts

Charge around a unit connected to customer value and cost — not a mysterious internal meter. Customers already count companies researched, workflows monitored, assets published, appointments booked, transactions completed. They do not count tokens or GPU-seconds, and they should not have to.

Good units pass three tests. The customer can predict the bill before acting ("we monitor six topics, that is the Team tier"). The unit aligns with value received (more monitored workflows means more risk caught). And the unit covers your cost without constant repricing (heavy users pay more because they cost and gain more).

Compare candidate units for the Research Desk:

• Per user / per team: simple, familiar, predictable. Fails when one power user monitors fifty topics while tenoccasional readers split one login.
• Per company researched: maps to the job — "cover my twelve suppliers." Predictable per project; awkward for continuous monitoring.
• Per monitored workflow / topic: maps to ongoing value — each watched topic produces recurring briefs. Strong alignment for a monitoring product.
• Per published asset or brief: maps to output — pay per checked brief. Clean for report-style value; punishes exploration and drafts.
• Per booked appointment / per successful transaction: perfect when the product completes an exchange; irrelevant for research.

No unit wins everywhere. The question is which unit your specific recurring job already revolves around.

AI cost alignment without token-jargon transfer

Model and API spend is real and must be covered — but do not simply transfer fluctuating token jargon to users. "You used 48,212 tokens" tells a customer nothing about what they bought and everything about your cost anxiety. It also hands them a bill they cannot predict and a vocabulary they resent.

Package instead. Estimate what a useful outcome costs on average — a checked brief, a monitored topic-month — add margin for support, hosting, and retries, then price the outcome unit. Internally, track tokens per outcome so margin stays honest; externally, sell briefs, topics, and seats. A builder who says "the Team plan covers 10 monitored topics and 40 briefs a month" can survive a model-price change. A builder who sells raw tokens reprices in public every quarter.

Watch the failure shapes: per-seat pricing on an AI product with heavy per-action cost invites one login shared across a department running thousands of generations. Pure usage pricing with no allowance invites bill shock and angry cancellations. Credits with no outcome mapping invite "where did my 500 credits go?" tickets. Each is fixable — allowances, overage caps, outcome-mapped credits — but only if you name the failure before launch.

Exercise: propose three units, score them, pick one

Create PRICING-UNIT.md. The scoring is the learning.

# PRICING-UNIT.md — [Project]

## Candidate units (3)
1. ___ — defined as: ___ / counted when: ___
2. ___ — defined as: ___ / counted when: ___
3. ___ — defined as: ___ / counted when: ___

## Scorecard (1–5 each; 5 is best, except complexity where 5 is most complex)

| Unit | Customer clarity | Value alignment | Bill predictability | Operational complexity | Notes |
| --- | --- | --- | --- | --- | --- |
| 1. ___ | _ | _ | _ | _ | ___ |
| 2. ___ | _ | _ | _ | _ | ___ |
| 3. ___ | _ | _ | _ | _ | ___ |

## Recommendation
- Chosen unit: ___ — because: ___
- Tier sketch: Starter ___ / Team ___ / allowance ___ / overage ___ per ___
- Cost check: avg delivery cost per unit ___ / margin at tier price ___

## Known failure case
- This unit breaks when: ___ / early warning: ___ / fix prepared: ___ (cap / allowance change / tier nudge)

Worked mini-example — Desk: candidates are per seat, per monitored topic, per brief. Per seat scores high on clarity (5) but low on alignment (2) because one analyst can burn heavy model spend. Per brief scores high on alignment (4) but low on predictability (2) — customers hesitate to explore. Per monitored topic wins: clarity 4 ("how many topics do you watch?"), alignment 5, predictability 4 with a 40-brief monthly allowance, complexity 3 (metering topics plus brief counts). Failure case: a customer parks 10 topics but generates 300 briefs by re-running; warning is brief-to-topic ratio above 8:1; prepared fix is a fair-use brief cap with stated overage per 10 extra briefs.

Finish line: a PRICING-UNIT.md with three scored units, one recommendation with allowance and overage, and a named failure case.

Verify quickly: show only the tier sketch to a potential buyer. If they cannot estimate their own monthly bill in under a minute, the unit is still jargon — simplify or add an allowance.

Common failure mode: the token pass-through — billing customers in the same units your provider bills you. It feels honest and reads as abdication. Absorb the complexity; sell the outcome.

Check your understanding

1. Define seat, allowance, overage, and metered billing in your own words. 2. Why should AI builders package model costs into outcome units instead of billing tokens? 3. What four criteria does the unit scorecard use, and why does each matter?

Next

Price architecture is set. Lesson 81.4 faces what the price cannot hide — why customers leave, and how to learn from every cancellation.