How to Structure a Battlecard So Your AI Copilot Can't Improvise
The fix for AI assistants inventing competitor claims mid-call isn't a smarter model. It's a battlecard that isn't secretly a Google Doc.
A rep is on a discovery call. The buyer asks the question every buyer asks eventually: "How are you different from [Competitor]?" The AI copilot pipes a suggested answer into the sidebar — a specific, confident claim about the competitor's implementation timeline. The rep reads it out. It's wrong. Not wrong in tone, wrong in substance — the kind of wrong that gets screenshotted and forwarded to the competitor's account exec by an ex-colleague within the hour. Nobody typed that claim into any system, ever. The copilot built it, live, from a battlecard that never actually said it.
Enablement leaders' instinct here is to blame the model. Swap the LLM, add a disclaimer, tell reps to "always verify." None of that fixes anything, because the model isn't the thing that's broken.
The battlecard was never a source of truth
Open the actual document most teams call a battlecard and you'll find three pages of prose written by a product marketer eighteen months ago, half-updated by a sales engineer who left in Q1, formatted with headers like "Why We Win" and "Objection Handling." Somewhere in there is a sentence like: "We're generally faster to deploy than [Competitor], especially for mid-market accounts." That sentence is not a fact. It's a vibe with a competitor's name attached.
Feed that to a live copilot and ask it a specific, time-pressured question — "how much faster, exactly?" — and the model does what language models do with ambiguous input under pressure to answer: it completes the pattern. It invents a number that sounds like it belongs in that sentence. That's not a malfunction. It's the model doing precisely what unstructured prose forces it to do — interpret, and interpretation under time pressure produces fabrication.
The fix isn't a smarter model. It's removing the interpretation step so there's nothing left to invent.
Replace prose with atomic claims
An atomic claim is one sentence the copilot is permitted to say, with nothing attached that requires judgement to use correctly. Every claim in your battlecard needs to be broken down to this shape:
| Field | Purpose |
|---|---|
| Claim | The exact sentence the copilot may output, word for word |
| Competitor | Named specifically — never "the competition" |
| Scope | The condition under which it's true (segment, region, product tier, deal size) |
| Evidence | A link to the actual source — a win/loss call, a competitor's own pricing page, a signed analyst note |
| Verified | The date someone last checked this against reality |
| Owner | The named person accountable if it goes stale |
| Expires | The date it gets automatically pulled if nobody re-verifies it |
Notice what's missing: tone, framing, persuasion language. That's deliberate. A battlecard's job is to be a database, not a script. The moment a claim carries adjectives, you've reintroduced the ambiguity the model has to fill in.
Build it in four passes
- Audit what you have. Pull every competitive claim currently living in decks, wikis, and Slack threads. Most teams are stunned by how many versions of the same claim exist, each slightly different, none dated. A structured pass through this — the kind a Sales Content Audit Checklist is built for — usually surfaces three or four contradictory claims about the same competitor sitting in different documents at once.
- Decompose, don't summarise. Take each surviving claim and force it into the atomic shape above. If you can't fill in Evidence with something more specific than "sales engineering says," the claim doesn't survive the pass. This step is where most of the actual work is, and it's tedious on purpose — the tedium is what unstructured prose was hiding from you.
- Structure the displacement logic separately from the claims. Competitive positioning against a specific rival — when to lead with price, when to lead with implementation speed, which claims to hold back until the second call — is a different asset from the claims themselves. A Competitive Displacement Playbook Framework keeps that sequencing logic out of the claims table, so the copilot's retrieval layer only ever pulls atomic, sourced facts, never strategy dressed up as fact.
- Feed the copilot structured data, not the document. This is the step teams skip because it's the one that requires touching the tooling. If your copilot's retrieval index is pointed at a Google Doc or a Confluence export, it is still interpreting prose — you've just added a vector database on top of the ambiguity instead of removing it. The index needs to point at the structured table, one row per claim, with the scope and expiry fields intact so retrieval can filter on them.
Governance is the part that keeps it true
A structured battlecard that never gets re-verified degrades exactly like the prose version did — it just fails more precisely, which is actually worse, because reps trust it more. Every claim needs a named owner and a review cadence, and expired claims need to disappear from the copilot's retrieval automatically rather than sit there waiting for someone to notice. This is a governance problem before it's a tooling problem, which is why a Sales Content Governance Framework belongs upstream of any copilot rollout, not bolted on after the first bad call gets flagged.
What this actually buys you
It doesn't make the AI smarter. It makes the AI unable to be creative about things creativity shouldn't touch. A rep will still occasionally misjudge tone or push a claim in the wrong context — that's a coaching problem, and a legitimate one. But the specific failure mode of a system inventing a specific false number about a named competitor, live, on a recorded call, is a data architecture failure, not a model failure. Fix the architecture and the model stops having anything to invent.
The teams still getting burned by this in six months won't be running worse models. They'll be running the same unstructured document through a newer one, wondering why the improvise-under-pressure problem didn't go away. It won't, because it was never the model's problem to solve.