Um Claude Skill que recebe o domínio de uma empresa e produz um brief de conta estruturado: snapshot da empresa, prioridades estratégicas extraídas de earnings calls ou notícias recentes, sinais do stack tecnológico, personas-chave com suas linhas de reporte, e três hipóteses de pain points mapeadas ao seu produto. Rode antes de cada call de discovery.
O que você vai precisar
Claude.ai ou Claude Code com web fetch habilitado
Um domínio de empresa ou URL do LinkedIn como input
Seu documento de positioning do produto (one-pager) carregado na pasta do Skill
Opcional: uma fonte paga de signals como Apollo ou BuiltWith para dados de stack
Setup
Coloque o Skill no Claude. Salve o diretório account-research.skill em ~/.claude/skills/ (Claude Code) ou importe num projeto do Claude.ai. O Skill expõe research_account(domain) como entrypoint.
Carregue os arquivos de contexto. Coloque seu one-pager, rubric de ICP e lista de competidores no subdiretório references/ do Skill. O Skill lê eles em cada execução para que o brief fique ancorado no seu positioning, e não em research genérico de AE.
Configure o formato de saída. A saída padrão é um brief em Markdown com cinco seções. Edite SKILL.md se seu time prefere blocos do Notion, um Google Doc ou um resumo pro Slack.
Rode numa conta de teste.claude run research_account --domain acme.com. Inspecione o brief e refine os prompts em SKILL.md até a saída casar com o que seus melhores AEs escreveriam à mão.
Como funciona
O Skill roda quatro sub-tarefas em sequência. Primeiro, faz fetch da homepage, página About e página de careers da empresa para construir o snapshot. Segundo, busca transcripts de earnings, releases ou anúncios de funding dos últimos 90 dias para mostrar prioridades estratégicas. Terceiro, puxa dados públicos do LinkedIn sobre o comitê de compra — títulos típicos de RevOps, Marketing Ops e Sales Ops — e registra tempo de casa e empresas anteriores. Quarto, sintetiza hipóteses de pain cruzando o snapshot contra seu documento de positioning.
A saída é deliberadamente opinativa. Em vez de despejar fatos, o Skill ranqueia os três pontos de entrada mais prováveis e sugere uma pergunta de discovery para cada um. Os reps podem adotar, editar ou rejeitar — mas sempre partem de uma tese, não de uma página em branco.
Pontos de atenção
Dados públicos defasados. O scraping do LinkedIn quebra com frequência e os transcripts de earnings ficam um trimestre atrás. Se frescor importa, coloque uma fonte paga como ZoomInfo ou Apollo na entrada.
Org charts alucinados. O Claude inventa linhas de reporte se você forçar. Restrinja a seção de personas a títulos de fato visíveis no LinkedIn ou no site da empresa, e exija uma citação por cada nome.
Drift de positioning. Se seu one-pager tem seis meses, as hipóteses de pain refletem mensagem antiga. Re-sincronize o diretório de references sempre que o marketing atualizar o positioning.
Stack
Claude — orquestração, web fetch e síntese
Apollo ou BuiltWith (opcional) — sinais de stack e headcount
---
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.