How this works

Turn verified product facts into a comparison page for prospective buyers. Keep dated evidence behind every feature and pricing claim. Comparison pages age quickly when plans, limits, and billing conditions change. A useful page compares the same buyer requirement across comparable offerings and makes unknowns visible instead of converting missing documentation into a negative claim.

Maintain a dated feature matrix behind the page. Research and copy generation are separate stages: first establish what each plan actually includes, then explain the implications for the intended buyer. Use an available CMS draft interface when configured; otherwise deliver a Markdown page and import table.

Before you start

Prepare the inputs

own_offer

Required

Plan record

Include tier, billing interval, limits, and evidence date.

comparison_offers

Required

List of offer records

Avoid comparing a free tier with an enterprise quote without saying so.

criteria

Required

Named evaluation rows

Each row must have a testable definition.

source_material

Required

Dated documents or snapshots

Retain the passage for each feature or price.

page_brief

Required

Audience and desired action

Do not claim universal superiority.

Implementation, step by step

1. 01

   Define fair comparison units

   • Translate buyer questions into rows such as included seats, export availability, or support hours.
   • Write the conditions under which each offer is compared and identify any incompatible units.

   Checkpoint: An agreed comparison matrix schema.

2. 02

   Collect current observations

   • Read product documentation and pricing conditions for the selected tiers.
   • Record retrieval dates and retain conflicting pages instead of silently selecting the cheaper figure.

   Checkpoint: Dated evidence attached to every populated row.

3. 03

   Normalize the facts

   • Convert billing periods and currencies only when the conversion assumptions are explicitly supplied.
   • Keep unknown, unavailable, not included, and optional add-on as different states.

   Checkpoint: Comparable values with explicit exceptions.

4. 04

   Draft the buyer narrative

   • Explain which trade-offs matter for the chosen use case using the verified matrix.
   • Separate factual differences from editorial interpretation and avoid unsupported claims about competitor performance.

   Checkpoint: Page draft whose substantive claims link internally to matrix rows.

5. 05

   Prepare the publishing package

   • Create headings, a readable table, limitations, and an update date in the existing page format.
   • Save as a CMS draft if authorized and available, or provide files for manual import.

   Checkpoint: An editable draft and source ledger.

6. 06

   Review and schedule rechecks

   • Have an editor verify prices, feature wording, and any unsupported negative implication.
   • Set a review trigger for plan changes and retain the exact approved draft version.

   Checkpoint: Approved content candidate with an owner and next review date.

Decisions along the way

What you will produce

Check the result

• Check every table cell against a dated source.
• Verify monthly versus annual billing and per-seat versus account pricing.
• Look for blanks converted into unsupported absence claims.
• Read the page from the intended buyer's perspective to confirm like-for-like scope.

When something goes wrong

A worked example

SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT

Run a small pilot

Keep the scope clear

• Competitor documentation supplies facts, not permission to copy its writing.
• Creating a CMS draft does not authorize publishing or changing live pricing claims.