Un Claude Skill que toma el dominio de una empresa y produce un brief de cuenta estructurado: snapshot de la empresa, prioridades estratégicas extraídas de earnings calls o noticias recientes, señales del stack tecnológico, personas clave con sus líneas de reporte, y tres hipótesis de pain points mapeadas a tu producto. Ejecútalo antes de cada llamada de discovery.
Qué necesitas
Claude.ai o Claude Code con web fetch habilitado
Un dominio de empresa o URL de LinkedIn como input
Tu documento de positioning del producto (one-pager) cargado en la carpeta del Skill
Opcional: una fuente de signals de pago como Apollo o BuiltWith para datos de stack
Setup
Coloca el Skill en Claude. Guarda el directorio account-research.skill en ~/.claude/skills/ (Claude Code) o impórtalo a un proyecto de Claude.ai. El Skill expone research_account(domain) como entrypoint.
Carga los archivos de contexto. Coloca tu one-pager, rubric de ICP y lista de competidores en el subdirectorio references/ del Skill. El Skill los lee en cada ejecución para que el brief esté anclado en tu positioning, no en research genérico de AE.
Configura el formato de salida. El output por defecto es un brief en Markdown con cinco secciones. Edita SKILL.md si tu equipo prefiere bloques de Notion, un Google Doc o un resumen para Slack.
Ejecuta en una cuenta de prueba.claude run research_account --domain acme.com. Inspecciona el brief y refina los prompts en SKILL.md hasta que la salida coincida con lo que escribirían tus mejores AEs a mano.
Cómo funciona
El Skill ejecuta cuatro sub-tareas en secuencia. Primero, hace fetch de la homepage, página About y página de careers de la empresa para construir el snapshot. Segundo, busca transcripts de earnings, comunicados de prensa o anuncios de funding de los últimos 90 días para mostrar prioridades estratégicas. Tercero, extrae datos públicos de LinkedIn sobre el comité de compra — títulos típicos de RevOps, Marketing Ops y Sales Ops — y registra antigüedad y empresas previas. Cuarto, sintetiza hipótesis de pain cruzando el snapshot contra tu documento de positioning.
La salida es deliberadamente opinada. En lugar de volcar datos, el Skill ranquea los tres puntos de entrada más probables y sugiere una pregunta de discovery para cada uno. Los reps pueden adoptar, editar o rechazar — pero siempre arrancan desde una tesis, no desde una página en blanco.
A tener en cuenta
Datos públicos desactualizados. El scraping de LinkedIn se rompe seguido y los transcripts de earnings tienen un trimestre de retraso. Si la frescura importa, agrega arriba una fuente de pago como ZoomInfo o Apollo.
Org charts alucinados. Claude inventa líneas de reporte si lo presionas. Restringe la sección de personas a títulos efectivamente visibles en LinkedIn o el sitio de la empresa, y exige una citación por cada nombre.
Drift de positioning. Si tu one-pager tiene seis meses, las hipótesis de pain reflejarán mensajes viejos. Re-sincroniza el directorio de references cada vez que marketing actualice el positioning.
Stack
Claude — orquestación, web fetch y síntesis
Apollo o BuiltWith (opcional) — señales de stack y 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.