Un Claude Skill qui prend un domaine d’entreprise et produit un brief de compte structuré : aperçu de l’entreprise, priorités stratégiques extraites des transcriptions d’appels de résultats ou de la presse récente, signaux sur le stack technologique, personas clés et leurs lignes hiérarchiques, et trois hypothèses de points de douleur mappés sur votre produit. À lancer avant chaque appel de découverte.
Ce dont vous aurez besoin
Claude.ai ou Claude Code avec web fetch activé
Un domaine d’entreprise ou une URL LinkedIn comme input
Votre doc de positionnement produit (1-pager) chargé dans le dossier du Skill
Optionnel : une source de signaux payante comme Apollo ou BuiltWith pour les données de stack
Configuration
Déposez le Skill dans Claude. Sauvegardez le répertoire account-research.skill dans ~/.claude/skills/ (Claude Code) ou importez-le dans un projet Claude.ai. Le Skill expose research_account(domain) comme point d’entrée.
Chargez les fichiers de contexte. Placez votre one-pager, la rubrique ICP et la liste de concurrents dans le sous-répertoire references/ du Skill. Le Skill les lit à chaque exécution pour que le brief soit ancré dans votre positionnement, pas dans une recherche AE générique.
Configurez le format de sortie. La sortie par défaut est un brief Markdown avec cinq sections. Modifiez SKILL.md si votre équipe préfère des blocs Notion, un Google Doc ou un résumé adapté à Slack.
Lancez sur un compte test.claude run research_account --domain acme.com. Inspectez le brief, puis affinez les prompts dans SKILL.md jusqu’à ce que le résultat corresponde à ce que vos meilleurs AE écriraient à la main.
Comment ça fonctionne
Le Skill exécute quatre sous-tâches en séquence. D’abord, il récupère la page d’accueil, la page À propos et la page Carrières de l’entreprise pour construire un aperçu. Deuxièmement, il recherche des transcriptions d’appels de résultats récents, des communiqués de presse ou des annonces de financement des 90 derniers jours pour faire remonter les priorités stratégiques. Troisièmement, il extrait les données LinkedIn publiques sur le comité d’achat — titres RevOps, Marketing Ops et Sales Ops typiques — et note l’ancienneté et les entreprises précédentes. Quatrièmement, il synthétise les hypothèses de douleur en croisant l’aperçu avec votre doc de positionnement.
La sortie est délibérément opinionée. Plutôt que de déverser des faits, le Skill classe les trois points d’entrée les plus probables et suggère une question de découverte pour chacun. Les commerciaux peuvent adopter, modifier ou rejeter — mais ils partent toujours d’une thèse, pas d’une page blanche.
Points de vigilance
Données publiques périmées. Le scraping LinkedIn se casse fréquemment et les transcriptions d’appels de résultats ont un trimestre de retard. Si la fraîcheur compte, intégrez en amont une source payante comme ZoomInfo ou Apollo.
Organigrammes hallucinés. Claude inventera des lignes hiérarchiques si on le pousse. Limitez la section personas aux titres réellement visibles sur LinkedIn ou le site de l’entreprise, et exigez une citation pour chaque nom.
Dérive du positionnement. Si votre one-pager a six mois, les hypothèses de douleur refléteront d’anciens messages. Resynchronisez le répertoire references/ chaque fois que le marketing met à jour le positionnement.
Stack
Claude — orchestration, web fetch et synthèse
Apollo ou BuiltWith (optionnel) — signaux sur le stack technologique et les effectifs
---
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.