A pricing page should let a suitable buyer understand what they pay, what they receive, what changes the total cost, which plan fits their situation and what commitment comes next. Use plain labels, state billing periods and material conditions beside the price, explain meaningful differences between plans, and provide a contact route only where a genuine scoping conversation is necessary.
Start with the pricing decision
The page is not only a table. It supports a decision about fit, affordability and risk. Define what a visitor needs to compare:
- unit of price—user, project, usage, location or fixed scope;
- billing period and currency;
- minimum commitment;
- included limits and overage treatment;
- plan differences that matter to the customer;
- setup, support or third-party costs;
- cancellation, renewal or trial conditions;
- taxes where relevant.
Coordinate these facts with product, finance, legal and operations owners. Marketing language cannot repair an ambiguous commercial model.
Name plans around fit, not status
Labels such as Starter, Pro and Enterprise are familiar but often force visitors to decode what “Pro” means. Add a concise fit statement based on observable needs: “For one team managing up to five active projects” is easier to evaluate than “For growing innovators”.
For each plan, show:
- who it is designed for;
- the price and billing basis;
- the important included capabilities;
- usage, seat or support limits;
- material exclusions or dependencies;
- the accurate next action.
Order features by decision importance, not by internal architecture. Link to full detail when tables would become unreadable.
Explain value without hiding cost
Connect the plan to a customer task or level of complexity. Avoid claiming that an option “pays for itself” unless you can support the assumptions for the audience concerned.
The UK CAP Code pricing rules require quoted prices to include non-optional taxes, duties, fees and charges that apply to all or most buyers where applicable, and to make qualifications clear. Specific requirements vary by market and customer type, so pricing content needs suitable review. Put any objective saving or performance statement through the same process used to support marketing claims with proof.
Avoid visual or verbal pressure that distorts choice: preselected add-ons, hidden renewal conditions, false scarcity or a visually dominant option unrelated to customer fit. The UK Competition and Markets Authority explains online choice concerns in its work on online choice architecture.
Illustrative example: a three-plan analytics product
Illustrative example: imagine analytics software with three plans.
Unhelpful distinction:
- Basic — essential features
- Pro — advanced features
- Premium — everything you need
Clearer distinction:
- Monitor: for one team reviewing standard weekly dashboards; includes five data sources and monthly email support.
- Investigate: for teams creating custom analyses; adds unlimited saved views and daily support.
- Govern: for organisations that need single sign-on, audit logs and procurement review; priced after confirming users and support requirements.
The page would still need exact prices where they can be determined, clear definitions of “data source” and “user”, and any setup or usage costs. “Contact us” is justified for the third option only if the scope genuinely changes the price.
Answer risk and implementation questions
Price rarely stands alone. Buyers may need to know how long setup takes, who provides data, what support includes, whether a trial converts automatically or how cancellation works.
Place concise answers near the decision, then link to current terms or documentation. Use the method in objection messaging to answer directly, identify conditions and avoid unsupported reassurance.
Make calls to action accurate. “Start free trial” should begin a trial, not lead to a sales form. “Request pricing” should explain what information is needed and what happens next.
Check accessibility and comparison usability
Do not rely on colour alone to show the recommended plan or included features. Ensure the table can reflow on small screens and remain understandable to keyboard and assistive-technology users. The W3C guidance on reflow explains why content should work without two-dimensional scrolling at narrow viewport widths, with limited exceptions.
Use text labels for included, limited and unavailable states. Descriptive tooltips must also work with keyboard focus and should not contain information essential to the choice if it is difficult to access.
Limitations and trade-offs
Publishing price improves self-qualification, but a genuinely variable project may not have one honest figure. In that case, explain the pricing model, minimum scope or factors that determine a quotation rather than showing nothing.
Simple plans are easier to compare but may not reflect operational complexity. Complex packaging may protect margins but transfer effort to the buyer. Treat repeated pricing questions as evidence that the model or explanation needs attention.
Pricing page checklist
- State currency, billing period and unit.
- Include mandatory charges and material conditions.
- Explain who each plan fits.
- Show meaningful differences consistently.
- Define usage, seats and support terms.
- Disclose renewal, trial and cancellation basics.
- Avoid false urgency and preselected extras.
- Test mobile, keyboard and screen-reader use.
Frequently asked questions
Should a B2B company publish prices?
Publish them when the amount can be stated accurately. For variable work, publish the model and factors that determine scope so visitors can still assess fit.
Is “most popular” a useful plan label?
Only when supported by current evidence and helpful to the buyer. “Best for multi-team reporting” usually communicates fit more directly.
How much detail belongs in the comparison table?
Enough to distinguish the plans on important criteria. Move exhaustive feature inventories into accessible documentation and keep key limits visible.
Your useful next step
Ask someone outside the business to calculate the likely first-year cost for two realistic scenarios using only the page. Record every assumption they must make, then revise the relevant label, condition or example. Check that the result aligns with the product page message.