---
name: pricing-tier-design
source: https://app.decimal.ai/s/pricing-tier-design@1/SKILL.md
source_sha256: 99319ab0e637
---

# Pricing Tier Design (Good / Better / Best)

## What this does

This skill turns a product with a pile of features into a **packaged three-tier lineup** — a
Good/Better/Best structure built to answer "which package does each customer buy, and what makes
them move up a tier" — not an open-ended pricing consult that answers "what should our pricing
philosophy be."

The bare-model default, asked to "package this into tiers," is a **rambling consult plus a generic
feature grid**: paragraphs on willingness-to-pay, personas, and competitor benchmarking, then a
Basic/Pro/Enterprise table where features are sprinkled across tiers with no logic — each tier is
just "the last one plus more stuff." That grid does not tell a buyer why they'd upgrade, and it
meters different tiers on different axes.

A packaged lineup makes four deliberate moves the default skips:

1. **One value metric** meters every tier.
2. **One fence feature** guards each upgrade boundary.
3. **The top tier anchors** the whole lineup.
4. The result is **one three-tier table**, not prose.

## The four moves

### 1. Pick ONE value metric — the single axis usage scales on

The **value metric** is the one unit a customer buys more of as they get more value: seats, projects,
monthly API calls, GB stored, contacts, tracked assets. Pick exactly one and let it climb across all
three tiers. Every tier is metered on that same axis (5 seats → 25 seats → unlimited seats), so the
buyer reads the ladder in a single glance.

Choose the metric that **tracks the value the customer gets**, not the cost you incur. "Seats" works
when value grows with team size; "records processed" works when value grows with volume. The wrong
metric charges a solo power-user the same as a hobbyist, or caps a team on something they don't care
about. Pick one and commit — do not meter Good on seats and Best on data volume. If two axes both
grow with value, pick the one the buyer already uses to describe their own scale, and mention the
other only as an add-on.

### 2. Place the fence feature at each boundary

A **fence** is the ONE capability a customer hits, needs, and cannot get without moving up a tier.
It is the reason the upgrade happens. Each of the two boundaries (Good→Better, Better→Best) gets
exactly one clearly-named fence — the single most-wanted feature just out of reach.

- Good→Better fence: the feature a growing individual/small team hits first (e.g. *team roles &
  shared workspaces*, *integrations*, *the automation the free-tier user keeps asking for*).
- Better→Best fence: the feature that only the largest / most-regulated buyer needs (e.g. *SSO/SAML*,
  *audit logs*, *SLA & dedicated support*, *advanced permissions*).

Everything else is filler that can sit in whatever tier; the **fence** is load-bearing. Do not
scatter five half-features across a boundary — name the one that does the pulling. A boundary with no
fence is why "Basic + more of the same" never converts anyone upward.

### 3. Make the top tier a deliberate anchor

Set the highest tier (Best / Enterprise) intentionally high — richer and pricier than most buyers
will pick. Its job is not primarily to sell; it is to **anchor**, making the middle tier read as the
sensible, reasonable choice by comparison. The middle (Better) is the tier you actually want most
buyers to land on; the anchor exists to steer them there. Say plainly which tier is the anchor and
which is the intended default — that intent is the whole point, and the default grid never states it.

### 4. Output ONE three-tier table

Deliver a single table with three columns (Good / Better / Best — rename to fit the product), rows
for the value-metric level, the fence feature at each boundary, the key included features, and the
target buyer per tier. One table, readable top to bottom. Prose only for a two-line note on which
tier is the anchor and which is the default.

## Working from what you're given

- Package **only the features present** in what the user gives you. Do not invent capabilities (no
  fabricated "AI assistant" tier) to fill a column.
- If the user hasn't said what their value metric could be, infer candidates from the product and
  **name the one you picked and why** — don't punt the decision back.
- Setting the actual dollar prices is out of scope; use relative placeholders (`$`, `$$`, anchor)
  unless the user supplied numbers. This skill designs the *structure*, not the price points.
- Three tiers is the default. Only add a fourth (e.g. a free tier) if the user's context calls for
  it, and still keep one value metric and one fence per boundary.

## Example (shape only)

For a project-management tool, value metric = **projects**:

| | Good (Solo) | Better (Team) — *default* | Best (Business) — *anchor* |
|---|---|---|---|
| Projects | Up to 3 | Up to 25 | Unlimited |
| Fence in | — | **Shared workspaces & roles** | **SSO + audit log** |
| Includes | Boards, basic reports | + automations, integrations | + advanced permissions, SLA |
| For | Individuals | Growing teams | Regulated orgs / IT-led buys |

Note: Team is the intended default; Business anchors the lineup so Team reads as the reasonable pick.