A program-owner's guide to competitive intelligence for sales teams: ownership split between PMM, RevOps and enablement, the AI-assistant delivery channel that fixes adoption, and the metrics that prove the program works.
May 16, 2026 · 17 min read
If you own a sales-CI program, your readers and your buyers are not the same. You read this article. Your reps live the consequences of how you design the program around them. Most "competitive intelligence for sales" content is written as if reps were the audience. They aren't. They are the consumer of the program you build, and whether they use it depends on choices made well upstream of any battlecard.
This is the program-owner's version. It's for RevOps, sales enablement, and sales leadership who need to decide who owns what, what delivery channel actually reaches reps in deals, and what metrics tell you whether the system is working. For the discipline-level overview, read the competitive intelligence pillar. For the upstream view from the PMM side, see competitive intelligence for product marketing managers.
TL;DR
A sales-CI program is owned by four functions, not one. PMM produces the content. RevOps owns capture and routing. Enablement owns adoption. Sales leadership owns the feedback loop. Programs without that split named end up orphaned.
Reps don't read battlecards. They ask questions mid-call. The fix is a delivery architecture (AI assistant, in-CRM surfacing, Slack alerts), not a better-looking document.
Win/loss is a RevOps responsibility before it's a PMM one. The CRM field, the sampling discipline, and the routing back to battlecards all start with operations.
Tooling depends on stage. SMB/mid-market: self-serve AI-native stack plus Gong-style call intelligence. Enterprise: sales-led suites (Klue most often) layered over the same primitives.
Five metrics tell you the program works: competitive win rate, battlecard freshness, AI-assistant query volume, win/loss capture rate, time-to-update after a competitor move. None of them are "battlecards shipped."
Who owns what in a sales-CI program
The single most common failure mode of sales-CI programs is undefined ownership. The CRO sponsors it because the board asked. The PMM gets handed battlecard duty because they're "closest to messaging." The reps are nominally the audience but never consulted on format. Six months later the program is stalled and nobody knows whose problem it is.
A workable program names four ownership zones explicitly.
Function
What they own
What they don't
Product marketing (PMM)
Battlecard content, positioning thesis per competitor, qualifying signal definition, launch counter-messaging
CRM hygiene, rep adoption mechanics, win/loss data capture
RevOps / Sales ops
CRM fields (competitor at close, deal stage tagging), data routing, integration plumbing (Gong to CRM, MCP feed), tooling decisions
Ready to monitor your competitors without the manual work?
Competitive intelligence practitioners building AI-native workflows.
Battlecard wording, narrative positioning
Sales enablement
Onboarding to the CI program, adoption coaching, training cadence, deal-level CI office hours
Strategic positioning, top-line metric definition
Sales leadership (VP / CRO)
Monthly win/loss review, executive sponsorship, escalation when adoption stalls, the metric that triggers program changes
Day-to-day content production
The split exists in big orgs by default and in small orgs by force. A 15-person GTM team still needs all four roles named, even if one person holds two of them. The naming is what matters; ambiguity is what kills the program.
A concrete test of whether the split is working: when a competitor ships a new pricing tier on a Tuesday afternoon, who updates the battlecard, who triggers the Slack alert to reps in active deals against that competitor, who confirms reps acknowledged it, and who closes the loop in next month's exec review? If those four answers come back as four different named people, the program is healthy. If three of them come back as "I think the PMM?", it isn't.
The rep's actual moment of need
The rep needs answers, not documents. That distinction is the entire program-design problem in one sentence.
Three moments in a deal cycle drive most of the actual CI consumption.
Pre-callWho's the likely incumbent? What's their recent positioning shift?
In-callHow do I handle this objection right now? What trap question fits?
Post-callWhat did the prospect say about the competitor? Where do I log it?
Pre-call use is well served by existing surfaces. Reps look up the prospect's stack, scan a battlecard, prep for likely competitive scenarios. They have time, they have hands free, the content can be five paragraphs. Most CI programs serve this moment fine.
In-call use is where adoption goes to die. The rep needs one specific answer between two prospect questions. They can't open a 6-block Notion page. They can't even open a new tab without losing eye contact on Zoom. If the answer isn't reachable in three seconds, they wing it. Anything you ship at this moment that requires a separate UI to consult might as well not exist.
Post-call use is where reps owe the program something back. Win or lose, the deal note should capture what the competitor did or said. Most programs collect this data badly because the field is optional, the prompt is buried, and reps see no value coming back to them from filling it.
If you design only for pre-call, your battlecard count goes up and your win rate doesn't move. If you design for in-call, you'll be forced into a delivery architecture that looks very different from what most programs ship.
Battlecards as a delivery problem, not a content problem
Most failed sales-CI programs are content-rich and delivery-poor. The PMM wrote excellent battlecards. The reps don't open them. Both observations are true at the same time and the program owner is asking the wrong question when they ask "how do we improve our battlecards?"
The right question is: when a rep needs a specific competitive answer in a deal, what surface puts it in their hands?
Rep's question mid-deal
CRM opportunity tile
AI copilot via MCP
Slack competitor channel
Manager ping
Gong call snippet
Four delivery patterns work better than a static document. They stack rather than substitute.
CRM-embedded battlecard tiles surface the freshest two or three competitive lines directly on the opportunity record, tagged by the competitor at close. The rep is already in the CRM; the content meets them there. This is where Klue, Crayon, and most sales-led suites concentrate their effort, and it's table stakes for any program above ~10 reps.
Slack channels per priority competitor turn the program into a living feed. New ad creative spotted in Meta Ad Library, new pricing tier on the competitor site, fresh win/loss debrief on a deal against them. Anything material posts in a dedicated channel that interested reps mute by default and search when they need to.
Gong (or any call-intelligence tool) embeds CI back into the conversation surface. When a competitor name is detected on a call, the rep sees the relevant battlecard snippet inline in the call review afterward. Some platforms also surface this in real-time during the call.
The AI assistant via MCP or API is the channel most teams haven't built and where the next two years of marginal value sit. A rep mid-call asks their internal copilot or sales assistant "what's our pricing answer if they push Klue at Enterprise tier?" and gets a clean answer pulled from the same battlecard data. This works only if the battlecard content lives as machine-readable structured data, not as a PDF. The MCP endpoint or stable API is the contract that lets every assistant in the rep's stack query the same source of truth.
Manager pings are the human fallback. When everything else fails, a rep messages their manager. A good program treats manager response patterns as a signal that the upstream surfaces failed and works back from there to fix the gap.
The AI-assistant channel: MCP, copilots, in-CRM AI
The AI-assistant channel deserves its own treatment because it changes the program-design calculus more than the other three.
Reps don't read. They will absolutely ask. Once an internal copilot is on their laptop or inside their CRM, the question "what's the trap question for Klue on security?" becomes a 4-second action between two prospect emails. That changes the cost of consumption from a tab-open to a typed sentence, and the volume of CI consumed goes up an order of magnitude in the teams that have wired it.
For the program owner, three architecture choices follow.
Battlecard content has to live as structured data. Fields, tags, source URLs, last-updated timestamps. Not paragraphs in a PDF. Not a Word doc on a shared drive. The format is the contract that lets an AI assistant retrieve and recompose answers reliably.
A retrieval surface has to exist. Either an MCP endpoint (the cleanest option for AI-native teams) or an API the internal copilots can call. Many AI-native CI workspaces (including watchr) expose this directly. Sales-led suites are catching up with various degrees of completeness.
The assistant chain has to be allowed to use it. This is where most programs stall non-technically. Security and IT need to greenlight the connection. Sales enablement needs to train reps that "ask your copilot" is now a documented step in the playbook. Without both, the channel exists technically and stays unused.
Teams that wire this end-to-end see the steepest adoption curve of any sales-CI surface in 2026. It's not because the AI is magic. It's because the friction of asking a question is finally lower than the friction of looking one up.
Win/loss as the RevOps feedback loop
Win/loss is the most undervalued CI input in most sales organizations, and the most fixable. The problem is structural: the data lives in conversations, not in fields, and conversations don't aggregate.
RevOps owns the structural fix. PMM owns the synthesis.
The fix has three components.
A required CRM field for competitor at close on every lost opportunity, with a clean dropdown and an "other" escape. Bad dropdowns force reps to type, typed data is noisy, noise kills downstream analysis.
A sampling discipline rather than an aggregation report. RevOps pulls 15 to 20 lost-competitive deal notes per month and routes them to PMM for read-through. Patterns emerge at small sample sizes that vanish in dashboards. The dashboard tells you you lost 14 deals to Crayon last quarter; the deal-note read tells you you lost them all on a specific objection about implementation time.
A debrief cadence with at least the closing rep, ideally with the prospect. Even a 15-minute rep conversation 48 hours after close-lost yields information the CRM note didn't capture. Programs that build this into the close-lost workflow (a calendar invite triggered by stage change) get the data; programs that wait for reps to volunteer it don't.
The feedback loop closes when the synthesis comes back to reps as updated battlecards, refreshed trap questions, and a Slack message in the relevant competitor channel summarizing what changed. If the loop doesn't close, reps stop reporting because they see no return on their data entry. RevOps owns the data discipline; PMM owns the return path.
Tools and integrations for sales-led CI
The sales-CI tooling landscape sorts into four layers. Most mature programs run several at once because they solve different problems.
Layer
Examples
What it solves
Stage fit
Sales-led CI suite
Klue, Crayon, Kompyte
Battlecard authoring, CRM-embedded delivery, sometimes integrated win/loss
Mid-market and up, with revenue ops infra
Call intelligence
Gong, Clari, Avoma
Detect competitor mentions on calls, surface relevant CI inline
Any team running >20 reps on recorded calls
AI-native CI workspace
watchr, newer entrants
Per-competitor qualifying prompt, MCP-readable feed, low setup cost
SMB through mid-market, AI-augmented teams
Change detection / point tools
Visualping, Wachete, ad-library wrappers
Raw signal capture on competitor surfaces
Any stage; usually as a component
Sales-led suites sit at the center for mid-market and enterprise programs because they ship CRM-embedded battlecard delivery out of the box, which is the highest-yield surface for in-deal consumption. Klue is the most integrated with revenue workflows. Crayon has the deepest web change-detection history. Kompyte sits between the two with stronger social and ad monitoring. All three carry enterprise pricing and annual contracts; they're heavy lifts for teams without revenue ops staffing to support them.
Call intelligence platforms are increasingly a CI surface in their own right. Gong's ability to flag competitor mentions on calls and surface the relevant battlecard snippet during call review is one of the few in-context CI experiences reps actually use unprompted. If you're already on Gong or a peer, ask what CI features ship in your current tier before buying anything else.
AI-native CI workspaces are the newer category, organized around an LLM qualifying prompt per competitor rather than rule-based filters, with MCP-readable delivery so AI assistants query qualified intelligence directly. They suit SMB and mid-market sales orgs that don't have enterprise CI budget and are building AI-augmented internal workflows. Self-serve pricing changes the buy-in math for a 10 to 30-rep org meaningfully.
Change-detection and point tools fit underneath any of the above as the raw-signal layer. A working program rarely runs only point tools because there's no qualification layer; rep signal-to-noise stays too low.
Measuring whether the program is working
Most sales-CI programs report on the wrong metrics. "Battlecards published this quarter" is a vanity number. "Reps trained on competitor positioning" is a training KPI, not a program-health one. Five metrics actually correlate with program effectiveness.
Metric
Definition
Cadence
Owner
Competitive win rate
Win rate on opportunities where a tagged competitor was in the deal
Monthly
Sales leadership reviews; RevOps captures
Battlecard freshness
Median days-since-last-update across active battlecards
Weekly
PMM owns; RevOps surfaces in dashboard
AI-assistant CI query volume
Number of CI-related queries reps run against the internal assistant per week
Weekly
Enablement reviews; RevOps instruments
Win/loss capture rate
Percentage of close-lost deals with a populated competitor at close field and a deal note
Monthly
RevOps owns
Time-to-update after competitor move
Hours between a material competitor move (pricing tier change, launch) and the battlecard reflecting it
Per event
PMM owns; enablement audits
Two principles run through all five. They're all about adoption and freshness, not production. And they're all leading indicators of competitive win rate, not lagging trophies. The point of measuring is to identify which surface in the program is leaking, not to celebrate that the program exists.
Programs that hit healthy thresholds on freshness, query volume, and capture rate tend to see competitive win rate move 4 to 8 points over two to three quarters. Programs that don't tend to plateau or regress regardless of content investment.
Anti-patterns that kill adoption
Five recurring patterns predict program failure across team sizes.
The battlecard-as-PDF anti-pattern. A beautifully designed PDF, shipped at the start of a quarter, opened twice, then forgotten. PDFs are static, unsearchable by AI assistants, ungrep-able by anyone, and disconnected from the CRM surface where reps work. If your program ships PDFs, the next change is to retire them.
The single-source-of-truth fantasy. The belief that "if we just consolidate everything into one tool, reps will use it." Reps work in 5 to 8 surfaces a day. The CI has to meet them in those surfaces, not pull them into a sixth. Multi-surface delivery isn't fragmentation; it's the only working model.
The PMM-owns-everything pattern. When PMM is asked to own content, capture, routing, and adoption simultaneously, the program stalls. PMM is a content function. The other three are operational. Separate the work or it doesn't happen.
The leadership absence pattern. Programs without a CRO or VP of Sales reviewing competitive win/loss monthly underperform programs that have one by a large margin. Industry data suggests roughly 76% effectiveness uplift when this review exists. It costs an hour a month from one executive and changes nearly everything downstream because it tells reps the data they enter actually gets read.
The "we'll measure once we ship" pattern. Programs that defer instrumentation to phase two never instrument. The win/loss field, the battlecard freshness dashboard, and the AI-query telemetry need to ship with the program, not after. If you're not measuring on day 30, you won't be measuring on day 300.
Next steps
If you're standing up a sales-CI program from scratch, six moves in the first 60 days will determine whether it survives the year.
Name the four owners. PMM, RevOps, enablement, sales leadership. Even if one person holds two roles, name the role assignment in writing.
Add the competitor at close field to your CRM with a clean dropdown. Make it required on close-lost.
Pick the primary in-deal delivery surface and instrument it. CRM-embedded battlecards for mid-market+; AI-assistant via MCP/API for AI-augmented teams; both ideally.
Stand up Slack channels per priority competitor. Three to five, not fifteen.
Schedule the monthly leadership win/loss review. Put it on the CRO's calendar before you ship anything else.
Instrument the five metrics. They don't have to be perfect on day one; they have to exist.
If you want to see what an AI-native CI workspace looks like as the delivery layer for a sales-CI program, watchr is free during the open beta. The MCP-readable feed and per-competitor qualifying prompt are built around the architecture this article argues for.
FAQ
Who should own a sales-CI program: PMM, RevOps, enablement, or sales?
All four, with explicit splits. PMM owns content and positioning thesis. RevOps owns data capture and routing. Enablement owns adoption. Sales leadership owns the feedback loop and executive sponsorship. The most common failure is asking one function to own all four.
What's the minimum viable sales-CI program for a sub-30-rep team?
A required CRM field for competitor at close, three to five Slack channels per priority competitor, one maintained battlecard per priority competitor in Notion or your CRM (not PDF), and an AI assistant or copilot wired to the battlecard content. Skip enterprise tooling at this scale; the AI-native stack plus call intelligence covers the use cases.
How do we get reps to actually use battlecards?
Wrong question. The right question is how to put battlecard content where reps already work (CRM, Slack, AI assistant, call review) so they don't have to "use battlecards" as a separate behavior. Adoption follows surface fit, not training intensity.
Where does Gong fit in a sales-CI program?
Gong (or any call-intelligence tool) is a CI surface in its own right. Competitor mention detection, in-context battlecard surfacing, and call review CI snippets are all more useful than they look. If you already run Gong, audit what CI features ship in your tier before buying additional tools.
How often should sales leadership review competitive win/loss data?
Monthly. The cadence matters less than the consistency. The signal to reps is that the data they capture gets read at the top.
Should sales enablement or RevOps run the program?
Neither alone. Enablement runs adoption and training. RevOps runs instrumentation and tooling decisions. Programs that pick one and ignore the other underperform programs that split clearly.
What's the biggest mistake new sales-CI programs make?
Shipping content before delivery. Beautifully written battlecards in surfaces no rep visits is the most common failure mode. Build the delivery architecture first; the content fits into it after.
