Automatisch generierte Wettbewerber-Battlecards aus Gong

---
name: competitive-battlecard
description: Build and refresh a competitive battlecard for a named competitor by mining Gong calls (won and lost) and reconciling against Salesforce deal outcomes. Produces a structured Markdown card with positioning summary, win patterns, loss patterns, talk-tracks per objection, and traps to avoid. Use when an active deal involves a named competitor and the existing battlecard is older than 30 days, or when a competitor has materially shifted positioning.
---

# Competitive battlecard

## When to invoke

Invoke when a deal in the active pipeline names a tracked competitor and the rep needs an objection-handling card the same day. The skill assumes Gong is the call corpus, Salesforce is the deal-outcome source of truth, and the competitor is one of the 3-5 you actively track in `references/competitor-list.md`.

Do NOT invoke for:

- Generic "tell me about competitor X" research with no live deal attached. Use a search tool — battlecards rot fast and producing them speculatively wastes tokens and creates stale artifacts.
- Customer-facing claims about competitors. Output is internal-only by default. The classification rules in `references/internal-vs-external.md` exist to gate what can ever leave the company.
- Competitors you have never lost to. Without loss data, the skill cannot extract loss patterns; it will pad and that padding is the exact failure mode the watch-outs guard against.
- Brand-new competitors with fewer than 5 mentions in the lookback window. The skill returns "insufficient signal" rather than hallucinating.

## Inputs

Required:

- `competitor` — slug matching an entry in `references/competitor-list.md` (e.g. `competitor-x`). The slug, not the display name, so aliases resolve.
- `lookback_days` — integer, defaults to 180. Use 90 for fast-moving categories, 365 for stable ones. The skill clips to the smaller of this window and 12 months.

Optional:

- `deal_id` — Salesforce Opportunity ID for the active deal. If provided, the skill weights talk-tracks toward objections raised on this specific call thread.
- `audience` — `ae` (default) or `pmm`. AE output emphasises talk-tracks; PMM output emphasises pattern shifts since the last refresh.
- `prior_card_path` — file path to the previous battlecard. If provided, the skill diffs and surfaces what is new versus stale.

## Reference files

Always read these from `references/` before generating the card. Without them the output is generic.

- `references/battlecard-format.md` — the literal Markdown skeleton the skill fills. Section order is load-bearing; reps scan top-to-bottom.
- `references/objection-talk-track-library.md` — the canonical pattern library (pricing, integration, migration, support, security). The skill matches new objections against these patterns rather than reinventing handlers.
- `references/internal-vs-external.md` — the classification rules that decide which lines may ever appear in customer-visible material. The skill marks every claim with `[INTERNAL]` or `[EXTERNAL_OK]`.
- `references/competitor-list.md` — slugs, aliases, product modules to differentiate, and the sales motion each competitor leads with.

## Method

Run these five steps in order. The skill does not parallelize; later steps consume context from earlier ones.

### 1. Pull the call corpus

Query Gong for every call in the lookback window where the competitor or one of its aliases (per `competitor-list.md`) is mentioned. Pull call ID, deal ID, call date, and the transcript snippet around each mention (60 seconds of context each side). Hard cap at 200 calls; if the result exceeds, narrow the window before sampling.

### 2. Reconcile to Salesforce outcomes

Join each call's deal ID against Salesforce Opportunity. Bucket calls into: `won` (Closed Won, this competitor named), `lost` (Closed Lost, this competitor named in the loss reason or as primary competitor), `open` (still in pipeline), `unknown` (no Opportunity match).

Drop the `unknown` bucket from synthesis — selection bias is too high. Track the count and report it as a data-quality footnote.

### 3. Extract loss patterns from `lost`

Two-pass extraction. First pass: for each lost-deal transcript snippet, classify the objection into one of the canonical patterns from `objection-talk-track-library.md` or `other`. Second pass: for the `other` bucket, propose new pattern candidates only if the same theme appears in 3+ deals; below that threshold, list as raw quotes without generalisation. Three-deal threshold exists because anything lower is noise dressed as signal.

### 4. Extract win patterns from `won`

Same two-pass approach against the won bucket. The deciding-factor quote ("we picked you because…") is the highest-signal artifact; prioritise quotes where the customer explicitly contrasts with the competitor. Surface these verbatim in the card with the call ID for verification.

### 5. Assemble the card

Fill the skeleton from `battlecard-format.md`. For each objection in the talk-track section, pull the matching handler from the library and adapt it with the competitor-specific evidence found in steps 3-4. Mark every line with `[INTERNAL]` or `[EXTERNAL_OK]` per the classification rules. End with a "what changed since last refresh" diff if `prior_card_path` was provided.

## Output format

