Date every comparison claim and its source
Compare the same buyer task using dated primary sources, version or plan context and a named reviewer for each row. Keep an unverified export unknown instead of declaring it absent. The comparison becomes useful through its evidence and limits; the fictional products below establish the recording method rather than actual vendor differences.
Worked example — illustrative data.
| Criterion | Product / version / plan | Checked | Specific source | Limitation | Review owner | Next review |
|---|---|---|---|---|---|---|
| Approval stages | Fictional A v0.1 / Team | 2026-11-04, example review | Authored sample A-01 below | One stage in this specimen | Product reviewer role | 2026-12-04, example target |
| Export format | Fictional B v0.1 / Team | Not verified | Provider export URL and dated passage still needed | Unknown does not mean absent | Technical reviewer role | 2026-12-04, example target |
| Setup task | Both fictional v0.1 concepts | Not run | Equivalent task log still needed | No performance winner | Research owner role | Set after task access |
Sample A-01 is the authored statement: “The fictional Team v0.1 concept supports one approval stage.” It is not vendor documentation. The example dates show recordkeeping; actual platform claims need their own exact source URL, dated passage and version/plan context.
Write the buyer’s evaluation task before choosing rows. Use primary product documentation for material feature and commercial claims, then run equivalent tasks only when authorized access exists. Separate native capability from add-ons and custom work. Include a fair fit statement for the alternative when evidence supports it. Keep source URLs, checked date and the next review date beside the working comparison so updates do not depend on memory.
Make each comparison row falsifiable
Write the criterion as an observable task or supported limit, then record the product version, plan, source and review date. For the fictional export row, leave the value unverified until the provider or an authorized task demonstrates it. Use the same requirement for both products. A checkmark without a condition can hide exactly the difference the buyer needs.
Gradual rollout and plan limits can change a comparison
A feature may differ by plan or be rolled out gradually. A screenshot from one account does not establish universal availability. Preserve the account context and qualify the public statement accordingly.
Publish a narrower sourced comparison instead of filling unknown cells with confident conclusions. This specimen provides the structure; it does not establish facts about any named competitor.
Should an unknown competitor feature be marked absent?
No. Unknown means the evidence is missing or inconclusive. State the source needed and its review owner. Only a supported current finding can establish a limitation, and a staged rollout may require a narrower conclusion.
Continue with Guides for stores, software teams and local businesses, SaaS SEO services and How to design a SaaS pricing page for buyers comparing plans.