Sales Battle Card Template: 12 Fields

Quick answer

A prospect-specific sales battle card is a short, source-linked decision aid for one active buying motion. Fill 12 fields: account scope, business problem, desired outcome, buying stage, buying group, decision criteria, current approach, real alternatives, approved proof, gaps and risks, evidence-safe objection responses, and the next action with owner and date.

Label every entry VERIFIED, REPORTED, HYPOTHESIS, UNKNOWN, or PROHIBITED. Link the source and observation date, record who may approve the claim, and expire stale facts. A battle card should help a seller ask better questions—not invent urgency, attack a competitor, expose confidential information, or send a message without review.

A battle card is a decision aid, not a competitor dossier

Generic cards usually collapse product marketing, anecdotes, old pricing, and a few objection scripts into one page. A prospect-specific card starts with the buyer’s actual decision and only includes alternatives that the buyer has named or that a qualified owner has deliberately introduced. Its job is to expose what is known, what remains unknown, and which claim can be used safely in this conversation.

Keep facts, interpretations, and recommendations separate

“The prospect requires EU data residency” can be a verified requirement linked to an approved security questionnaire. “The incumbent cannot meet it” is a separate competitor claim that needs current, comparable evidence. “Lead with our residency controls” is a recommendation that still needs product and account-owner approval. Mixing these sentences hides the weakest link.

Research only what the team is allowed to use

Prefer the prospect’s own statements, signed or approved records, official company publications, regulator filings, current product documentation, approved internal proof, and attributable public sources. Do not use leaked decks, private conversations outside their purpose, scraped personal data, unsupported reviews, invented usage, or confidential information carried from a former employer or another customer.

Five evidence states for every field

Evidence labels that prevent a polished card from overstating certainty
State	Meaning	May a seller state it?	Required handling
VERIFIED	Supported by a current, attributable source suitable for this purpose.	Yes, within the exact scope and qualifications of the source.	Link source, observation date, excerpt or field, owner, and expiry.
REPORTED	Stated by the prospect or an authorized participant but not independently confirmed.	Attribute it: “You told us…”; do not convert it into an objective fact.	Record speaker, channel, date, scope, consent/permission, and confirmation need.
HYPOTHESIS	A reasoned possibility that can guide discovery.	Only as a question, never as a diagnosis or assertion.	Show reasoning, contrary evidence, sensitivity, and the question that would test it.
UNKNOWN	Relevant information is absent, conflicting, stale, or inaccessible.	No.	Name the missing evidence and owner; do not fill the gap with model inference.
PROHIBITED	Information or a claim is not permitted, reliable, relevant, or safe to use.	No.	Suppress from prompts and outputs; record policy reason and escalation route.

12 fields for one prospect-specific sales battle card

Complete each field against the same opportunity cutoff. Copyable blocks include the field definition, evidence test, and acceptance condition so the output can be reviewed instead of merely read.

Prospect identity, opportunity, and scope

Name the legal account or business unit, opportunity ID, region, product/workload in scope, seller, stage, currency, preparation cutoff, and intended meeting or decision. Distinguish a parent company from the actual buyer and a new purchase from renewal or expansion.

FIELD Name the legal account or business unit, opportunity ID, region, product/workload in scope, seller, stage, currency, preparation cutoff, and intended meeting or decision. Distinguish a parent company from the actual buyer and a new purchase from renewal or expansion. EVIDENCE Link the governing CRM record and account hierarchy, note conflicts or duplicates, and show access limitations. Public company research may support context, but it does not override the live opportunity. ACCEPTANCE A reviewer can identify exactly one buying motion and cutoff. If identity, ownership, or scope is ambiguous, hold recommendations and resolve the record first.

Current business problem and use case

Describe the operational problem in the prospect’s language: affected team, current workflow, trigger, frequency, consequence, constraints, and why it matters now. Avoid generic industry pain pasted from a persona.

FIELD Describe the operational problem in the prospect’s language: affected team, current workflow, trigger, frequency, consequence, constraints, and why it matters now. Avoid generic industry pain pasted from a persona. EVIDENCE Prefer an attributable discovery note, transcript segment, approved brief, support record, or buyer document. Separate the reported symptom from the team’s interpretation of root cause. ACCEPTANCE The seller can quote or accurately paraphrase the buyer and knows what remains a hypothesis. Sensitive details are minimized, access-controlled, and used only for the stated sales purpose.

Desired outcome and success measure

