Good-Better-Best Plans

Turn one product into three decision-ready plans so the buyer chooses a tier instead of deciding whether to buy at all.

Pro involved Pricing & Packaging Offers

What it adds

The builder reads your feature list, existing pricing notes, and customer segments, then constructs three plans around a single shared value metric with deliberate ceilings that make the middle plan the obvious landing spot. Conversion comes from replacing a yes-or-no decision with a which-one decision, and from making the top plan expensive enough to make the middle feel proportionate. The goal is a higher share of visitors selecting the target tier without extra sales contact.

What your builder is told to do

The actual instructions, in order.

1
Inspect the supplied feature inventory, existing price sheet, and any customer-segment or usage notes, and produce a working list of every capability with the segment that actually asks for it.
2
Choose one value metric that scales with the buyer's own success (records, projects, seats, sends, locations) and confirm the source files show it growing as accounts grow; if two candidates tie, pick the one buyers already track themselves.
3
Define tier boundaries by segment ceiling rather than by even feature counts: the Good plan solves one job completely but hits a real ceiling, Better removes the ceiling that the primary segment hits first, and Best carries the low-frequency, high-cost capabilities that only the largest accounts request.
4
Set the Best plan price high enough to act as the anchor for the page, then position Better so its price gap to Good is smaller than its gap to Best, and label Better as the most-chosen plan only if the source files contain evidence of that; otherwise label it by the segment it fits.
5
Write each plan's headline as an outcome for a named buyer type, list only the three to five differences that change the outcome, and move the shared baseline capabilities into a single included-in-every-plan strip so the comparison stays readable.
6
Build the upgrade path in the interface: show what the current plan blocks at the moment it is blocked, price the difference rather than the whole plan, and make mid-cycle upgrade proration and downgrade timing explicit in plain language.
7
Specify responsive behavior. On mobile, stack the plans Good to Best with the target tier rendered first, collapse the comparison into an accordion, and keep a sticky select-plan bar. On tablet, show two plans per row with the third wrapping full width and the feature matrix horizontally scrollable with the plan names pinned. On desktop, present all three side by side with the target tier visually elevated and a full comparison table below the fold.
8
Add a single objection block below the table that answers switching, limits, and cancellation using only what the source files state.

Edge cases it handles

The things an agent skips when you only say "build a good-better-best plans".

A buyer whose usage sits exactly on a tier boundary needs an explicit rule for which plan the interface recommends and what happens the month they cross it.
If the source files reveal a segment that needs one Best feature but none of the others, note it as an add-on candidate rather than silently widening the Better plan.
Annual and monthly toggles can invert the visual price ordering; verify the middle plan still reads as proportionate in both billing states.
Existing customers on legacy prices must see their current plan reflected accurately rather than being shown as unsubscribed.
If the feature inventory does not support three genuinely distinct ceilings, flag it and propose two plans plus an add-on instead of padding a third.

Definition of done

Your builder is required to check every one of these before reporting the work finished.

Exactly one value metric governs all three plans and it appears in the same units on every card.
The middle plan is identified as the target and its price gap to the entry plan is smaller than its gap to the top plan.
Each plan lists no more than five differentiating lines, with shared capabilities factored out into one common strip.
Upgrade, downgrade, and proration behavior is described in plain language visible without contacting support.
Mobile, tablet, and desktop layouts are each implemented as specified and verified at their breakpoints.
No feature, limit, price, or popularity claim appears that is not traceable to a source file.
The builder reports which source files it used for the feature list and price points, and lists every assumption it could not resolve from them.

Related offer files

Pricing & Packaging Offers

Multi-Product Bundle

Combine separate products into one subscription that solves a whole workflow, priced below buying each product on its own.

Pricing & Packaging Offers

Setup Fee Plus Monthly Offer

Separate the one-time work of getting started from the ongoing service, so the monthly figure stays low and the launch is funded.

Pricing & Packaging Offers

License Renewal Offer

Renew expiring licenses by showing what was actually used during the term and what continued access protects going forward.

How it works

1

Copy the link

Grab the Markdown blueprint URL for this offer type.
2

Give it to your builder

Paste it into Claude Code, Cursor, Codex, or whatever AI builder is already working in your app.
3

It maps, then builds

Your agent reads the blueprint first, then builds the offer into your app around the product, audience, and stack.

Works with your stack

These blueprints are written to adapt. They tell the agent to detect your framework, match your existing design system, and use your source files instead of guessing the offer.

Need it tighter than that? Customize the offer file and tell it exactly which source docs and stack to use.