# A sales battlecard template that shows its own age

> Build a sales battlecard with a full template, filled example, discovery questions and objection responses using Browse AI, Notion, Slack and Zoom evidence.


“Their plan already includes that.”

If a buyer says that halfway through your demo, an outdated comparison slide puts your rep on the defensive. The next few minutes become a debate about whose information is correct, while the buyer’s actual problem waits.

For a small SaaS team, that is an expensive way to discover a competitor changed its offer. The founder cannot join every call. The product marketer cannot rewrite every deck before lunch. Sales needs something better than an old feature grid and a warning to double-check it.

A useful battlecard gives the rep a route through the deal: what to ask, where the competitor is credible, which difference matters, how to prove it and what to do when the buyer pushes back. Each competitive claim also needs its own evidence and date. A fresh cover cannot rescue an old claim.

Below is a complete sales battlecard template, a filled Browse AI example and worked examples using Notion, Slack and Zoom. You will see the exact wording to retire, the questions to ask instead and the checks that turn a possible advantage into a defensible one.

[Jump to the battlecard template](#the-sales-battlecard-template), or start with the [filled Browse AI example](#a-filled-battlecard-browse-ai-and-amazon-s3).

## Give the card one buyer and one decision

A sales battlecard is a short, internal guide to a specific competitive conversation. Its job is to help someone decide what to say and show next. A product catalogue rarely does that.

Choose a competitor that appears in real deals, then name the buying situation. “Against Notion” is too broad. “A support team comparing a dedicated search tool with the AI features included in Notion Business” gives the card a buyer, an existing alternative and a reason to care.

Start from your recent calls, objection emails and win-loss notes. Write down what buyers actually compare, including their current process. Staying with a spreadsheet or an existing subscription can be the strongest competitor in the deal.

Use one core card per competitor, with short use-case sections when the conversation genuinely changes. Separate cards make sense when the buyer, evaluation criteria and proof are different. Creating a card for every feature quickly produces a library nobody maintains.

Keep two layers:

- **The call sheet:** buyer context, discovery questions, credible strengths, proven differences, objection responses and next step. A rep should be able to skim it before a meeting.
- **The evidence notes:** exact sources, plan restrictions, test results, dates, owners and withdrawn wording. These support the call sheet without turning it into a research report.

A founder can own both layers at first. As the team grows, PMM can own the wording, a product specialist can verify technical claims and the deal owner can supply buyer context. Put names against the work; “sales and marketing” is not an approval process.

## The sales battlecard template

[Download the complete Markdown template](/downloads/sales-battlecard-template.en.md) and the [filled Browse AI example](/downloads/sales-battlecard-browse-ai-example.en.md). Prefer Word? Get the [editable template](/downloads/sales-battlecard-template.en.docx) and [filled example](/downloads/sales-battlecard-browse-ai-example.en.docx). Copy them into your wiki or CRM. The questions below are prompts to answer, not copy to show a prospect.

### Call sheet: what the rep needs in the meeting

| Section | What to put in it | Quality check |
| --- | --- | --- |
| Buyer and trigger | Role, job to be done, current tool and reason for evaluating now. | Can you explain why this deal exists without describing your product? |
| Competitor’s credible strengths | The reasons a sensible buyer would choose them. | Would the buyer recognize a fair description? |
| Fit and qualification | Conditions that make your offer worth evaluating; conditions that make it a poor fit. | Is there an answer that would make you stop pushing? |
| Discovery | A question, a follow-up and the decision each answer changes. | Does the question uncover a requirement rather than bait an attack? |
| Proven differences | Buyer requirement → verified difference → practical consequence → proof. | Is evidence available for both sides of the comparison? |
| Objection response | Acknowledge the valid point, clarify the requirement, show proof and agree a next step. | Could a rep say it naturally in a few sentences? |
| Demo or evaluation | The buyer’s task, test conditions, pass criteria and owner. | Could both vendors attempt the same test? |
| Commercial and switching checks | Relevant plan, usage, add-ons, migration work, permissions and contract timing. | Are you comparing complete workable offers? |
| Next step | A named person, deliverable and agreed date. | Does it resolve the main open question? |
| Do not say | Withdrawn or unverified lines, with replacement guidance. | Can an old slide be recognized and corrected? |

A differentiator should survive the question “so what?” For example, “supports S3” says little to a buyer whose current tool already supports S3. “Your operations lead can complete this export without waiting for an AWS administrator” could matter, but only after you have demonstrated that workflow and checked the competitor’s actual requirements.

Use this working structure for each important comparison:

```text
BUYER REQUIREMENT:
Why it matters in this deal:
Competitor's verified capability and limit:
Our verified capability and limit:
Meaningful difference, if any:
Evidence or repeatable demo:
Question to ask:
Approved wording:
When this difference does not matter:
Next step:
```

### Evidence notes: what makes the wording safe to use

Give material claims stable identifiers such as S3-01. Reference those IDs beside the relevant call-sheet lines, so changing a source does not mean searching every sentence manually.

```text
CLAIM ID:
Exact claim:
Scope: product / plan / region / release stage / buyer setup
Competitor source URL, excerpt and capture:
Our source URL or test evidence:
Observed change date, if known:
Last verified date:
Verified by:
Evidence level: vendor-documented / tested / buyer-reported / unverified
Status: usable / check before use / withdrawn
Approved wording and necessary qualification:
What the evidence does not establish:
Next review date or event:
Affected cards, decks, snippets and active deals:

CHANGE LOG
Date | Claim ID | Old wording | Replacement | Reason | Owner
```

**Evidence level and status answer different questions.** “Vendor-documented” describes the source. “Usable” means the owner has approved a specific sentence within that source’s limits. A vendor-documented integration can be usable evidence that the integration exists while its performance in your buyer’s environment remains untested.

Record buyer-reported information as the buyer’s experience, with permission and scope. One difficult migration does not establish that every customer has the same experience. Keep confidential deal notes out of customer-facing materials.

Use **check before use** when a necessary fact is missing. Use **withdrawn** when the evidence contradicts the line or its scope is misleading. Neither state needs to freeze the whole card: the rep can still ask the discovery question and use other verified claims.

![A brass date stamp above individual claim cards, illustrating claim-level verification.](/img/blog/battlecard-claim-dates.png)

## A filled battlecard: Browse AI and Amazon S3

Our [Browse AI record](/companies/browse/) highlighted data-destination support. We followed that signal to Browse AI’s current [Amazon S3 page](https://www.browse.ai/integrations/amazon-s3) and [setup guide](https://help.browse.ai/en/articles/10715592-aws-s3-integration-guide). They provide a much stronger basis for a battlecard than a feature checkmark.

Browse AI documents CSV and JSON exports, S3 availability on all plans at no additional integration cost and regular robot-run credit usage. Its setup guide requires an AWS account with permission to create CloudFormation stacks and IAM roles, plus the destination bucket. Those are concrete facts to work with.

The following is a **worked card for a hypothetical competing data-extraction vendor**. The buyer scenario and proposed sales wording are illustrative. We have not tested either product in a customer environment and are not asserting that the hypothetical seller has an advantage.

### Buyer and fit

**Situation:** an operations lead wants recurring web data delivered into the company’s own S3 bucket. An AWS administrator controls permissions. The buyer is evaluating whether to use Browse AI or another extraction tool.

**Browse AI’s credible strength:** it already documents the required export destination and file formats. A buyer who wants data in S3 has a reason to shortlist it. Do not dismiss that strength as “just an integration.”

**Qualification:** find out which part of the workflow is difficult. Extracting the right fields, approving AWS access, delivering a predictable file or recovering from a failed run are separate jobs. Compete on the one the buyer actually needs help with.

**Poor-fit condition for a replacement:** if Browse AI already meets the extraction, access and downstream-processing requirements at acceptable cost, an integration checkbox is a weak reason to switch. Establish a real unsolved problem before proposing a migration.

### Discovery that leads somewhere

| Ask | Follow up | What the answer changes |
| --- | --- | --- |
| “What will consume the exported file?” | “Does it expect CSV or JSON, specific field names or a particular folder structure?” | Defines the sample output both vendors must produce. |
| “Who can approve the AWS connection?” | “Can they create the required IAM role and CloudFormation stack?” | Identifies an implementation dependency and the person to involve. |
| “How current must the data be?” | “What happens downstream if an export is late or duplicated?” | Sets an acceptance test for delivery and failure handling. |
| “Who owns this after setup?” | “Who gets notified and restores the process if it breaks?” | Opens a meaningful discussion about ongoing work. |

These questions do not imply that Browse AI fails any of the requirements. They establish what you need to verify before comparing the offers.

### Claim record and objection response

**S3-01 — usable, vendor-documented, checked September 10, 2026:** Browse AI documents an S3 integration with CSV and JSON exports. Its FAQ says the integration is included across its plans; normal robot-run credits still apply. Its guide describes the AWS permissions required for setup.

**Withdraw this hypothetical line:** “Browse AI cannot export to your own cloud storage.”

**Also avoid:** “S3 export is free, so there is no usage cost.” An integration fee and the cost of running the extraction are different things.

**Buyer objection:** “Browse AI already sends data to S3.”

**Proposed response:** “Yes, it documents that integration. Let’s compare the output your downstream process needs and who will maintain it. If both tools meet those requirements, the decision should come down to the remaining extraction, operating and commercial differences.”

That response acknowledges the buyer’s correct information. It also gives the rep a useful next step without inventing a feature gap.

### A fair proof exercise

Agree the requirements with the buyer before the demo. Use the same source page and required fields for both vendors, with authorization to extract the data and a nonproduction destination.

1. **Produce the sample.** Export the agreed fields in the buyer’s chosen format. Check completeness, field names and how missing values appear.
2. **Inspect delivery.** Confirm the file reaches the intended bucket and prefix. Check that the downstream process can consume the actual output.
3. **Review access.** Have the AWS owner inspect the permissions and setup steps. Record the work required from the buyer, rather than guessing from “no code” marketing.
4. **Test repeat runs.** With a controlled test source, change a value and rerun. Record how updates, file naming and duplicates behave.
5. **Review recovery and cost.** Ask how failures are surfaced and recovered, then capture actual usage for the test. Identify any support or recurring operating work that remains.

The pass criteria are the buyer’s required output, permitted access and agreed delivery behavior. We are proposing this test, not reporting a result. Put the actual evidence into the card when it exists.

**Next step:** the deal owner sends the sample specification; the buyer’s AWS administrator confirms access requirements; the product specialist records the two outputs and unresolved questions. Agree a date with those people rather than adding an arbitrary deadline to the card.

## Three more battlecard examples worth studying

The following examples use vendor documentation checked on September 10, 2026. They illustrate different mistakes a card can make. Historical announcements are dated explicitly; these are not presented as four product changes discovered this week. The proposed bad lines and rep responses are teaching examples, not quotations from actual sales teams.

### Notion: compare the current bundle, not an old add-on story

A card saying “Notion AI always costs extra” would miss a material packaging change. In its [May 13, 2025 release](https://www.notion.com/releases/2025-05-13), Notion announced that its Business and Enterprise plans included Notion AI, naming enterprise search, research mode and AI meeting notes.

The [current pricing page](https://www.notion.com/pricing) lists Notion Agent, AI Meeting Notes and Enterprise Search under Business. It separately describes Custom Agents using Notion credits. An old release saying “unlimited” is therefore a poor substitute for checking the exact current capability the buyer wants.

**Buyer situation:** a team already pays for Notion and is evaluating another AI search or meeting tool. The buyer’s first question is likely to be whether the existing subscription already does enough.

| Card element | Useful entry |
| --- | --- |
| Withdraw | “Every Notion AI feature is a separate add-on.” |
| Avoid the opposite overclaim | “All AI work in Notion is included without usage charges.” |
| Ask first | “Which Notion plan are you on, and which exact job are you comparing: meeting notes, search or autonomous tasks?” |
| Follow up | “Which information sources, permissions and outputs must that job support?” |
| Proposed response | “Some of the capabilities you need may already be included. Let’s test the exact workflow before you pay for another tool.” |
| Proof | Run the same permitted question set or meeting task against the required sources. Check answer quality, citations, access controls and missing information. |

**What changes the sales approach:** if the included feature meets the requirement, a standalone competitor needs a demonstrable reason for another purchase. If it falls short, name the failed requirement and show your result. “We are more specialized” is a description; a reproducible difference in the buyer’s task is evidence.

**Commercial check:** compare the buyer’s actual current plan with the complete alternative. Record required upgrades, seats, usage-based features and deployment work. Do not put a list-price comparison in the card while leaving the paid prerequisite out.

### Slack: separate history access from permanent deletion

“Slack deletes everything after 90 days” compresses several different rules into a misleading line.

Slack’s [free-workspace documentation](https://slack.com/intl/en-ie/help/articles/115002422943-Usage-limits-for-free-workspaces) describes access to the most recent 90 days of messages and files. Its [retention documentation](https://slack.com/help/articles/203457187-Customize-data-retention-in-Slack) allows free-workspace owners to choose retention of 90 days or one year. It also documents permanent deletion and relevant exceptions, including certain Enterprise-sponsored Slack Connect messages. Paid-plan settings differ.

**Buyer situation:** a team is evaluating a collaboration tool because people cannot retrieve older decisions. The underlying need might be searchable history, a retention policy, export access or a legal requirement. Those should not become one checkbox called “history.”

| Card element | Useful entry |
| --- | --- |
| Withdraw | “All Slack messages are deleted after 90 days.” |
| Ask first | “Are the missing messages hidden by your plan’s history limit, or deleted under the workspace’s retention setting?” |
| Follow up | “How far back must staff search, and what does your organization require you to retain or delete?” |
| Proposed response | “Let’s check your plan and retention settings separately. That will tell us whether you need different access, a policy change or another product.” |
| Proof | With authorized test data, verify retrieval, export permissions and retention behavior for the relevant plan. Document any exceptions. |
| Do not promise | Recovery of permanently deleted data or compliance with an unverified legal requirement. |

**What changes the sales approach:** upgrading the existing service may solve an access problem. Moving to another tool may introduce migration work without restoring deleted material. Your card should help the rep identify that possibility before recommending a switch.

**Migration check:** establish which messages and files the buyer can actually export, who can authorize it and what the destination can import. Bring in a security or legal owner when policy interpretation is required. A sales comparison is not a compliance assessment.

### Zoom: qualify the host’s license, not the company’s account label

A card can contain the right number and still apply it to the wrong customer.

Zoom’s [meeting time-limit documentation](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0059213) says almost all meetings hosted by Basic users are limited to 40 minutes, including Basic users inside paid accounts. Assigned paid licenses generally permit meetings up to 30 hours. The documentation also describes exceptions, including certain Zoom Room participation and idle-meeting conditions.

**Buyer situation:** a company says “we pay for Zoom,” but a particular host’s calls still end early. The account’s paid status alone does not establish that host’s entitlement.

| Card element | Useful entry |
| --- | --- |
| Withdraw | “Every user on a paid Zoom account can host long meetings.” |
| Also avoid | “Zoom meetings are limited to 40 minutes.” |
| Ask first | “What license is assigned to the person hosting the affected meeting?” |
| Follow up | “Who regularly hosts, which meeting types do they run and what duration do they need?” |
| Proposed response | “Check the host’s assigned license first. Then we can compare the licenses and meeting conditions your team actually needs.” |
| Proof | Have an authorized admin verify license assignments and compare a representative meeting setup against the documented limits. |

**What changes the sales approach:** correcting an assignment might solve the problem. If a wider licensing or workflow issue remains, compare the full host population and necessary capabilities. Avoid presenting an administration problem as proof that the competitor lacks a feature.

These examples cover different failure modes: an integration falsely described as absent, an outdated bundle, a retention rule stripped of its conditions and an entitlement attached to the wrong user. A good card makes the relevant distinction easy to remember in a call.

## Build objection responses around a decision

An objection section needs more than “we are easier to use” or “focus on value.” Give the rep a response that acknowledges reality and moves toward evidence.

Use four steps: **acknowledge → clarify → prove → agree the next step**. The next step should resolve the buyer’s uncertainty, rather than force another generic demo.

| Buyer says | Useful response pattern | Evidence needed |
| --- | --- | --- |
| “We already have that.” | “You may. Which part still creates work? Let’s test that part before discussing a replacement.” | Current capability, buyer’s unmet requirement and the result of a fair comparison. |
| “They are cheaper.” | “Which plan and workload are you comparing? Let’s include the required seats, usage and setup on both sides.” | Comparable offers and buyer-specific usage assumptions. |
| “Switching is too much work.” | “Which part is hardest to move? We should establish what can migrate and who would own it.” | Export/import limits, permission requirements, implementation work and timing. |
| “They are good enough.” | “If the current setup meets the requirement, a switch may not be justified. What problem prompted the evaluation?” | A real unresolved need, not a feature the seller happens to prefer. |

Write the corresponding stop condition. If the buyer cannot identify an unmet need and the current tool meets the agreed test, stop manufacturing a reason to change. Record why the opportunity was not qualified. That feedback is more useful than a battlecard full of imaginary advantages.

For a founder-led team, rehearse the card on one real objection with a colleague. Have them challenge the source, the plan and the “so what?” If the answer collapses into a long explanation, shorten the claim or replace it with a question.

## Keep the card useful after the first week

Review active-deal claims first. Use a claim-level change queue so a new integration or plan revision points to the sentence it affects. Our [feature-launch tracking guide](/blog/competitor-feature-launch-tracking/) explains how release notes, product pages and documentation contribute different parts of that check.

**Signal → Motive → Move** helps separate the observation from the interpretation. Browse AI documents an S3 export; serving more data workflows is a possible motive; verifying the buyer’s actual export task is the move. The motive stays a hypothesis unless further evidence supports it. It is not a line for sales to present as fact.

Use review rules your small team can actually maintain:

- **Before the next relevant call:** withdraw a contradicted claim, check a disputed entitlement or resolve a material pricing uncertainty.
- **In the weekly review:** inspect changes affecting active competitors and decide which claims need a new test or wording.
- **Before an important evaluation or proposal:** recheck the source and the buyer’s exact plan, region and configuration. A weekly digest cannot approve a deal-specific promise.
- **At the card’s scheduled review:** remove unused sections, add recurring objections and confirm ownership. Set frequency according to how quickly those claims change.

Tell sales exactly what changed: “S3-01: stop using the no-S3-export line. Browse AI documents the integration across plans. Use the output-and-maintenance discovery questions; our comparative test is still open.” Link the revised card and correct active decks, email snippets and deal notes. Keep the retired wording in the change log so someone does not resurrect it from an old presentation.

Measure whether the card is helping. Record which objections recur, which proof requests remain unanswered and which claims reps challenge. Check whether the card was used in the relevant deals before interpreting win-rate changes. A small sample or a changed deal mix cannot establish that the card caused an improvement.

Before calling a card ready, ask one rep to find the buyer’s question, a defensible answer, its source and the next step without assistance. If they cannot, simplify the call sheet. Keep the detail in the evidence notes.

## When Competitor Tracker & Co. fits

Competitor Tracker & Co. fits when the team has somewhere to keep battlecards but public competitor changes keep slipping past the people responsible for them:

- “Tell us when an integration gap might have closed.”
- “Show us the plan change before we reuse an old comparison.”
- “Give us a short review queue with the changed page and evidence.”
- “Help our founder and PMM spend review time on the claims that moved.”

Our pack of AI agents watches public competitor pages, filters routine edits and files the Monday dossier. Your team connects those observations to the card, checks the relevant claim and approves the wording. The [weekly dossier template](/blog/weekly-competitor-dossier-template/) gives that review a place to start.

Public monitoring cannot supply private win-loss interviews, run a buyer’s product evaluation or approve security and legal claims. Keep those inputs alongside the public sources, with the right owner. API and MCP access let your own agent retrieve competitor data; the final sales promise still needs someone accountable for it.

The payoff is practical: when the buyer says “their plan already includes that,” your rep can acknowledge it, ask the right follow-up and keep the conversation on the decision.

[See a sample dossier](/demo/) or [start a case](/#engage) with Competitor Tracker & Co.

— C. T. Lucky


---

Source: https://competitortracker.io/blog/battlecards-go-stale-dossiers-do-not/
Updated: 2026-09-10