Record the change the prospect wants, the metric or observable condition, baseline if known, target or range, measurement owner, time horizon, and what would count as failure. Do not invent an ROI percentage to make the case look complete.

FIELD Record the change the prospect wants, the metric or observable condition, baseline if known, target or range, measurement owner, time horizon, and what would count as failure. Do not invent an ROI percentage to make the case look complete. EVIDENCE Use buyer-confirmed objectives, an approved mutual plan, or an attributable internal calculation with inputs and assumptions. Label estimates and scenarios clearly. ACCEPTANCE Every number has units, period, source, assumptions, and owner. A recommendation does not promise that OpenMax will cause the target; qualified specialists review financial or performance claims.

Buying stage and next decision milestone

State the current buyer-verified stage, completed exit evidence, next decision milestone, expected date, dependencies, and stop/no-decision conditions. CRM stage alone may reflect seller process rather than buyer progress.

FIELD State the current buyer-verified stage, completed exit evidence, next decision milestone, expected date, dependencies, and stop/no-decision conditions. CRM stage alone may reflect seller process rather than buyer progress. EVIDENCE Link stage history, a current mutual plan, meeting decision, or buyer confirmation. Show close-date changes and whether the next milestone is accepted or merely proposed. ACCEPTANCE The card identifies a real decision, not just a seller activity. Missing or contradicted evidence is UNKNOWN and routed to the owner; the AI cannot advance, close, or reforecast the opportunity.

Buying group, roles, and authority

Map confirmed users, evaluators, champion, economic decision maker, procurement, legal, security, implementation owner, blocker, and absent roles relevant to this stage. Role and influence are not reliably inferred from a job title.

FIELD Map confirmed users, evaluators, champion, economic decision maker, procurement, legal, security, implementation owner, blocker, and absent roles relevant to this stage. Role and influence are not reliably inferred from a job title. EVIDENCE Use participant statements, accepted plans, meeting records, CRM contacts, and authorized enrichment. Label each role CONFIRMED, REPORTED, HYPOTHESIZED, or UNKNOWN with date and source. ACCEPTANCE The map avoids sensitive personal profiling and private contact discovery. It suggests one respectful question or introduction request; it never fabricates a committee or automatically contacts a person.

Decision criteria, priority, and proof needed

List each criterion in buyer language, priority or weight if actually supplied, minimum threshold, evidence expected, responsible evaluator, decision date, and unknowns. Include functional, security, legal, commercial, service, implementation, and governance needs where relevant.

FIELD List each criterion in buyer language, priority or weight if actually supplied, minimum threshold, evidence expected, responsible evaluator, decision date, and unknowns. Include functional, security, legal, commercial, service, implementation, and governance needs where relevant. EVIDENCE Link RFP/RFI items, approved requirements, meeting decisions, tests, questionnaires, or attributable notes. Do not treat a seller’s standard checklist as buyer criteria. ACCEPTANCE Criteria are comparable across alternatives using the same definitions and period. No weight is invented, and unmet or untested requirements are visible rather than hidden by an overall score.

Current approach and cost of staying with it

Describe the incumbent product, manual workflow, internal build, outsourced service, or no-decision path; include ownership, dependencies, switching constraints, observed friction, and any approved cost model. “Do nothing” is often the real alternative.

FIELD Describe the incumbent product, manual workflow, internal build, outsourced service, or no-decision path; include ownership, dependencies, switching constraints, observed friction, and any approved cost model. “Do nothing” is often the real alternative. EVIDENCE Use prospect-reported workflow, verified system inventory, approved process map, or documented calculation. Distinguish observed cost from modeled cost and recurring expense from one-time transition effort. ACCEPTANCE The card does not ridicule the current approach or inflate pain. It shows assumptions, missing inputs, transition risk, and circumstances in which retaining the current system may be reasonable.

Named alternatives and competitive status

Record only alternatives the buyer named or a qualified owner intentionally included: product, internal build, service provider, incumbent, delay, or no decision. Add evaluation status and why it is in scope without claiming hidden buyer preference.

FIELD Record only alternatives the buyer named or a qualified owner intentionally included: product, internal build, service provider, incumbent, delay, or no decision. Add evaluation status and why it is in scope without claiming hidden buyer preference. EVIDENCE Attribute buyer statements and link current official competitor documentation for objective capabilities or prices. Use a capture date, region, plan/edition, configuration, and comparison basis. ACCEPTANCE No rumor, anonymous review, outdated screenshot, scraped confidential detail, or former-employee information appears as fact. Unsupported competitor claims remain UNKNOWN or PROHIBITED.