```markdown
# Battlecard — {Competitor display name}

_Generated {YYYY-MM-DD} from {N won} / {N lost} / {N open} calls in last {lookback_days}d._
_Data quality: {N unknown} calls dropped (no SFDC match)._

## Positioning summary [INTERNAL]

One paragraph: how this competitor frames itself today, the segment
they lead with, the wedge they price aggressively. Trace each claim to
a public source URL (their pricing page, a recent blog post, a G2
update) so the next refresh can re-check.

## Where we win [INTERNAL]

| Pattern | Deal count | Representative quote (call ID) |
|---|---|---|
| {Pattern 1} | {N} | "{quote}" ({call-id}) |
| {Pattern 2} | {N} | "{quote}" ({call-id}) |

## Where we lose [INTERNAL]

| Pattern | Deal count | Representative quote (call ID) |
|---|---|---|
| {Pattern 1} | {N} | "{quote}" ({call-id}) |
| {Pattern 2} | {N} | "{quote}" ({call-id}) |

## Talk-tracks [EXTERNAL_OK unless flagged]

### Objection: "{Objection 1, customer wording}"

**Handler:** {2-3 sentence rep response, no FUD, no comparative claim
unless cited from a public competitor source.} [EXTERNAL_OK]

**Evidence (internal):** {customer quote from won deal} ({call-id}) [INTERNAL]

### Objection: "{Objection 2}"

(same shape)

## Traps to avoid [INTERNAL]

- {Trap 1: a misstep reps make against this competitor — e.g. matching
  on a feature where the competitor is genuinely stronger.} Guard:
  {what to do instead}.
- {Trap 2}. Guard: {what to do instead}.

## Sources

- Competitor public pages: {URL, fetched YYYY-MM-DD}
- Gong calls: {N} calls, IDs available in appendix
- Salesforce report: {report ID or filter}

## What changed since {prior-card date} (if prior_card_path provided)

- New: {pattern that has appeared since last refresh}
- Faded: {pattern that no longer appears}
- Shifted: {pattern that is now larger or smaller in deal count}
```

## Watch-outs

