Eine Claude Skill, die eine Unternehmens-Domain entgegennimmt und einen strukturierten Account-Brief erstellt: Unternehmens-Snapshot, strategische Prioritäten aus Earnings-Calls oder aktueller Presse, Tech-Stack-Signale, wichtige Personas mit ihren Berichtslinien sowie drei hypothetisierte Pain Points, die Ihrem Produkt zugeordnet sind. Führen Sie sie vor jedem Discovery-Call aus.
Was Sie benötigen
Claude.ai oder Claude Code mit aktiviertem Web Fetch
Eine Unternehmens-Domain oder LinkedIn-URL als Input
Ihr Produkt-Positioning-Dokument (1-Pager), das in den Skill-Ordner geladen wurde
Optional: eine kostenpflichtige Signal-Quelle wie Apollo oder BuiltWith für Stack-Daten
Setup
Skill in Claude einspielen. Speichern Sie das Verzeichnis account-research.skill unter ~/.claude/skills/ (Claude Code) oder importieren Sie es in ein Claude.ai-Projekt. Die Skill stellt research_account(domain) als Einstiegspunkt bereit.
Kontextdateien laden. Legen Sie Ihren One-Pager, Ihr ICP-Rubrik und Ihre Competitor-Liste im Unterverzeichnis references/ der Skill ab. Die Skill liest diese bei jedem Durchlauf, sodass der Brief in Ihrem Positioning verankert ist und keine generische AE-Recherche darstellt.
Ausgabeformat konfigurieren. Das Standard-Output ist ein Markdown-Brief mit fünf Abschnitten. Bearbeiten Sie SKILL.md, wenn Ihr Team Notion-Blocks, ein Google Doc oder eine Slack-freundliche Zusammenfassung bevorzugt.
Mit einem Test-Account ausführen.claude run research_account --domain acme.com. Prüfen Sie den Brief und verfeinern Sie dann die Prompts in SKILL.md, bis der Output dem entspricht, was Ihre besten AEs von Hand schreiben würden.
Funktionsweise
Die Skill führt vier Teilaufgaben der Reihe nach aus. Zuerst ruft sie die Homepage, die Über-uns-Seite und die Karriereseite des Unternehmens ab, um einen Snapshot zu erstellen. Zweite Aufgabe: Sie sucht nach aktuellen Earnings-Transcripts, Pressemitteilungen oder Finanzierungsankündigungen der letzten 90 Tage, um strategische Prioritäten zu identifizieren. Dritte Aufgabe: Sie zieht öffentliche LinkedIn-Daten zum Buying Committee – typischerweise RevOps-, Marketing Ops- und Sales Ops-Titel – und notiert Betriebszugehörigkeit und frühere Unternehmen. Viertens synthetisiert sie Pain-Hypothesen, indem sie den Snapshot mit Ihrem Positioning-Dokument abgleicht.
Der Output ist bewusst meinungsstark. Statt Fakten zu häufen, priorisiert die Skill die drei wahrscheinlichsten Einstiegspunkte und schlägt für jeden eine Discovery-Frage vor. Reps können diese übernehmen, bearbeiten oder ablehnen – aber sie starten immer mit einer These, nicht mit einem leeren Blatt.
Wichtige Hinweise
Veraltete öffentliche Daten. LinkedIn-Scraping bricht häufig ab, und Earnings-Transcripts hinken ein Quartal hinterher. Wenn Aktualität wichtig ist, schalten Sie vorgelagert eine kostenpflichtige Quelle wie ZoomInfo oder Apollo ein.
Halluzinierte Organigramme. Claude erfindet Berichtslinien, wenn es dazu gedrängt wird. Schränken Sie den Persona-Bereich auf Titel ein, die tatsächlich auf LinkedIn oder der Unternehmenswebsite sichtbar sind, und fordern Sie für jeden Namen ein Quellenangabe an.
Positioning-Drift. Wenn Ihr One-Pager sechs Monate alt ist, spiegeln die Pain-Hypothesen altes Messaging wider. Synchronisieren Sie das Verzeichnis references/ neu, sobald das Marketing das Positioning aktualisiert.
Stack
Claude — Orchestrierung, Web Fetch und Synthese
Apollo oder BuiltWith (optional) — Tech-Stack- und Headcount-Signale
---
name: account-research
description: Research a target account and produce a structured pre-discovery brief. Use this skill before every discovery call to ground the AE in company snapshot, strategic priorities, persona map, and three pain hypotheses tied to your product.
---
# Account research
## When to invoke
Whenever you need a pre-call brief on a B2B account: before discovery, before a renewal conversation, before a strategic review, before prepping a stakeholder map. Take a company domain or LinkedIn URL as input and produce a structured Markdown brief.
Do NOT invoke this skill for:
- Personal-name research on individuals (privacy)
- Public-company financial analysis (use a finance tool)
- Anything that requires paid data sources you do not have configured
## Inputs
- Required: `domain` — the company's primary domain (e.g. `acme.com`) or a LinkedIn company URL
- Optional: `focus` — a free-text hint about the deal context (e.g. "expansion of existing logo, focus on Marketing Ops persona")
- Optional: `comparison` — slug of a competitor whose presence you want flagged
## Reference files
Always read the following from `references/` before generating the brief. They contain the user's positioning and ICP rubric — without them, the brief is generic.
- `references/positioning-template.md` — the user's product one-pager (replace contents with your actual positioning)
- `references/icp-rubric-template.md` — the rubric the brief uses to rank pain hypotheses (replace contents with your actual rubric)
## Method
Run these four sub-tasks in order. Do not parallelize — later steps depend on context from earlier steps.
### 1. Snapshot
Fetch the company homepage, About page, and careers page. Extract:
- One-sentence company summary (industry, scale signal, core offering)
- Headcount range (from About or LinkedIn, never invented)
- Geographic footprint (HQ + notable offices)
- Notable customers or markets they cite publicly
If a fetch fails (404, paywall, etc.), record "unavailable" rather than guessing.
### 2. Strategic priorities
Search for: earnings transcripts, press releases, blog posts, funding announcements from the last 90 days. Also: changes to their About page (if available via web archive).
Output: 3-5 strategic priorities, each with a citation (URL + brief quote). If no recent signal, write "no recent strategic signal found" — do not invent priorities.
### 3. Persona map
For each ICP-relevant role at this company (RevOps, Marketing Ops, Sales Ops, IT — adjust to your ICP from the rubric), find:
- Current incumbent's name and title (from LinkedIn — only if public-visible)
- Tenure in role
- Prior company
Constraint: never invent reporting lines. If you cannot see "X reports to Y" in public data, write "reporting line not public." Hallucinated org charts is the failure mode this section guards against.
### 4. Pain hypotheses
Cross-reference the snapshot, strategic priorities, and persona map against the positioning doc and ICP rubric. Produce three pain hypotheses, ranked. For each:
- The pain (one sentence)
- The signal that supports it (cite snapshot or priority)
- The discovery question that would confirm it (single, specific)
Constraint: every hypothesis must trace to evidence in section 1, 2, or 3. If you cannot produce three evidenced hypotheses, produce two or one. Never pad.
## Output format
```markdown
# Account brief — {Company name}
## Snapshot
- Industry: ...
- Scale: ...
- Geo: ...
- Notable customers: ...
## Strategic priorities (last 90 days)
1. ... [citation]
2. ... [citation]
3. ... [citation]
## Persona map
| Role | Name | Tenure | Prior |
|---|---|---|---|
| RevOps | ... | ... | ... |
Reporting lines: not public.
## Pain hypotheses
1. **{Pain}.** Signal: {evidence}. Ask: "{discovery question}"
2. ...
3. ...
## Sources
- {URL 1}
- {URL 2}
```
## Watch-outs
- **LinkedIn scraping breaks frequently.** When persona data is unavailable, surface that openly rather than synthesizing names.
- **Earnings transcripts lag.** A "last 90 days" claim is honored only by date-stamped sources. Note publication dates in citations.
- **Positioning drift.** The brief reflects the positioning doc as loaded. If positioning was updated more than 6 months ago, prepend a one-line note: "Positioning doc may be stale (last edited {date})."
- **Don't write the deal strategy.** This skill produces a brief. The AE writes the strategy.
# ICP rubric — TEMPLATE
> Replace this template's contents with your team's actual ICP rubric.
> The account-research skill uses this to rank pain hypotheses against
> the right buying-committee shape.
## Firmographics
| Dimension | In-ICP | Stretch | Out |
|---|---|---|---|
| Industry | {list} | {list} | {list} |
| Headcount | {range} | {range} | {below/above} |
| Revenue | {range} | {range} | {below/above} |
| Geo | {regions} | {regions} | {regions} |
| Funding stage | {stages} | {stages} | {stages} |
## Technographics
Tools that signal a fit (we win when they have these):
- {Tool 1}
- {Tool 2}
- {Tool 3}
Tools that signal misfit (we lose to or against these):
- {Tool A}
- {Tool B}
## Buying committee — minimum viable
The roles that must exist for a deal to be qualified. The skill uses this in the persona-map section.
- **Economic buyer**: {title pattern}
- **Technical evaluator**: {title pattern}
- **End user**: {title pattern}
- **Champion target**: {title pattern}
## Pain ranking
When the skill ranks the three pain hypotheses, it weighs against this priority order. Higher = more important to surface first.
1. {Pain category — e.g. "data quality blocking outbound"} — weight 5
2. {Pain category — e.g. "manual reporting eating ops time"} — weight 4
3. {Pain category — e.g. "sales-marketing handoff friction"} — weight 3
4. {Pain category — e.g. "tooling sprawl"} — weight 2
5. {Pain category — e.g. "compliance overhead"} — weight 1
## Disqualifiers
Single signals that drop an account out of ICP regardless of other fit. The skill should flag these prominently in the brief if found.
- {Disqualifier 1 — e.g. "uses Tool X as system of record" if we cannot integrate}
- {Disqualifier 2 — e.g. "regulated industry without our compliance certifications"}
## Last edited
{YYYY-MM-DD}
# Positioning one-pager — TEMPLATE
> Replace this template's contents with your actual positioning. The
> account-research skill reads this file on every run; without your
> real positioning, the brief output is generic.
## Who we serve
We serve {ICP definition: industry, headcount band, motion}. We do not serve {anti-ICP: who would technically buy us but should not}.
## Problem we solve
The {persona} at {ICP company} is responsible for {outcome}. They fail today because {root cause — typically a tooling, process, or data gap}. The cost of that failure is {quantified — revenue, retention, headcount, regulatory risk}.
## How we solve it
Three to five bullets. Each bullet ties to one capability of the product, in the customer's language not ours. Avoid feature lists.
- {Capability 1 → outcome}
- {Capability 2 → outcome}
- {Capability 3 → outcome}
## Wedge use case
The single use case we lead with in discovery. The one where we win 80% of the time. Describe it in one paragraph.
## Common misuses
What we do NOT solve, even though buyers sometimes wish we did. Listing this protects against losing late-stage deals when reality hits.
- {Misuse 1}
- {Misuse 2}
## Proof points
Two to four. Each: customer name (anonymized if required), the outcome, the metric.
- {Customer 1}: {outcome} ({metric}).
- {Customer 2}: {outcome} ({metric}).
## Competitive frame
How we differ from the top 2-3 alternatives. One sentence each, no disparagement, no FUD. The brief uses this for the optional `comparison` parameter.
- vs. {Competitor 1}: {one-sentence differentiation}
- vs. {Competitor 2}: {one-sentence differentiation}
- vs. {Status quo / DIY}: {one-sentence differentiation}
## Pricing posture
The model (per-seat, usage, hybrid) and the rough range. The skill uses this only when the user passes a "budget question" focus hint; otherwise it's reference context.
## Last edited
{YYYY-MM-DD} — update on every material change so the brief can warn when the doc is stale.