OpenMax fit and approved proof

Map only the OpenMax capabilities relevant to verified criteria. For each, attach the exact approved product document, security response, demo evidence, contractual language, reference policy, or authorized case proof—and note prerequisites and limitations.

FIELD Map only the OpenMax capabilities relevant to verified criteria. For each, attach the exact approved product document, security response, demo evidence, contractual language, reference policy, or authorized case proof—and note prerequisites and limitations. EVIDENCE Use current first-party materials and approved internal repositories with version, owner, geography, plan, environment, and expiry. A customer logo or anecdote is not proof of a quantified outcome. ACCEPTANCE The claim says no more than the evidence supports. Security, legal, pricing, roadmap, performance, and ROI statements route to the responsible owner before external use.

Gaps, risks, and where OpenMax may not fit

List unmet, untested, conditional, or out-of-scope requirements; integration and migration dependencies; policy or data limits; adoption burden; commercial uncertainty; and implementation capacity. A credible card includes reasons not to proceed.

FIELD List unmet, untested, conditional, or out-of-scope requirements; integration and migration dependencies; policy or data limits; adoption burden; commercial uncertainty; and implementation capacity. A credible card includes reasons not to proceed. EVIDENCE Link product constraints, test results, qualified-owner decisions, open tickets, contract positions, and prospect dependencies. Separate remediable gap, roadmap possibility, and hard no-fit. ACCEPTANCE No workaround, roadmap date, certification, exception, or integration is promised without authorization. Each material risk has severity, owner, mitigation or stop condition, and next verification date.

Likely objections and evidence-safe responses

Write the objection in the prospect’s words, identify whether it is confirmed or anticipated, explain the underlying criterion, provide a short approved response, and add one diagnostic question. Include what the seller must not claim.

FIELD Write the objection in the prospect’s words, identify whether it is confirmed or anticipated, explain the underlying criterion, provide a short approved response, and add one diagnostic question. Include what the seller must not claim. EVIDENCE Use current conversation records, approved enablement, product documentation, pricing policy, security/legal answers, and attributable win/loss research. Never fabricate a competitor weakness or customer quotation. ACCEPTANCE The response is specific, qualified, and supported; it does not evade the concern. High-risk questions are handed to Product, Security, Legal, Finance, or Deal Desk instead of answered by the model.

Next action, owner, date, and refresh trigger

Specify one smallest useful action, responsible human, counterparty or internal dependency, expected result, due date/time zone, approval requirement, and deduplication key. Add a review date and events that invalidate the card.

FIELD Specify one smallest useful action, responsible human, counterparty or internal dependency, expected result, due date/time zone, approval requirement, and deduplication key. Add a review date and events that invalidate the card. EVIDENCE Tie the action to an accepted milestone, explicit request, missing decision criterion, expiring artifact, or accountable owner instruction. Preserve the source and approval record. ACCEPTANCE The action is authorized, non-duplicative, reversible where possible, and observable. The card expires after material product, price, competitor, stakeholder, stage, or requirement change.

Worked example: turn a competitor rumor into a safe question

This hypothetical example demonstrates evidence handling. It is not a statement about any real competitor, prospect, customer, or product.

Unsafe draft“Competitor A is insecure and cannot support the buyer’s compliance needs. Tell the prospect OpenMax is safer.” The draft converts an anonymous review into a broad security claim and provides no product edition, control, date, or approval.

Evidence inspectionThe prospect reported that EU data residency and SSO are required. The seller found a two-year-old third-party comment about a different competitor plan. Current official documentation is unclear, and the prospect has not said the competitor failed either criterion.

Corrected cardMark the competitor capability UNKNOWN. Preserve the buyer requirements as REPORTED, link their source, and add a question: “Which residency boundary and identity controls must each shortlisted provider demonstrate?” Attach only the current approved OpenMax evidence relevant to that answer.

Human decisionThe account owner may use the question. Security reviews any control comparison; Product confirms edition and configuration; the seller cannot state that the competitor is insecure or that OpenMax satisfies the requirement until evidence and scope are approved.

What the audit record should prove

Store the opportunity cutoff, source URLs or record IDs, captured excerpts, evidence states, freshness, alternative versions, prompt/output version, policy checks, approver, approved wording, rejected claims, next action, and later corrections. Minimize personal or confidential content.

Acceptance: another reviewer can reconstruct why the rumor was excluded, why the discovery question is fair, and which exact OpenMax claim—if any—was authorized.