- **Defamation risk.** Every comparative claim about the competitor's product, pricing, or support must trace to a public source the competitor has shipped (their pricing page, a published case study, an SEC filing). Guard: the skill rejects any `[EXTERNAL_OK]` line that does not carry a source URL fetched in this run; flips it to `[INTERNAL]` and logs the reason.
- **Stale public data.** Competitor pricing pages change without notice and a battlecard built on a 6-month-old screenshot will embarrass the rep on the call. Guard: the skill records the `fetched` date next to every public-source URL; if any source is older than 30 days at generation time, the card prepends a "verify before use" banner.
- **FUD versus fact.** Reps want one-liners that crush the competitor; Claude is happy to oblige unless constrained. Guard: the skill rejects any handler whose subject is the competitor and whose predicate is not directly attributable to a customer quote (won deal) or a public source (competitor's own page). If neither exists, the handler is rewritten in product-positive form ("here is how we do X") rather than competitor-negative form ("they cannot do X").
- **Internal versus customer-facing leakage.** A handler marked `[EXTERNAL_OK]` may still embed an internal-only data point (deal counts, won-against rates, internal pricing benchmarks). Guard: the second pass scans every `[EXTERNAL_OK]` line against the blocklist in `internal-vs-external.md` (deal counts, win rates, customer names not in the public reference list, internal pricing ranges). Matches are auto-redacted with `[REDACTED — internal metric]` and the line stays usable.
- **Selection bias.** Reps under-log the competitor on lost deals — the painful losses are the ones least likely to be tagged. Guard: the data-quality footnote always reports the `unknown` count; whenever it exceeds 20% of pulled calls, the card prepends a "competitor-tagging coverage is low — interpret loss patterns with caution" banner.
- **Quote accuracy.** Gong transcription mangles technical terms and proper nouns. Guard: the skill marks any quote containing a Gong confidence score below 0.85 with `[low-confidence transcript]`; reps are instructed in the format header to verify those before using.

# Battlecard format — TEMPLATE

> This is the literal Markdown skeleton the competitive-battlecard
> skill fills. Section order is load-bearing — reps scan top to bottom
> and stop reading at the first useful line. Keep it that way.

```markdown
# Battlecard — {Competitor display name}

_Generated {YYYY-MM-DD} from {N won} / {N lost} / {N open} calls in last {lookback_days}d._
_Data quality: {N unknown} calls dropped (no SFDC match)._
_Verify before use: any source older than 30 days is flagged inline._

## Positioning summary [INTERNAL]

One paragraph. How they frame themselves today, the segment they lead
with, the wedge they price aggressively. Each claim cites a public
source URL with a `fetched` date.

## Where we win [INTERNAL]

| Pattern | Deal count | Representative quote (call ID) |
|---|---|---|
|  |  |  |

## Where we lose [INTERNAL]

| Pattern | Deal count | Representative quote (call ID) |
|---|---|---|
|  |  |  |

## Talk-tracks

### Objection: "{customer wording}"

**Handler [EXTERNAL_OK]:** rep response, 2-3 sentences, no FUD.

**Evidence [INTERNAL]:** customer quote from a won deal (call ID).

(repeat per objection — pricing, integration, migration, support,
security at minimum if patterns exist)

## Traps to avoid [INTERNAL]

- Trap: …  Guard: …
- Trap: …  Guard: …

## Sources

- Public pages: URL, fetched YYYY-MM-DD
- Gong calls: N calls, IDs in appendix
- Salesforce report: report ID or saved filter

## What changed since {prior-card date}

- New: …
- Faded: …
- Shifted: …

## Appendix — call IDs

{flat list of Gong call IDs grouped by bucket: won / lost / open}
```

## Authoring rules for whoever fills this

- Every line carries either `[INTERNAL]` or `[EXTERNAL_OK]`. No line is unmarked. The internal-vs-external classifier in `references/internal-vs-external.md` decides borderline cases.
- Quotes are verbatim. Cleaning up grammar is fine; rewording the meaning is not.
- Deal counts are always raw integers, never percentages. "12 of 47 lost deals" not "26% of losses" — the denominator is meaningful.
- Public-source claims always carry a fetched-date next to the URL. Without it the next refresh has no anchor for diffing.
- Section order is fixed. Do not reorder; reps build muscle memory.

## Last edited

{YYYY-MM-DD} — bump on every material edit so the skill can warn when the format itself is stale.

# Objection talk-track library — TEMPLATE

> Replace this template's contents with your team's actual canonical
> handlers. The competitive-battlecard skill matches incoming
> objections from Gong against these patterns rather than inventing
> handlers per run. That is what keeps tone consistent across
> battlecards and across reps.

The library is organised by objection pattern. Each pattern has:

- The pattern name (used as the slug the skill matches against)
- The customer wording variants the skill should treat as the same pattern
- The canonical handler (the rep response)
- The evidence requirement (what must back the handler before it can ship as `[EXTERNAL_OK]`)
- The escalation path (when to bring in PMM, SE, or product)

## Pattern: pricing-aggression

**Customer wording variants:**

- "Competitor X is half the price."
- "We got a quote from {competitor} that was significantly lower."
- "Your list price is hard to justify versus {competitor}."

**Canonical handler:**

> "{Competitor} prices on {their model — per seat / per usage / etc.};
> our pricing reflects {one differentiator that maps to outcome, e.g.
> the integration depth that removes the second tool from your stack}.
> Happy to walk through TCO with your finance partner — most teams
> find the comparison flips once {specific cost line} is included."

**Evidence requirement:**

- Public competitor pricing page URL with fetched date, OR
- Customer quote from a won deal where TCO was the deciding factor.

If neither, the handler ships as `[INTERNAL]` and the rep adapts live.

**Escalation:** finance-partnered TCO model — bring in PMM if the pattern repeats across 5+ deals in 30 days.

## Pattern: integration-depth

**Customer wording variants:**

- "Does this integrate with {tool}?"
- "{Competitor} already has a {tool} integration."
- "We need this to work with our existing stack on day one."

**Canonical handler:**

> "We integrate with {tool} via {mechanism — native, API, Zapier — be
> specific}. The differences worth knowing: {1-2 concrete capability
> gaps or strengths}. Happy to show the integration in a working
> environment before you commit."

**Evidence requirement:**

- Public integration directory URL on our own site, OR
- Working demo environment the SE can spin up in under an hour.

## Pattern: migration-effort

**Customer wording variants:**

- "We just moved to {competitor} last year."
- "Migrating off {competitor} would be painful."
- "What does it take to switch?"

**Canonical handler:**

> "Migration off {competitor} typically takes {realistic range based
> on prior migrations}. The blockers we see most often: {1-2 specific
> ones}. We have a migration playbook for {competitor} specifically —
> {customer name from public reference list} did this in {timeframe}."

**Evidence requirement:**

- Public case study from a customer who migrated, OR
- Internal migration playbook the SE can walk through.

## Pattern: support-quality

**Customer wording variants:**

- "We've heard your support is slow."
- "{Competitor} has 24/7 support included."
- "Who do we call at 2am?"

**Canonical handler:**

