Pricing page clarity review
Use when visitors reach the pricing page and leave without choosing a plan.
Fill in before running
Replace each placeholder with your own detail. The more specific you are, the less the model invents.
- {{PLAN_NAMES_PRICES_AND_FEATURES}}
- {{BILLING_MODEL}}
- {{KNOWN_QUESTIONS}}
- {{TARGET_PLAN}}
Getting a better result
- Paste the feature comparison table verbatim, including the tick marks, so it can spot rows that mean nothing to a buyer.
- List the questions your sales or support team actually gets - that is the fastest source of real gaps.
- Ask for the arithmetic check separately if usage based pricing is involved.
Questions about this prompt
When do I use this rather than changing the prices?
When visitors reach pricing and leave without picking a plan, and you suspect comprehension rather than cost. The prompt refuses to add a plan, remove one or change a number, so it stays on what the page fails to explain. If the hesitation is genuinely about risk, the guarantee and risk reversal prompt is closer to it.
What do I need in front of me before running it?
The plan names, prices and features pasted verbatim including the comparison table tick marks, the billing model, the questions sales and support actually get, and which plan you want people to choose. Without the target plan named, the section on anchoring and plan ordering has nothing to judge the current running order against.
What comes back, and which part is worth acting on?
Five sections, then five changes ordered by how much confusion each removes. The arithmetic section is where to start: every place a buyer has to calculate what they will pay is a place some of them stop. Claims about buyer behaviour it cannot verify from your inputs come back marked assumption in brackets.
What is the mistake that costs me here?
Pasting a tidy summary of the plans instead of the table as it appears. The jargon findings depend on the exact feature names, and a row that means nothing to a buyer only surfaces when the wording is intact. Where pricing is usage based, run the arithmetic check separately so it gets proper attention.