Role-Based Battlecard Framework

How the roles differ across a card set

The organizing idea is that the same competitor intel gets repackaged by seller stage. In the four-role cut most closely associated with the framework, the BDR card is the shortest, roughly a handful of bullets on how to respond when a prospect name-drops a competitor or drops a landmine, since the BDR's goal is to book the meeting, not to win a technical debate.

The AE card carries more depth and does double duty: it is a live-call resource and also pre-call training material, weighted toward objection handling and countering FUD. The SE, or solutions engineer, card is the most in-depth of the set, because SEs have to answer detailed questions about features, implementation, and integrations during evaluation. The CS card is a post-sale artifact, used at kickoff and especially at renewal, when a competitor may resurface. The content underneath is the same competitive truth; the length, technical depth, and framing are what change from role to role.

Role-based vs. matrixed and dynamic frameworks

Role-based is one rung on the maturity ladder Crayon describes, which runs Universal, then Role-Based, then Matrixed, then Dynamic. Understanding the neighbors keeps the scope clean. A universal battlecard is the single, one-size-fits-all card the role-based approach is built to replace or supplement; it segments by nothing.

A matrixed battlecard framework is a superset of role-based: it keeps the role axis but adds a second one, such as region, product line, or enterprise-versus-SMB segment, so a card is chosen by who you are and what deal you are in. Role-based segments by 'who' only; matrixed segments by 'who' plus 'where or what.' The dynamic stage is orthogonal to all of this. It is defined by an update mechanism, cards kept current automatically and embedded in workflow, rather than by how the audience is sliced. A set of cards can be role-based and dynamic at once.

Where it sits in a CI workflow

In competitive-intelligence practice, a role-based framework is the delivery layer, not the research layer. The underlying intelligence, whether a pricing change, a feature launch, or a positioning shift picked up by monitoring a competitor's website, pricing page, or job postings, is gathered once. The framework decides how that single input is routed and phrased for each consumer.

That routing is deliberate. BDRs get terse objection-deflection bullets for early-funnel conversations. AEs get deal-stage positioning and FUD-countering talk tracks. SEs get the deep technical differentiators that hold up under evaluation scrutiny. CS gets renewal-focused messaging for the moment a competitor reappears in an existing account. The recurring justification across sources is adoption: generic cards are frequently reported as under-used, and tailoring each card to what a role can actually act on is the mechanism meant to raise the odds it gets opened.

Common mistakes and limits

The framework is a packaging discipline, not a source of truth, so its most common failure is treating card proliferation as progress. Four role-specific cards that all trace back to stale or thinly-sourced intel are four times the maintenance for the same weak signal; the tailoring only pays off when the underlying competitive research is current.

A second pitfall is confusing role-based classification with content-focus classification. Some vendor taxonomies sort cards by subject, such as competitor battlecard, objection-handling battlecard, or product battlecard, which is a different axis from the internal seller's job function. The labels overlap confusingly, since a term like 'BDR battlecard' can appear in both schemes but grouped differently. Finally, there is no canonical role list. Adopting a role split mechanically, without checking that your actual sales motion has those exact stages, produces cards for roles that do not exist on the team and leaves real handoff moments uncovered.

Frequently Asked Questions

Related terms