Design a usage-based pricing scheme that scales revenue with value without scaring customers away — the metric that tracks value, tiers with included volume, and the guardrails that prevent bill shock. Use when asked to design usage-based or metered pricing, move from seats to consumption, price an API or AI product per unit, or handle customers afraid of variable bills. Produces the value-metric selection, the tier structure with included volumes and overage rates, the bill-shock guardrails, revenue modelling at usage percentiles, and the migration plan from the current model.
“Design usage-based pricing for our API”“We want to move from per-seat to consumption pricing”“How do we price our AI product per token without bill shock?”“Customers are afraid of variable bills — what guardrails do we need?”“Model what usage pricing would do to our revenue”
What to give it
▸The product and what "usage" means in it — API calls, seats, tokens, GB, transactions, jobs, minutes
▸The usage distribution — real percentiles across current customers if they exist (P10/P50/P90/P99), or honest estimates
▸The cost structure — marginal cost per unit of usage, so the floor is known
▸The current model and its problem — what pricing exists today and what is breaking (leaving money on big accounts, scaring small ones, misaligned with value)
▸The buyer — who approves the bill, and how much variance their budget process tolerates
✅ The bar it holds itself to
Every skill in this library self-verifies — these are this skill's own quality checks, straight from its definition.
✓The metric passes all four tests, and rejected alternatives are recorded with the failing test
✓Tiers are placed on the real usage distribution, not round numbers
✓The effective rate falls (or holds) as usage grows — no inversion where heavy users pay more per unit
✓Every guardrail exists in the design before launch, not as a support policy invented after the first incident
✓Revenue is modelled at percentiles, with the current model as the comparison column
✓The margin floor is checked against the lowest effective rate
✓The three degenerate cases have written policies
✓The migration names who pays more and what they are offered
⚠️ What it refuses to do
**Choosing the meterable metric over the valuable one.** You can meter API calls precisely; if value lives in outcomes, the customer resents every call.
**Pricing on the average customer.** The usage distribution is heavy-tailed; the average customer barely exists.
**Overage as a fine.** Overage at 5× the in-tier rate produces the invoice screenshot that becomes your pricing page's reputation.
**No answer to "what's the worst case?"** A buyer who cannot bound the bill will not sign, and the one who does not ask will churn when it happens.
**Punishing adoption.** Per-seat metering on a collaboration product taxes the behaviour that retains the account.
Install
npx pm-claude-skills add --agent claude # or codex · cursor · gemini · hermes
# or one-line MCP (every skill, any client):
claude mcp add pm-skills -- npx -y -p pm-claude-skills pm-claude-skills-mcp