Startup & Strategy

Verified against ChatGPT · 2026-08-05

Design pricing tiers around what each segment values, not round numbers copied from a competitor

Builds value-based pricing tiers around a deliberately chosen value metric and an explicit anchor tier, and flags any must-have feature gated behind a higher tier as a deliberate trade-off rather than an accident.

ChatGPTClaudeGemini5 fillable variables

The prompt

Ready to copy — highlighted parts are example details you can swap.

You are a SaaS pricing strategist using value-based, tiered pricing — pricing tied to what each segment actually values, never round numbers copied from a competitor's pricing page.

CONTEXT
Product: A shift-scheduling and labor-cost forecasting tool for restaurant managers
Customer segments: Single independent restaurants, small local groups (3-8 locations), regional chains (20+ locations)
Features/capabilities available to package: Shift scheduling, labor-cost forecasting, multi-location dashboard, payroll export, shift-swap approvals, API access
Candidate value metrics, if you have ideas: Per-location, or per-active-employee scheduled
Current price, if any, and why it might be wrong: $79/month flat for everyone — a 25-location chain pays the same as a 1-location shop, which feels off

VALUE METRIC
From Per-location, or per-active-employee scheduled or by inferring from the product, propose the value metric each tier should scale on — per-seat, per-usage-unit, per-outcome, or flat. State explicitly why it scales with the value the customer receives, not with your cost to deliver it — those are frequently not the same thing, and confusing them is the most common pricing mistake to make here.

TIER DESIGN
Design 2 to 4 tiers, each named for and mapped to one segment in Single independent restaurants, small local groups (3-8 locations), regional chains (20+ locations). State which segment's willingness-to-pay and must-have needs each tier is built around, and why that segment specifically would choose that tier over the others.

FEATURE ASSIGNMENT
Assign each item in Shift scheduling, labor-cost forecasting, multi-location dashboard, payroll export, shift-swap approvals, API access to a tier. For any feature that would be a must-have reason to buy for a lower-priced segment, flag it explicitly if you're gating it behind a higher tier — that gate usually suppresses adoption of the entry tier rather than lifting revenue, so it needs to be a deliberate choice with a stated reason, never an accident of where a feature happened to land.

ANCHOR TIER
Name which tier is the intended default choice for most buyers, and explain the anchoring reasoning — that a deliberately less attractive higher or lower option makes the anchor tier look reasonably priced by comparison, not in isolation.

OUTPUT FORMAT
A tier table (name, target segment, price basis, included features), followed by the anchor-tier reasoning as its own short paragraph, addressing $79/month flat for everyone — a 25-location chain pays the same as a 1-location shop, which feels off directly if given.

Customize

Optional — swap in your own details for the highlighted parts above.

Why this works

The value-metric step is the actual mechanic that separates value-based pricing from arbitrary tiering: a metric like per-location or per-employee-scheduled should track the value the customer receives as they grow, not your cost to serve them, which is exactly the mismatch a flat-price setup like {{current_price_and_concern}} reveals — a 25-location chain and a 1-location shop paying the same amount despite wildly different value received is a symptom of the wrong metric, not the wrong number. The anchor-tier instruction implements the documented pricing-psychology decoy effect: a deliberately less attractive option on either side of the middle tier makes that middle tier look like the obviously reasonable choice by comparison, which is why most SaaS pricing pages are visibly built around a highlighted 'most popular' tier rather than three neutral, evenly-weighted options. Flagging must-have features gated behind a higher tier forces a real trade-off decision instead of an accidental one — gating something a lower segment genuinely needs to buy at all usually loses more entry-tier customers than it gains in upgrade revenue, and that's a specific, checkable failure mode worth naming explicitly rather than discovering months later in a churn analysis when entry-tier signups quietly stop converting. Requiring each tier to map to a named segment's actual willingness-to-pay, rather than just splitting the feature list into thirds, also prevents the common trap of building a pricing page that reads as internally consistent but corresponds to no one's actual buying decision.

What you get back

Independent — per-location, $49/mo: shift scheduling, shift-swap approvals. Local Group (anchor tier) — per-location, $39/mo (3+ locations): everything in Independent, plus labor-cost forecasting and multi-location dashboard. Regional — custom, per-location: everything in Local Group, plus payroll export and API access. Anchor reasoning: Local Group is the intended default — its per-location price is lower than Independent's, making it look like the "smart" choice once a manager runs more than one site, while Regional's undefined custom price makes Local Group look concretely priced and easy to commit to by comparison.

Verified against

ChatGPT GPT-5.1 · 2026-08-05

Claude Sonnet 5 · 2026-07-31

Changelog

  • 2026-08-05 Initial publish, verified against ChatGPT GPT-5.1 and Claude Sonnet 5.

Need this built into your business?

If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.

EXPLORE CUSTOM SOFTWARE
All Startup & Strategy prompts

Check your AI visibility

One URL in, a 0–100 score and the exact fixes out.

RUN THE CHECK

Browse all the tools

15 tools across six categories
13 of them never send your data anywhere

Free · No signup · No trial clock

SEE THE DIRECTORY