How to use the template without creating sales noise

Start from one meeting or decision

Declare the opportunity, audience, objective, cutoff, permitted sources, and action boundary. Do not create one giant account dossier that silently merges unrelated subsidiaries and old deals.

Retrieve evidence, then draft

Fetch bounded source packets for each field, classify evidence state, surface conflicts, and leave missing fields UNKNOWN. Generate language only after claims and permissions are visible.

Review high-risk claims

Route security, legal, privacy, price, discount, roadmap, performance, ROI, customer reference, and named competitor comparisons to their qualified owners before seller use.

Use, observe, and expire

Record whether the card helped discovery or a decision, capture corrections, and refresh after material changes. Track usefulness and correction burden—not only opens, copies, or generated cards.

How OpenMax supports this workflow

OpenMax workflow diagram for sales battle card template

From prompt to governed OpenMax workflow

OpenMax can turn a reviewed instruction into an AI employee workflow with shared context, tool connections, task ownership, logs, and human review. The template defines the job; permissions and approval gates control what can happen next.

Explore OpenMax →

Limits and human-review boundaries

A battle card organizes evidence; it does not make a product, legal, security, pricing, or commercial decision.

Never invent prospect pain, budget, authority, urgency, competitor usage, intent, win probability, or a customer result.
Do not use confidential competitor material, scraped personal data, irrelevant sensitive attributes, restricted communications, or information without a lawful and permitted sales purpose.
Comparative statements must use a clear comparison basis, current equivalent scope, accurate qualifications, and substantiation for both express and implied claims.
Do not promise roadmap items, exceptions, discounts, contractual terms, security outcomes, implementation dates, ROI, or performance without the accountable owner’s approval.
The AI may summarize, detect gaps, and propose questions. A human owns external wording, outreach, record changes, escalation, and any decision to proceed or withdraw.

Frequently asked questions

Should every opportunity have all 12 fields completed?

No. UNKNOWN is an honest and useful state. Complete fields relevant to the next decision and risk; do not conduct excessive research or invent content just to fill a template.

Can the card name a competitor?

Yes, when the alternative is genuinely in scope and comparisons are truthful, current, clearly based, and substantiated. Use official documentation where possible and show edition, region, configuration, capture date, and limitations.

Can AI infer what the prospect cares about?

It may produce a labeled hypothesis for discovery when policy allows, but it cannot turn industry stereotypes, job titles, browsing signals, or missing data into facts. Ask and verify.

How often should the card be refreshed?

Set a review date and event triggers: a new stakeholder, changed criterion, stage move, revised quote, security answer, product release, competitor update, source expiry, or correction. High-change fields may need shorter lifetimes.

How should quality be measured?

Track verified-field coverage, unknowns resolved, citation validity, stale or rejected claims, reviewer correction burden, time to a useful question, meeting usefulness, policy incidents, and downstream decision quality. Do not equate card volume with sales impact.

Sources, editorial method, and limitations

OpenMax editors reviewed primary guidance on comparative-claim clarity and substantiation, public-company research, opportunity record structure, sales playbooks, and AI risk documentation. We converted those principles into an original 12-field prospect card with evidence labels, field-level acceptance tests, explicit no-fit reporting, claim approval, expiry, and correction routes. Sources were reviewed September 3, 2026. Product and competitor information changes; always verify the precise current scope. No customer win rate, revenue, conversion, or productivity result is claimed.

U.S. Federal Trade Commission — Statement of Policy Regarding Comparative Advertising — comparisons should identify the basis clearly and remain truthful and non-deceptive.
U.S. Federal Trade Commission — Advertising Substantiation Policy Statement — objective express and implied claims need an appropriate reasonable basis before dissemination.
U.S. Securities and Exchange Commission — Search Filings — free public access to issuer filings and full-text EDGAR research for attributable company context.
Salesforce Help — Opportunities — opportunity records and the sales information used to manage a live buying motion.
HubSpot Knowledge Base — Use playbooks — guided content, questions, notes, and record updates within seller workflows.
NIST AI Resource Center — AI RMF resources for documentation, testing, evaluation, verification, and validation.

Scope note FTC materials describe U.S. advertising principles and are not legal advice for every jurisdiction or private sales conversation. SEC filings cover public disclosures and can be old or incomplete for the immediate buying motion. CRM and playbook behavior varies by product, license, configuration, region, permissions, and retention. Apply applicable law, contract, company policy, and qualified review.