Start the card with that question. Put a short answer beside the evidence, then add the question you need to ask next. A missing feature in a listing is an unanswered question, not proof that the product lacks it.
The filled example below shows how to keep that distinction useful during a conversation. It uses two fictional booking tools and three common buyer concerns. There are no real vendor claims or sales results.

A filled battlecard you can use as a model
This is an internal practice card for fictional CedarDesk, compared with fictional MapleSlot. These authored source cards are the entire evidence set:
- S1 — CedarDesk package brief: one team calendar and an approval step. Price, plan version and observation date: TO CONFIRM.
- S2 — MapleSlot listing: one calendar and a shareable booking link. Approval behavior, price, plan version and observation date: TO CONFIRM.
These descriptions have not been tested in either product. Before using a real card with a customer, check the actual plans, current sources and approved wording.
“Does MapleSlot handle approval?”
Response: “The CedarDesk brief includes an approval step. The MapleSlot listing we have does not specify approval behavior, so we need to check that before comparing the two.”
Next question: “Who needs to approve a booking, and when should that happen?”
Internal check: Verify the actual MapleSlot plan and its approval behavior. Confirm that CedarDesk's documented step fits the buyer's required sequence. Sources: S1 and S2.
This answer gives the rep something useful to say now. It also avoids turning “not specified” into “not available.”
“Is MapleSlot cheaper?”
Response: “We do not have comparable prices yet. Let's compare the actual plans that cover your required booking and approval steps.”
Next question: “Which plan are you considering, and what must be included?”
Internal check: Obtain current pricing for both relevant plans and confirm the same scope and pricing basis. Do not fill the gap with an estimate. Sources: S1 and S2, neither of which supplies a price.
The card cannot answer the price question with this evidence. Showing that limit is more useful than a confident answer the teammate will have to retract.
“We only need a simple booking link.”
Response: “The MapleSlot listing includes a shareable booking link. If that is the full requirement, let's check whether it covers the workflow you need before adding an approval step you may not use.”
Next question: “Can people book directly, or does anyone need to review the booking first?”
Internal check: Confirm the actual link behavior and requirements. S1 does not specify CedarDesk's booking-link behavior; leave that unknown too. Source: S2 for the listed link.
A good card can help a rep recognize when a distinction is irrelevant. It does not need to force CedarDesk into every answer.
Keep customer wording separate from the internal check
The response should be short enough to say aloud. The internal check can hold source details, missing information and the owner of the next verification step.
That separation is consistent with the short, focused conversation reference described in Salesforce's guide to sales battlecards. The fictional facts above come only from S1 and S2; the guide does not establish anything about either tool.
Here is a weak draft:
“MapleSlot cannot handle approvals. CedarDesk is the better choice.”
Here is the revision:
“The CedarDesk brief includes an approval step. MapleSlot's listing does not specify its approval behavior. What approval sequence do you need?”
The revision preserves the supported distinction and opens a useful discussion. It removes both the unsupported negative claim and the overall verdict.
A blank sales battlecard template
Use one card for one named alternative and a small set of buyer concerns. Add another concern when it helps someone answer a different question, rather than squeezing the whole product catalog onto the page.
INTERNAL SALES BATTLECARD
Our offering and actual plan:
Alternative and actual plan:
Intended conversation:
Card owner:
Last checked:
Next review trigger:
BUYER CONCERN
The question in the buyer's words:
SUPPORTED RESPONSE
One or two sentences appropriate to say to the buyer:
NEXT QUESTION
What do we need to understand about this buyer's task?
EVIDENCE
Source ID or link:
Exact supported fact:
Source date and applicable plan/version:
INTERNAL CHECK
What is unknown or needs current verification?
Who will check it?
What should the rep avoid claiming?
Use a real owner and review date when they are known. Until then, label them TO CONFIRM. A date printed on a card should describe a check someone actually performed.
For the approval example, a review trigger could be a new package brief or a changed approval requirement. An old observation should not silently become a current product claim.
A complete prompt for turning your evidence into a card
Paste your permitted source notes into the prompt. Remove confidential customer information before using a tool or sharing a reading copy.
Create a concise internal sales battlecard from the source notes below.
Our offering and plan:
[actual offering and plan, or TO CONFIRM]
Named alternative and plan:
[actual alternative and plan, or TO CONFIRM]
Buyer concerns:
[the actual questions this card should help answer]
Permitted source notes:
[Give each source an ID. Include its exact supported facts,
URL or reference, observation date, and applicable plan/version.
Mark missing details TO CONFIRM.]
For each concern, write:
1. A short response appropriate to say to the buyer.
2. A clarifying question about the buyer's actual task.
3. The exact source IDs supporting the response.
4. A separate internal check naming missing information
and any claim we must avoid.
Keep customer wording separate from internal notes.
Treat an omitted feature as unknown, not absent.
Do not invent prices, feature tests, customer stories, market share,
win rates, vendor weaknesses or overall winners.
If neither source answers a question, say so.
If the buyer may not need our distinguishing feature, reflect that
instead of forcing a favorable conclusion.
Include owner, last-checked date and next-review trigger.
Leave unknown values TO CONFIRM. Do not imply that verification,
approval, sending or a sales call has happened.
Return one complete self-contained HTML card with inline CSS and JavaScript.
Use a buyer-concern selector that keeps each supported response, next
question, source IDs and separate internal check together. Preserve the
source notes and all TO CONFIRM values; do not fabricate vendor facts.
Include a short unresolved-check list and blank temporary review notes.
Keep typed notes while switching concerns and confirm before reset.
Use system fonts at least 16px, labeled native keyboard-accessible controls,
visible focus and a readable 360px layout without horizontal scrolling.
Display user text safely as text. Load no external dependencies and make
no storage, export, sending, approval or other fake-action claims.
Read the response against each cited source. A source ID beside a sentence does not make the sentence supported: the wording still has to stay within what that source actually says.
Try the card with a teammate
Ask a teammate to find the answer to the approval question, then the price question. Watch whether they can distinguish what they may say from what still needs checking.
In a NOS HTML reading copy, the concern selector can keep the response, next question and internal check together. If “Internal check” is easy to mistake for customer wording, edit that static label to “Check before making this claim,” then try the same lookup again.
Carry the clearer wording back into the maintained, approved sales material. For confidential notes, use your team's approved private route. The useful result is a teammate who can give a supported answer and knows exactly what remains open.