A SaaS comparison page outline for a specific use case

A two-person support team comparing AI tools needs to know whether every reply can require human approval. Checkmarks for knowledge bases, draft replies, and integrations leave that question unanswered.

Build your SaaS comparison page outline around one buyer’s job and the requirements that could rule out an option. Use six sections: buyer context, conditional recommendation, deciding requirements, shared workflow, adoption costs, and the next verification task. Attach evidence to each claim that carries the recommendation.

Define the buyer’s decision

Write a brief that names the buyer, job, alternatives, and deciding constraint. “Small businesses choosing support software” leaves too much unresolved. “Two support agents choosing a tool for drafting email replies, with mandatory approval before sending” gives the page a useful boundary.

In her positioning guide, April Dunford starts with what customers would do if your solution did not exist, then connects differentiated capabilities to value and the customers who care about it. Apply that sequence when choosing what to compare. The current manual process may deserve attention alongside a competing product. Read Dunford’s positioning guide.

Find evidence for the brief in buyer conversations, support questions, or relevant public discussions. Keep the person’s situation and original wording separate from your interpretation. One frustrated comment can suggest a question to investigate; it cannot establish how common the problem is.

Use FindVex’s pain-point evidence sheet to organize those observations before choosing the page’s criteria.

Choose a named competitor when buyers actually consider it. If you lack evidence that buyers compare the two products, mark the pairing as a hypothesis in your planning notes and investigate before writing the full page.

Outline six sections around the buyer’s questions

Replace these working headings with language specific to the products and task.

1. Buyer context and comparison scope

Name the products, plans, workflow, and team constraints. If your company sells one of the products, disclose that relationship near the beginning. State who falls outside the comparison, such as teams needing phone support when you evaluated only email.

2. When each option fits

Give a short, conditional recommendation near the top. Explain what favors each product and which unresolved fact could change your advice. Include keeping the current setup when it remains a reasonable option. Write this section after checking the evidence.

3. Requirements that decide the choice

Separate requirements that can disqualify a product from preferences that allow tradeoffs. Mandatory human approval might be a requirement; an extra reporting view might be a preference. Start with a handful of criteria and add more only when they change the decision.

4. The same task in both products

Walk through an identical task, from input to usable output. For an AI tool, include what happens when an answer is wrong, incomplete, or needs review. Show who checks it and what they must do before it reaches a customer.

5. Price and adoption tradeoffs

Compare the relevant plans under the same workload assumptions. Include billing cadence, seats, usage allowances, required add-ons, and migration work where they apply. Keep documented fees separate from estimates of setup effort. Any claim that one product costs less should specify the workload and exclusions.

6. The next verification task

End with a test the buyer can run: complete the shared task in both tools, check an uncertain integration, or confirm a plan restriction. Explain what result would change the recommendation.

Google’s review guidance recommends evaluating from the user’s perspective, explaining meaningful differences, and discussing benefits and drawbacks. When recommending something as best for a purpose, it calls for firsthand supporting evidence. See Google’s review guidance. If your comparison rests on documentation, make that scope clear and avoid implying hands-on testing.

Give every deciding claim an evidence record

Copy this record for each claim that could change the buyer’s choice:

Claim:
Why it matters to this buyer:
Product, plan, and version:
Source URL and relevant section:
Date checked:
Evidence basis: documentation / observed test / estimate / unresolved
What the source or test establishes:
Limits and exclusions:
Next verification step:
Owner and recheck date:

Match the evidence to the claim. A pricing page can establish a listed price and billing basis. Documentation can describe a supported workflow. Neither establishes how quickly your buyer will complete that workflow.

For usability or performance claims, record the input, settings, steps, evaluation criteria, and observed result. For AI output comparisons, use the same task set and define acceptable results before testing. Keep conclusions limited to the cases you observed; one successful answer cannot establish general accuracy.

Apply the same standard to both products. If you cannot find a capability in the documentation, record it as unresolved rather than unsupported. If it requires an add-on, state that condition beside the claim. Put supporting links and material qualifications next to the relevant statement in the finished page.

