Fern Kettlewell is VP of Revenue Enablement at a B2B infrastructure SaaS company. She oversees a governed claim library: the operational system where every seller-facing statement is versioned, tagged to its source evidence, and tracked for reuse. She has survived three enablement platform migrations, an incident she refers to only as "the screenshot call," and what she estimates is roughly four thousand Slack messages from account executives asking if a particular data point is "still good." We spoke over video. She was drinking from a mug that read "I SURVIVED THE Q3 BATTLECARD AUDIT." Whether the mug exists is less interesting than the fact that someone would buy it.
You call your claim library "the library with teeth." What does that mean in practice?
Fern: It means claims bite back when they're wrong. Every seller-facing statement in our system has three pieces of metadata bolted to it: a source link, a last-verified date, and an owner. If the source changes, the claim goes amber. If nobody re-verifies it within the window, it goes red and gets pulled from the CRM sidebar. Reps literally cannot copy-paste it anymore. That's the teeth.
What triggers a review? Is someone watching a dashboard all day?
Fern: God, I wish it were that romantic. We use a competitive intelligence platform — Klue, Crayon, that category — that crawls competitor websites, pricing pages, product announcements.1 When something changes, it fires a Slack alert tagged to the relevant battlecard. A competitor drops a feature from their pricing table, and within a few hours my team gets a notification that says, essentially, "hey, battlecard 47 might be lying now."
But the alert is the easy part. Translating "competitor changed their pricing page" into "here's what the rep should say differently on a call at 2 PM" — that's where everything breaks down.2 That translation requires a human, usually a product marketing manager, and that person has nine other things on fire. So the alert sits. Sometimes for a day. Sometimes for a week. And during that week, the old claim is still technically active.
How often does a single external event invalidate multiple claims at once?
Fern: More than anyone realizes. A competitor launches a new product tier and suddenly fifteen to twenty claim blocks across six different battlecards are potentially wrong. Not "outdated" in the sense that the data aged gracefully. Wrong. The truth value flipped.3 Monday morning the claim was accurate. Monday afternoon, after the press release, it wasn't.
We had an incident — "the screenshot call" — where a seller pulled up a competitive two-pager in a live demo with a prospect's CTO. The CTO had the competitor's actual, current pricing page open on his other monitor. Our two-pager was three quarters old. The CTO just... shared his screen. Didn't say a word. Just showed us our own document next to reality.
What happened after that?
Fern: I got a bigger budget. (laughs) No, seriously, that's when we moved from quarterly battlecard reviews to event-triggered reviews. The quarterly model is — look, a battlecard updated quarterly is dead by month two.4 In our market, competitors ship features every three weeks. Governing on a quarterly cycle means you're governing a fiction.
So the system works now?
Fern: The system works when the humans work. The platform is plumbing. We have lifecycle states — Draft, Under Review, Active, Archived — and every claim moves through them.5 But the bottleneck never changes: someone has to look at the alert, understand what changed, decide what it means for our positioning, rewrite the claim, and get it approved. If that person is on vacation or in back-to-back meetings or just... tired, the claim stays active longer than it should.
What happens when governance fails? When a stale claim gets through?
Fern: Rogue content. Every single time. And this is the part that drives me crazy — everyone treats rogue content like a discipline problem. "Reps need to use the approved materials." But reps are rational actors. If the library doesn't have what they need, or what it has feels stale, they'll pull from their personal Dropbox, an old email, a deck from two quarters ago.6 They have a call in twenty minutes and the battlecard says "last verified: four months ago." You'd do the same thing.
The rogue content problem is a system design problem. Nobody knows a rep is using a personal version of a competitive talking point until the prospect corrects them on a call. Or until legal gets a letter.
The stat that haunts me: seventy-five percent of sales leaders logged into their enablement platform fewer than five times last quarter.7 That's the platform failing to be where the work happens. If your governed claims live in a portal that requires three clicks and a login, you don't have an enablement platform. You have an expensive content shelf.8
What's the difference between a shelf and infrastructure?
Fern: Whether the claim is findable at the moment of use, inside the system the seller is already in. A battlecard pinned to the right competitor inside the Salesforce opportunity sidebar, two clicks to copy — that's infrastructure. The same battlecard in a Google Doc bookmarked somewhere — that's a shelf. The content is identical. The dependency is completely different.
Is there a version of this where "current" and "usable" aren't the same thing?
Fern: Oh, absolutely. We're not regulated like pharma — we don't have formal MLR review (that's the Medical, Legal, and Regulatory approval process that pharmaceutical companies run every claim through before it touches a sales rep).9 But we have a lighter version. Legal has to sign off on certain competitive claims before they're shareable with prospects. So a claim can be factually updated, reflecting the latest competitive data, and still be blocked from external use because legal hasn't re-approved the new version.
We call that "accurate but grounded." The rep can see it, knows it exists, but can't share it. Drives them absolutely insane.
What would you want someone building content infrastructure to understand about this work?
Fern: That the unit of governance is the fragment, not the document. Not the article, not the deck, not the page. The individual claim block.10 Every template, every proof point, every competitive snippet needs its own source link, its own expiry, its own owner. If you govern at the document level, you get a document that's 80% current and 20% dangerous, and nobody knows which 20%.
And — I would tattoo this on a wall if HR would let me —
Speed without verification creates risk. We can generate battlecards with AI in minutes now. Beautiful, fluent, completely plausible battlecards. But if the underlying claim hasn't been verified against current source evidence, you've just made it faster to be wrong.11 The AI doesn't know the claim expired. It just sounds confident.
A rep who uses an AI-generated claim that's six months out of date can lose credibility in a competitive deal instantly. Confidence without currency is worse than silence.
Last question. Does anyone ever thank you for this work?
Fern: (long pause) A rep told me once that she won a deal because the battlecard had the competitor's actual current pricing, down to the penny, and the prospect was shocked we knew. She said, "I don't know who updates these, but tell them I owe them a drink." That was two years ago. I'm still waiting for the drink. I've started to think of it as a metaphor for enablement in general.
Footnotes
-
Klue and Crayon both offer near-real-time competitive intelligence monitoring, including automated crawling of competitor websites, pricing pages, and product announcements. See https://klue.com/competitive-intelligence-platform and https://inflowave.io/resources/best-competitive-intelligence-tools-2026 ↩
-
The gap between signal receipt and tactical translation is described in Klue's competitive battlecard literature: "External tracking tells you what the competitor claims they do. It does not tell you why you are actually losing deals to them." https://klue.com/blog/competitive-battlecards-101 ↩
-
AI-assisted battlecard creation introduces this risk explicitly: "speed without verification creates risk. A rep who uses an AI-generated claim that's six months out of date can lose credibility in a competitive deal instantly." https://www.apollo.io/insights/sales-battlecard-template ↩
-
The quarterly staleness problem is a recurring theme in enablement literature. Battlecards require "real-time updates triggered by launches, losses, pricing adjustments, or messaging changes." https://www.highspot.com/blog/sales-battlecards/ ↩
-
The Draft → Under Review → Active → Archived lifecycle is standard across enablement platforms. See https://www.highspot.com/blog/content-governance/ ↩
-
"Anything missing here will create gaps your reps will fill in unsafe ways — usually with personal Dropbox folders and outdated PowerPoints." https://www.buzzboxmedia.com/blog/healthcare-sales-enablement-platform/ ↩
-
Highspot's 2025 State of Sales Enablement data, cited in https://salesmotion.io/blog/best-sales-enablement-platforms ↩
-
"If your CRM, your DAM, and your marketing automation are not feeding into and out of your sales enablement layer, you do not have an enablement platform — you have an expensive content shelf." https://www.buzzboxmedia.com/blog/healthcare-sales-enablement-platform/ ↩
-
In fully regulated contexts, Veeva PromoMats enforces Medical, Legal, and Regulatory (MLR) review before any claim reaches commercial distribution. The lighter SaaS equivalent — legal sign-off on competitive claims — follows the same structural logic. https://www.veeva.com/products/veeva-promomats/claims-management/ ↩
-
"Modular sections: each proof block or talk track is a discrete unit, not buried in a document." Governance metadata — source, last-verified date, approver — attaches at the block level, not the document level. https://www.apollo.io/insights/sales-battlecard-template ↩
-
Highspot's AI content governance framework addresses this directly: machine learning can tag assets, flag stale material, and route reviews, but the verification step remains human-dependent. https://www.highspot.com/blog/content-governance/ ↩