> "Our support tiers are {list — be specific about response time
> SLAs}. For {customer's tier}, the SLA is {time}. Two named contacts
> on the customer success side, plus the in-app chat backed by our
> product engineers."

**Evidence requirement:**

- Public support SLA page URL with fetched date.

Never say anything about the competitor's support quality unless quoting a customer who came from that competitor and was on the record.

## Pattern: security-and-compliance

**Customer wording variants:**

- "Are you SOC 2?"
- "{Competitor} has FedRAMP."
- "Our security team has concerns."

**Canonical handler:**

> "We hold {list certifications, be exact}. The trust portal at {URL}
> has the current attestations and the security questionnaire. For
> the specific concern your team raised, the right person to bring in
> is {role — typically the security CSM or the CISO's office}."

**Evidence requirement:**

- Public trust portal URL with fetched date and the actual certifications listed.

## Pattern: feature-gap (genuine)

**Customer wording variants:**

- "{Competitor} has {feature} and you don't."

**Canonical handler:**

> "Correct, we do not have {feature} today. The reason is {real
> product reasoning — not 'on the roadmap'}. The way customers
> typically solve {underlying need} on our platform is {workaround
> with one named customer reference if available}. If that does not
> meet your need, I would rather flag that now than discover it in
> month three."

**Evidence requirement:**

- Internal product confirmation that the gap is real and the workaround is genuine.

This handler is the exception: it is intentionally honest about a gap. The traps-to-avoid section in the battlecard skeleton exists partly to remind reps not to fight battles they will lose — guard against pretending parity where none exists.

## Last edited

{YYYY-MM-DD}

# Internal-vs-external classification rules — TEMPLATE

> Replace this template's contents with your team's actual rules. The
> competitive-battlecard skill stamps every line of every battlecard
> with `[INTERNAL]` or `[EXTERNAL_OK]` per these rules. The
> classification is not advisory — `[INTERNAL]` lines are stripped
> from any export the rep shares with a customer.

## Default

Default classification is `[INTERNAL]`. A line is upgraded to `[EXTERNAL_OK]` only if it passes every rule below.

## Allowed `[EXTERNAL_OK]`

A line may be classified `[EXTERNAL_OK]` if all of these are true:

1. **No internal-only metric appears.** The blocklist below is exhaustive for our team. If any blocklist term appears, the line stays `[INTERNAL]`.
2. **Any comparative claim about the competitor traces to a public source.** The source URL is in the line or in the same bullet, with a `fetched` date no older than 30 days at generation time.
3. **No customer name appears unless that customer is on the public reference list** at `/legal/public-references.json` (or the equivalent in your CRM).
4. **No FUD.** The handler does not assert anything negative about the competitor's product, support, security, or company that is not directly attributable to a public source the competitor has shipped or to a customer the customer can call.

## Blocklist (these terms force `[INTERNAL]`)

Any line containing any of the following stays internal:

- Deal counts in absolute numbers (e.g. "we won 47 of 89 deals")
- Win rates as percentages
- Internal pricing ranges, discount thresholds, list-vs-paid deltas
- Customer names not on the public reference list
- ARR, MRR, ACV figures
- Internal codenames for products, projects, or initiatives
- Slack channels, Notion URLs, internal Gong call IDs
- Roadmap items not announced publicly
- Personnel names and reporting lines
- The phrase "we always" or "we never" applied to the competitor unless backed by a public source URL in the same line

## Borderline cases — the skill's behaviour

When a line is borderline, the skill defaults to `[INTERNAL]` and logs the reason in the appendix. PMM can flip it on review.

Examples of borderline cases the skill has hit historically:

- A handler that quotes a customer in a public case study but paraphrases the quote — flip to verbatim or mark `[INTERNAL]`.
- A pricing comparison that uses our own price list but the competitor's price is from a screenshot dated two months ago — the competitor side is stale, mark `[INTERNAL]` until refreshed.
- A capability claim about the competitor that is true but stated as "they can't do X" rather than "X is not on their public roadmap" — rewrite or mark `[INTERNAL]`.

## Auto-redaction

If the second pass finds a blocklist term inside an otherwise qualifying `[EXTERNAL_OK]` line, the term is replaced with `[REDACTED — internal metric]` and the line stays `[EXTERNAL_OK]`. This keeps the talk-track usable without leaking the underlying number.

Example before redaction:

> "We win against {Competitor} 73% of the time when integration depth
> is the deciding factor."

After:

> "We win against {Competitor} [REDACTED — internal metric] when
> integration depth is the deciding factor."

The handler is now usable in front of a customer without the win rate leaking.

## Reporting

Every battlecard generation logs a count of:

- Lines emitted as `[EXTERNAL_OK]`
- Lines downgraded from `[EXTERNAL_OK]` to `[INTERNAL]` and the reason
- Lines auto-redacted and the term that triggered the redaction

The log lives at the bottom of the card under "Classification audit" so PMM and legal can review.

## Last edited

{YYYY-MM-DD}