An unresolved requirement belongs in the recommendation, too. “Confirm whether this plan can enforce approval before evaluating its routing features” tells the reader what to do with the uncertainty.

Worked example: AI reply drafts for two support agents

The products, prices, and capabilities below are fictional. They illustrate how to build an outline; they are not software test results.

Suppose a founder is comparing Tool A and Tool B for two agents handling 1,000 email conversations per month. Every outgoing reply must receive human approval. The team already has a help desk and wants to keep its conversation history.

Assume Tool A drafts inside the existing help desk and requires approval before sending. It costs $90 per month for this workload and has limited routing controls. Tool B costs $60 per month and has more routing options, but requires moving conversations into its own inbox. Whether it can enforce approval is unresolved.

The page title could be “Tool A vs. Tool B for a two-person support team that reviews every AI reply.” Under the fictional assumptions, the opening recommendation would favor testing Tool A first because it meets the approval requirement and preserves the existing workflow. Tool B remains an option if enforceable approval is confirmed and the team accepts migration.

Keep the assumptions visible in the summary table:

Reserve the workflow section for the same exercise in both products: draft a reply to a billing question, inspect its supporting information, correct an error, and approve the message. Record actual observations when you test; leave timing and quality results blank until then.

For the unresolved approval requirement, write a test before writing a verdict. In a test inbox, configure the intended approval settings and attempt to send an AI reply without approval. Record the plan, user role, settings, and result. Check the documented restrictions as well. A single successful test supports only the configuration and path tested, so leave other relevant sending paths unresolved until checked.

Tool B’s assumed subscription price is $30 lower per month, or $360 over 12 months. That calculation excludes migration labor and any unlisted charges. The savings matter only if Tool B meets the mandatory approval requirement.

This gives the outline a clear decision sequence: verify Tool B’s approval controls, then compare the shared reply workflow. If Tool B fails the requirement, stop evaluating its other advantages for this use case. If it passes, investigate migration effort. Keep the current setup available while those questions remain open.

Make the comparison readable and keep AI visibility claims narrow

Use descriptive headings, explicit product names, and short explanations beside summary tables. Keep plan restrictions and other important qualifications in text, where readers can find them without interpreting a screenshot or checkmark.

Google says no special optimization or dedicated schema is needed for AI Overviews or AI Mode. To be eligible as a supporting link, a page must be indexed and eligible to appear in Google Search with a snippet. Eligibility does not guarantee inclusion. See Google’s guidance on AI features.

Treat the outline as a way to explain the buyer’s decision, without promising AI citations. Add related questions only when their answers help resolve that decision. A broad FAQ about every integration creates more claims to maintain and can bury the deciding issue.

Copy the comparison-page worksheet

Complete this brief before writing polished copy. Use the claim record above for the evidence behind each section.

Reader and job:
Products and plans being compared:
Current workaround and reason to reconsider it:
Requirement that could rule out each option:
Preferences the buyer can trade off:
Billing terms and workload assumptions:
Identical task to examine in both products:
Evidence records supporting the recommendation:
Option A fits when:
Option B fits when:
Keeping the current setup fits when:
Unresolved fact most likely to change the recommendation:
Reader's next verification task:

Before publication, ask someone who resembles the intended buyer to read the outline and explain which option they would investigate, why, and what remains unclear. Use the response to check comprehension. It does not establish conversion lift.

After publication, choose an outcome to observe, such as completion of the comparison exercise or a relevant activation step after a trial begins. Record the page version and traffic source. A change in results can suggest where to investigate, but cannot by itself establish that the outline caused it.

Finish one outline and verify its deciding claim

Choose one use case, complete the worksheet, and arrange the answers under the six page sections. Identify the fact most likely to change the recommendation and verify it first. If it remains unresolved, state the limit and give the reader a way to check it.

Assign someone to recheck prices, plan restrictions, and the claims carrying the recommendation. The finished outline should make the buyer’s next action clear even before you write the full page.