SaaS Pricing Prompt: Design Tiers From a Value Metric

Most SaaS pricing advice online stops at theory. You read about freemium versus usage-based, value-based versus cost-plus, and then you're left staring at a blank pricing page with no idea what Tier 2 should actually cost. A saas pricing prompt closes that gap: it takes your inputs and returns a copyable tier table you can ship.

The problem isn't a shortage of pricing frameworks. It's that none of them output the artifact you need. You don't want a 2,000-word lecture on price elasticity. You want three named tiers, a value metric they scale along, the fence that pushes someone from Pro to Business, and the lever that grows the account after they sign.

That's a structured-output job. And it's exactly the kind of job a prompt with a locked output contract does well, while an open-ended "design some pricing" request does not.

Why generic pricing prompts give you mush

Search "saas pricing prompt" and you'll mostly find one of two things. Open-ended templates that say "create a full pricing strategy for [product]" and leave tier mechanics entirely to the model. Or pricing-theory essays that explain the models without producing one.

The SaaS Pricing Model prompt on DocsBot is typical of the first kind. It ships a tidy nine-step framework (business goals, customer analysis, value proposition, define tiers) but it never locks the output to a table, and the page shows no sample of what comes back. "Define Pricing Tiers" is step six with no structure attached. The GPTBot pricing-strategy prompt is even looser: "analyze the competitive landscape and identify potential pricing models." Useful framing. Not a pricing page.

The paid options aren't better-shaped, just gated. PromptBase's SaaS Pricing Model Simulator paywalls the actual prompt at $6.99 and, per its own sample output, returns a pros-and-cons comparison of freemium versus subscription versus usage. Not a tier table with fences and expansion levers.

So here's the gap, and it's a real one: there's no widely-shared prompt that forces a value metric first and returns a copyable tier table with fences and expansion built in. That's what this post hands you.

What you can do with this prompt

• Turn one value metric plus two or three segments into a named three-tier table
• Set price points anchored to willingness-to-pay, not gut feel
• Define the fence between each tier (the feature or limit that triggers an upgrade)
• Build expansion levers in from day one (overage, seats, usage bands)
• Stress-test packaging against a free or trial entry point
• Generate annual-versus-monthly framing and a discount logic
• Produce a one-line rationale per tier so sales and the website say the same thing

Anatomy of the pricing prompt

The shape that makes this work: take the squishy inputs, force the value metric to the top, and lock the output to a table the model can't wander out of.

Variables  → {{product_description}}, {{value_metric}}, {{customer_segments}},
             {{cost_floor}}, {{competitor_prices}}, {{pricing_goal}}
Prompt     → Role: SaaS pricing strategist.
             Task: design 3 tiers that scale along {{value_metric}}.
             Rules: every tier maps to one segment; each higher tier
             must have a clear fence; build at least one expansion lever.
Output     → A markdown table:
             | Tier | Segment | Price | Value-metric limit | Fence to next | Expansion lever |
             plus a 1-line rationale per tier and one packaging risk.

The value metric is the load-bearing input. A value metric is the single unit a customer pays more for as they get more value: seats, API calls, contacts, GB, transactions. Tiers that scale along it expand naturally. Tiers that don't — flat per-seat pricing on a product where value comes from usage — leave money on the table and invite gaming. Put {{value_metric}} near the top of the prompt and the model designs around it. Bury it, and you get three arbitrary feature buckets.

Step-by-step usage

1. Gather inputs

Write a two-sentence {{product_description}}, name your {{value_metric}}, and list two or three {{customer_segments}} with a rough budget band each. If you sell to solo founders and to 50-person teams, those are different fences.

2. Fill the variables

Drop real numbers into {{cost_floor}} (your marginal cost per unit of the value metric) and {{competitor_prices}}. The model anchors to whatever you give it, so vague inputs make vague tiers. "Roughly $40/seat at the two closest competitors" beats "competitors charge a lot."

3. Run the prompt

Run it once. Read the table top to bottom. The first pass is a draft, not a verdict.

4. Pressure-test the fences

For each fence, ask: would a real customer actually upgrade here, or would they just live with the limit? A good fence sits right where pain starts. A bad fence is cosmetic and gets ignored. This is where most generated pricing falls apart, so spend your time here.

5. Iterate on one variable

Change one input and rerun. Tighten the value-metric limit on the entry tier, or split a segment. Don't rewrite the whole prompt between runs — you won't know which change moved the output.

Prompt-craft patterns that make pricing output usable

Put the value metric in the constraints, not the context. A weak prompt mentions the value metric in passing. A strong one makes it a hard rule: "Every tier's price and limits must scale along {{value_metric}}." Stated as a constraint, the model can't quietly default to flat feature tiers.

Constraint: All three tiers must scale along {{value_metric}}.
A tier whose price doesn't change with {{value_metric}} usage is invalid —
redesign it before returning the table.

Lock the output to a table with named columns. Free-form pricing advice is unusable; a table you can paste into a spreadsheet is shippable. Name every column in the output contract. Models honor an explicit column list far more reliably than "present this nicely." Worth noting: Claude tends to hold a markdown table structure across a long prompt better than GPT-4o, which sometimes drops a column on the final tier unless you restate the header near the end of the prompt.

Demand a fence and a lever per tier. The whole point of tiers is the upgrade path. Force the model to name the fence (what gates the upgrade) and the expansion lever (what grows the account after signup) for every tier. Without that instruction you get three price points and no growth motion.

Variables you'll set

An opinion: skip freemium until your value metric is proven

Here's a take a lot of pricing blogs won't give you. Don't add a free tier just because every competitor has one. Freemium only works when your value metric is the same thing that costs you money to serve — then free users self-limit and the upgrade is natural. When your free tier hands away the exact value people would pay for, you've trained the market to expect it for nothing. A pricing prompt that asks for {{pricing_goal}} and returns a free tier by reflex is doing you a disservice. Tell it to justify the entry tier against your value metric, or to start with a trial instead. A trial expires. Free doesn't.

Getting started

1. Copy the prompt structure above into ChatGPT, Claude, or Gemini.
2. Fill {{value_metric}} first — it's the input everything else hangs on.
3. Add your {{customer_segments}} with real budget bands.
4. Run it and read the tier table top to bottom.
5. Pressure-test each fence against a real upgrade decision.
6. Change one variable, rerun, compare.
7. For a version that ships with the fences, expansion logic, and a packaging-risk check already wired in, reach for the Pricing & Packaging Strategy Playbook instead of rebuilding the contract each time.

Pricing rarely lives alone. If you're pricing into a market and need the narrative to match, the Fundraising Narrative Playbook keeps your revenue story consistent with how you've packaged.

Pricing is a structured-output problem, and structured output is what a well-shaped prompt is for. If you want the broader argument for buying the contract instead of rebuilding it, read why prompt packs beat awesome-prompts lists, and when pricing decisions need to land in a requirements doc, the PRD prompt for product requirements keeps packaging and scope in one place. Then go price something.