The KISS Pricing Framework
The KISS framework is UsagePricing's 10-point rubric for scoring how simple and easy to understand a company's pricing is. Five dimensions — metric legibility, price discoverability, plan surface area, rate complexity, and bill predictability — are each scored 0, 1, or 2 from public materials and summed. It measures whether a buyer can understand the pricing, never whether the price is cheap or fair.
What KISS measures
KISS stands for Keep It Super Simple — a friendlier cousin of the old engineering principle with the same initials. It grades one thing: the comprehension cost of a pricing model. Can a prospective buyer, armed only with the vendor's public pages, understand what a unit is, find the price, pick a plan, do the math, and predict the bill?
Just as deliberately, KISS does not measure cheapness, fairness, or value-for-money — a 10/10 can be expensive and a 3/10 can be a bargain. And maximal simplicity isn't the goal either: sophisticated pricing can be the right design. KISS tells you the comprehension cost you're asking buyers to pay, so you choose it deliberately instead of by accident.
The rubric
Each dimension answers one buyer question and is scored against written anchors — no vibes, no partial credit. The five points sum to a score out of 10.
| Dimension | 2 points | 1 point | 0 points |
|---|---|---|---|
| Metric legibility & value alignment “Do I understand what one unit is — and can I count it myself?” | Plain-language, value-shaped, buyer-countable. Every billed unit is something the buyer already counts as value in their own business AND can verify independently before and after purchase: seats, orders, invoices, emails sent, employees who use the product. | Technical, vendor-counted, or stable credits. Units are countable and well-defined but need domain knowledge to relate to value (tokens, API calls, GB-hours, message segments); OR value-shaped but vendor-adjudicated (resolutions, qualified leads); OR a single credit currency with a published, contractually stable conversion table; OR a billed population that sweeps in non-users (company-wide headcount for a tool a subset uses). | Synthetic or floating. Credits with variable per-feature or per-provider burn rates, compute units with size multipliers — no stable line of sight from unit to money. |
| Price discoverability “Can I find the price without talking to anyone?” | Full public rate card. List prices, usage rates, and overage rates all published; a typical buyer can price their exact scenario from public materials. Negotiable discounts below public list don't demote. | Partially gated. A typical mid-market buyer can mostly price their scenario, but a material component — enterprise tier, volume rates, mandatory fees — requires signup or a quote. If only a toy tier is public, score 0. | Sales-only. "Contact us" is the pricing page; no usable public prices. Gate applies: unverifiable dimensions score 0 and the published total is capped at 4/10. |
| Plan surface area “How many price-changing decisions before I can buy?” | One decision. A single price, or up to three paid plans differing on one axis, no required add-ons. | Two axes. Four to five paid plans, or plans × add-ons / volume-tier ladders, or three-plus distinct unit types to estimate — still one coherent product line. | A matrix. Editions × products × add-ons × fees or minimums that interact; configuring a quote is a project. |
| Rate complexity “Once I've chosen, how hard is the math?” | Flat. A fixed price, or one linear rate per unit type; no schedules. | One schedule. A single graduated or volume-tier schedule, or a rate table on one lookup axis (country, model) — optionally with a small set of additive rate components (separate input/output rates) and opt-in discounts (caching, batch), which don't count as interacting axes. | Needs a calculator. Rates varying on two or more interacting lookup axes (instance × region × OS × term; edition × region), derived unit conversions, or interacting discounts. |
| Bill predictability & spend control “Do I know next month's number today — and can I enforce it?” | Fixed or enforceable. Flat or per-seat subscription, a one-off license, or usage hard-capped by plan or by a spend limit that actually stops service. | Bounded. Non-auto-recharging prepaid balances, enforceable opt-in budget caps, fees proportional to the buyer's own revenue or transactions, or usage driven by the buyer's own deliberate actions. | Open-ended. Post-paid usage driven by inputs the buyer doesn't control (end-user traffic, autoscaling), with alerts at best. Alerts alone don't qualify as bounded; auto-recharging prepay counts as post-paid. |
Scope rules
Applied before any dimension is scored:
- Score the primary offer as merchandised on the company's main pricing page. Conglomerate catalogs (AWS-scale) are scored per flagship product line, not the whole catalog.
- Score only from public materials: the pricing page, docs, and terms. Leaked quotes and hearsay don't count — if the public record can't support a cell, it scores 0.
- Transparency gate: if Price discoverability is 0 (sales-only), every dimension that can't be verified from public materials scores 0 and the published total is capped at 4/10.
- A "decision" is any choice that changes the price and must be made before buying. Free tiers don't count toward plan counts. For pay-as-you-go APIs, choosing a model or SKU inside one rate card is rate-structure complexity (D4), not a plan decision (D3).
- Applicability: entirely free products aren't scored. One-off perpetual licenses score 2 on Bill predictability. Pay-what-you-want scores 2 on Price discoverability. A simple usage minimum counts as one add-on in Plan surface area.
Score bands
Scores publish in five named bands. Within a band, differences are noise — don't read 7-vs-6 as a meaningful gap.
Readable at a glance; nothing to compute or fear.
One wrinkle — a gated tier, a usage layer — but the picture is honest.
Understandable with effort; bring a spreadsheet.
Multiple interacting dimensions; most buyers need help.
Synthetic units, open-ended bills, or no public prices at all.
How scoring works
- Open the company's public pricing materials — the pricing page, docs, and terms. Nothing else counts.
- Score each dimension against its anchors. When facts genuinely sit between two anchors, take the lower one and note why.
- Apply the transparency gate: if no usable prices are public, unverifiable dimensions score 0 and the total caps at 4.
- Sum to a total out of 10 and read off the band.
Worked examples
Three price books scored cell by cell — one simple, one middling, one hard.
Two public plans: $15 per user per month, or $299/month flat for unlimited users with everything included.
| Metric legibility & value alignment | 2 | The unit is a user (or the whole company) — plain language, and the buyer counts it themselves. |
| Price discoverability | 2 | Both prices sit on the public pricing page; any scenario is priceable in seconds. |
| Plan surface area | 2 | Two plans on one axis — per-user or flat unlimited — with no add-ons. |
| Rate complexity | 2 | Flat numbers; the only math is seats × one rate. |
| Bill predictability & spend control | 2 | The bill is fixed by the plan chosen; there is no usage component to drift. |
Claude subscriptions (Free / Pro / Max / Team) plus a pay-as-you-go API priced per million tokens by model, with cache and batch discounts.
| Metric legibility & value alignment | 1 | Seats are plain, but tokens — the API's unit — are technical: countable to the byte, yet most buyers need the docs to relate a token to value. |
| Price discoverability | 2 | Every rate is public, including per-model API pricing and the cache/batch discounts. |
| Plan surface area | 1 | A subscription ladder plus a separate API line — two axes, but nothing that interacts like a quote matrix. |
| Rate complexity | 1 | One lookup axis — the model catalog — with two additive published rates per model; cache and batch are opt-in discounts a buyer can ignore, not interacting axes. |
| Bill predictability & spend control | 1 | Subscriptions are fixed and API usage runs on prepaid credits with spend limits — bounded, though not hard-stopped by default. |
Compute billed in credits that warehouses consume by size (1 to 512 credits/hour), priced per credit by edition and region, with storage and serverless features billed separately.
| Metric legibility & value alignment | 0 | A credit's burn rate depends on warehouse-size multipliers and per-feature serverless rates — no stable line of sight from unit to money. |
| Price discoverability | 2 | Credit prices, size multipliers, and storage rates are all published. |
| Plan surface area | 1 | Edition × cloud/region × on-demand-vs-capacity are real pre-purchase choices, but picking them is a lookup, not a project. |
| Rate complexity | 0 | Credits/hour × warehouse size × edition × region plus separate storage and serverless multipliers — a calculator is mandatory. |
| Bill predictability & spend control | 0 | On-demand compute scales with query workloads and auto-scaling by default — open-ended without deliberate spend controls. |
Symptoms of a low score
You rarely need the rubric to know something is wrong — a low KISS score shows up in daily operations first. Each symptom points at the dimension that's bleeding:
- Customers file support tickets asking how the bill was calculated. Metric legibility
- Prospects ask for a quote before they can tell whether they're even in budget. Discoverability
- Sales can't explain the price in sixty seconds without opening a spreadsheet. Plan surface area
- The pricing page needs a calculator because prose can't state the number. Rate complexity
- Finance can't forecast next quarter's spend from the price book alone. Predictability
- A "why did my bill double?" thread about you exists on Reddit or Hacker News. Predictability
Score your own pricing
Pick the anchor that honestly describes your pricing in each dimension — as a buyer would see it from your public pages, not as you see it from inside. Full anchor definitions are in the rubric table above.
A self-assessment against rubric v1.1 — not an official UsagePricing score.
Limitations
What KISS deliberately doesn't measure
Two adjacent concepts are excluded on purpose, not overlooked:
- ROI models. The same pricing yields a different return for every customer — ROI is a property of the buyer's economics, not of the pricing design, so it can't live in a score of the design. It belongs in a companion framework.
- Attribution. Chargeback, showback, and who-drove-the-bill are post-purchase FinOps operability concerns about the buyer's cost management — real, but a different question from whether the seller's pricing can be understood. Also companion-score territory.
Value alignment, by contrast, is measured — inside metric legibility — because a unit the buyer already counts as value is genuinely easier to understand, provided the buyer can verify the count.
Known limitations
- KISS reads the price book, not the contract — auto-renewal traps, price escalators buried in terms, and audit exposure are invisible to the score. A hostile contract can sit behind simple-looking pricing.
- Rate complexity and bill predictability tend to move together for metered pricing. They stay separate because hard math and an unpredictable bill are different harms — and real spend control recovers predictability points.
- An 11-point scale produces ties, so scores publish in five bands, not a strict ranking. Don't read 7-vs-6 as a meaningful gap.
- The middle band of price discoverability is wide: 'everything public but one enterprise SKU' and 'entry tier public, the rest quoted' both score 1.
- A conglomerate's score describes its flagship offer as merchandised, not every SKU it sells.
FAQ
What is a KISS pricing score?
A KISS score is UsagePricing's 10-point measure of how simple and easy to understand a company's pricing is. Five dimensions — metric legibility, price discoverability, plan surface area, rate complexity, and bill predictability — are each scored 0, 1, or 2 from public materials and summed.
Does a high KISS score mean the pricing is good value?
No. KISS measures whether you can understand the pricing, not whether you should like it. A 10/10 can be expensive and a 3/10 can be excellent value — AWS pricing is famously complex and famously worth it. Value-for-money and ROI are deliberately out of scope.
How is the score calculated?
Each of the five dimensions has written 0/1/2 anchors, scored only from public materials — the pricing page, docs, and terms. The five points of a company's answer are summed to a total out of 10, with one exception: if no usable prices are public at all, unverifiable dimensions score 0 and the total is capped at 4.
Why does sales-only pricing score so low?
Because the framework's question is whether a buyer can understand the pricing, and a page that says only 'contact us' offers nothing to understand. Without public prices the other dimensions can't be verified either, so the transparency gate caps the total rather than letting opacity win points back.
Is usage-based pricing automatically penalized?
No — but badly instrumented usage-based pricing is. A metered product with one linear rate on a relatable unit, published prices, and a spend limit that actually stops service can score 8 or higher. What loses points is multi-axis rate math and open-ended bills with alerts at best.
Can I score my own pricing?
Yes — the framework page includes a self-scorer that walks you through the five dimensions with the same anchors we use, applies the transparency gate, and gives you a total and band. It's a self-assessment, not an official UsagePricing score, but it uses the identical rubric.