Account Research Brief Generator

Account Research Brief Generator

> A repeatable framework for turning a company name into a BDR-ready research brief > in 10-60 minutes depending on tier. Reduces inconsistent manual research by > giving BDRs a tier-calibrated workflow that produces a standardized brief > across researchers, accounts, and outreach waves.

Why This Skill Exists

Most account research is wasted work. BDRs spend an hour on a single account, find three usable insights, and the rest of the data dies in a Notion doc no one reads. By the time outreach starts, half the intel is stale and none of it ties to a specific message angle.

This skill fixes three failure modes:

1. Inconsistent depth across accounts. Tier-1 accounts get 90 minutes of

research; tier-2 accounts get 10. The brief format here scales depth to tier without losing structure.

1. Research that doesn't drive outreach. Generic "they raised a Series B"

notes don't tell a BDR what to say. Every section in this brief ends with a "so what" — the implication for messaging.

1. No reusable artifact. Each researcher works from scratch. This skill

produces a standardized brief that can be reviewed, refined, and reused across multiple outreach waves.

When to Use This Skill

• Preparing outreach for a specific named account (single brief)
• Building research packets for a tier-1 ABM cohort (batch briefs)
• Onboarding a new BDR with their first account list
• Refreshing intel on accounts re-entering active outreach after 60+ days
• Pre-call research for sales discovery on a recycled pipeline account
• Building "account snapshots" for executive sponsor outreach
• Validating that an account on the target list actually fits the ICP after research

When NOT to Use This Skill

• Building the target account list itself (use abm-program-orchestrator for list construction)
• Writing the outreach sequences (use bdr-enablement-generator after research is done)
• Mass-research on 1000+ accounts (this is a depth tool, not a breadth tool — use intent data platforms for breadth)
• Customer research for expansion (different motion; expansion needs usage data, not external signals)
• Competitive battlecards (use competitive-battlecard-generator)

Boundary With bdr-enablement-generator

These two skills are deliberately separated:

• account-research-brief-generator = the account intelligence layer. Produces sourced research output ending in an outreach hypothesis. Stops before any sequences are written.
• bdr-enablement-generator = the outreach execution layer. Takes a finished brief as input and produces sequences, talk tracks, and objection handlers.

If you find yourself writing email copy in this skill, stop. That's the next skill in the stack.

How This Skill Fits Into the Skill Stack

abm-program-orchestrator         →  Gives you the prioritized account list
   ↓
account-research-brief-generator →  Produces the BDR-ready intelligence brief  ← YOU ARE HERE
   ↓
bdr-enablement-generator         →  Turns the brief into outreach sequences
   ↓
grc-messaging-guardrails         →  Validates compliance terminology in the output

Run this skill after the target account list is set and before sequences are written.

---

Phase 1: Inputs and Tier Calibration

The brief's depth scales with account tier. Don't research a tier-3 account at tier-1 depth — that's how teams burn 40 hours/week on research and ship nothing.

Required Inputs

Before generating a brief, gather:

| Input | Why It Matters | Source | |---|---|---| | Company legal name + domain | Disambiguates between similar-named companies | Account list | | Tier (1, 2, or 3) | Determines research depth | ABM program design | | ACV target ($) | Calibrates effort against deal value | ICP / opportunity sizing | | Primary persona to engage | Focuses the "so what" against one buyer | ICP / persona doc | | Compliance frameworks relevant (SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR) | Anchors the GRC angle | Discovery from public signals | | Trigger event (if any) | The reason this account is being prioritized now | Intent data, news, sales input |

First-Party and Second-Party Signal Inputs (Required When Available)

Public signals alone produce generic briefs. The "why now" hypothesis gets sharper when first-party and second-party signals feed Section 3 (Trigger Events).

| Signal Source | Type | What It Tells You | |---|---|---| | HubSpot engagement (page views, form fills, email opens) | First-party | Active research happening on your site | | Factors.ai or similar reverse-IP visitor data | First-party | De-anonymized account-level web visits | | G2 buyer intent (category page visits, comparison searches) | Second-party | The account is in active evaluation | | Paid ad engagement (LinkedIn, Google) | First-party | Topic and creative resonance | | BDR/AE prior conversations (recycled pipeline) | First-party | Past pain points, blockers, objections | | Intent platforms (Bombora, 6sense) | Third-party | Topic interest at the account level |

If first-party signals exist for an account, they take precedence over public triggers in Section 3. A real page visit on your pricing page beats a six-month-old funding announcement.

Tier Calibration

| Tier | Research Time | Brief Length | Depth | |---|---|---|---| | Tier 1 (1:1 motion) | 45-60 min | 800-1200 words | All 6 sections, deep on each | | Tier 2 (1:few) | 20-30 min | 400-600 words | All 6 sections, summary on each | | Tier 3 (1:many) | 10-15 min | 200-300 words | Sections 1-3 + Section 6, deeper sections marked "Skipped by tier" |

Note: Tier 3 briefs use the same schema as Tier 1 and Tier 2. Sections that aren't researched at this tier are explicitly marked "Skipped by tier" rather than removed. This preserves the consistent scan-pattern that makes the brief format usable across tiers.

---

Phase 2: The Six-Section Brief Structure

Every brief uses the same six-section schema. Lower tiers may mark selected sections as "Skipped by tier" but the structure stays constant. This consistency matters more than comprehensiveness — BDRs and AEs learn to scan for specific sections, and varying the structure forces them to re-read every brief.

Section 1: Company Snapshot

What goes here. Basic firmographics and current state.

• Company name, HQ, founding year
• Employee count (LinkedIn — useful for directional headcount; verify with secondary sources for high-stakes accounts since LinkedIn data can be stale or inflated)
• Funding stage and total raised (Crunchbase — flag last raise date and amount)
• Revenue (if public; for internal sizing only, can estimate from headcount × $200K-$400K per employee for B2B SaaS — do not use estimated revenue in outreach unless publicly sourced)
• Industry vertical and sub-vertical
• Customer segment (B2B / B2C / both)

So what. One sentence on what this company does and who it sells to. Not their marketing tagline. The actual business model.

> Example: "Series B FinTech B2B SaaS, ~220 employees per LinkedIn, raised $45M > in Sept 2025. Sells fraud detection APIs to mid-market banks and lenders. > Last 18 months: aggressive expansion into EU."

Section 2: GRC and Compliance Surface Area

What goes here. The compliance and security angle. This is where Scrut wins or loses the deal — get this section right.

• Compliance frameworks already publicly committed to (check website footer, trust center, security page)
• Compliance frameworks they likely need but haven't publicly attested to
• Recent compliance-relevant events (audit findings, breach disclosures, regulatory actions)
• Stated security/compliance team size and seniority (LinkedIn search: "Compliance," "GRC," "Security" at the company)
• Use of competing GRC platforms (search G2, LinkedIn job posts mentioning "Vanta," "Drata," "Secureframe," "Tugboat Logic")
• Third-party risk exposure (do they sell into regulated industries? do their customers demand attestations?)

So what. One paragraph. The compliance pressure they're under, the gap between what they have and what they need, and which framework is the strongest hook.

Critical rule on competitor claims. If the account is using a known competitor, do not improvise messaging in this brief. Reference the approved competitor battlecard notes from competitive-battlecard-generator and tag the relevant battlecard in the brief. Unsourced competitor swipes in research briefs become unsourced competitor swipes in outreach — and that creates legal and credibility exposure.

> Example: "Has a public SOC 2 Type II attestation but no ISO 27001. EU > expansion means GDPR exposure and EU enterprise buyers will likely require > ISO 27001 within 12 months. Currently using Drata (job post mention from Aug > 2025) — see Drata battlecard for approved positioning. Compliance team is 2 > people per LinkedIn — likely overloaded. Hook: ISO 27001 as the EU expansion > blocker."

Critical terminology check. Run any compliance language in this section through grc-messaging-guardrails before finalizing. Common errors: calling SOC 2 a "certification" (it's an attestation), conflating GDPR with general data privacy, treating ISO 27001 as a one-time event.

Section 3: Trigger Events

What goes here. The reason this account is researchable now. Triggers are what make outreach feel relevant instead of generic.

First-party and second-party triggers (highest priority when available):

• Active page visits on your site (pricing, product, comparison pages)
• G2 category or comparison page visits
• Paid ad engagement (specific creative, topic resonance)
• Past conversations with BDR/AE (recycled pipeline)

Public triggers:

• Funding rounds (last 12 months)
• Executive hires or departures (especially CISO, CTO, VP Engineering, Head of Compliance)
• Product launches (especially anything that expands their data surface area)
• Geographic expansion (especially into regulated regions: EU, healthcare, finance)
• Public security incidents or breach disclosures
• Customer logos announced (especially regulated-industry customers)
• M&A activity
• Job posts that signal compliance need (e.g., hiring "Compliance Manager," "Security Analyst")
• Public statements on compliance roadmap (earnings calls, blog posts, conference talks)

So what. Rank triggers by recency and outreach value. The freshest, most relevant trigger anchors the opening message. First-party signals beat public signals when both exist.

> Example: "Highest-value trigger: New security leader hired in Oct 2025 > (ex-Plaid). Security leaders often reassess tooling early in tenure — > validate with their recent LinkedIn posts and public priorities. Outreach > window is now."

Section 4: Buying Committee

Tier 1: deep. Tier 2: summary. Tier 3: Skipped by tier.

What goes here. The 3-7 people who will influence or decide a Scrut purchase. For tier-1 accounts, name them. For tier-2, identify by role. For tier-3, explicitly mark this section "Skipped by tier — segment-level personas apply."

For each person:

• Name + title + tenure (LinkedIn)
• Reporting line (who they report to, who reports to them)
• Background (previous companies — flag if they've used GRC tools before)
• Public content (LinkedIn posts, conference talks, podcast appearances on compliance/security)
• Likely role in a Scrut deal (Decision Maker / Champion / Influencer / Blocker / End User)

So what. One sentence per person on how to engage them and what they care about most. Don't write generic personas — write this person given their background.

> Example: "Sarah Chen, Head of Compliance, joined from a Series D FinTech where > she rolled out Vanta. She'll have strong opinions on what 'good' looks like and > will benchmark Scrut against her last experience. Champion candidate. Reference > Drata battlecard for approved competitor positioning — do not improvise > Vanta-specific claims."

Section 5: Tech Stack Signals

Tier 1: deep. Tier 2: summary. Tier 3: Skipped by tier.

What goes here. What they use that tells you about their compliance maturity and integration needs.

• Cloud infrastructure (AWS, GCP, Azure — visible from job posts, BuiltWith, security pages)
• Productivity stack (Google Workspace vs M365 — affects integration priorities)
• Identity provider (Okta, Azure AD, Google — critical for evidence collection)
• Existing GRC/security tools (visible from LinkedIn job posts, G2 reviews, RFP responses)
• HR system (Rippling, Workday, BambooHR — affects employee evidence collection)
• Code repositories (GitHub, GitLab — affects developer evidence collection)
• Ticketing (Jira, Linear, ServiceNow — affects audit evidence workflows)

So what. Two sentences. The integration story Scrut needs to tell to make adoption frictionless. Flag any blockers (e.g., proprietary in-house systems that won't have native connectors).

> Example: "AWS + Okta + GitHub + Jira — fully covered by Scrut connectors. > Rippling for HR (native connector). Migration friction is low. Lead with > 'evidence collection works on day one with your existing stack.'"

Section 6: Outreach Hypothesis

What goes here. The synthesis. Given everything above, what should the BDR say first?

• The single highest-priority trigger event
• The single most pressing compliance gap
• The persona to lead with and why
• The opening message angle (one sentence — not a full email)
• The proof point or asset to lead with (case study, framework guide, calculator)
• The disqualification criteria (what would make this account not worth pursuing)

So what. This section is the brief. Sections 1-5 are evidence; Section 6 is the recommendation. If a BDR only reads Section 6, they should still know what to do.

> Example: > - Trigger: New security leader hired Oct 2025 (early-tenure tooling reassessment window) > - Gap: ISO 27001 likely needed for EU expansion within 12 months > - Persona: Sarah Chen, Head of Compliance (champion candidate) > - Angle: "Security leaders we work with often benchmark GRC tooling early in tenure. Worth a 15-min comparison?" > - Lead asset: ISO 27001 scoping guide for FinTech > - Disqualify if: They've signed a Drata renewal in the last 90 days (check via job posts mentioning Drata after Sept 2025)

---

Phase 3: Source Hierarchy and Verification

Not all sources are equal. Use this hierarchy to weigh signals.

| Source Tier | Examples | Trust Level | Use For | |---|---|---|---| | Tier A: Primary | SEC filings, official trust centers, earnings call transcripts, regulatory filings | High | Compliance frameworks, financial state, public commitments | | Tier B: Verified secondary | Crunchbase, LinkedIn (company), G2 verified reviews, official press releases | Medium-high | Funding, headcount (directional), product launches, customer logos | | Tier C: Inferred | Job posts, LinkedIn employee profiles, BuiltWith, Wappalyzer | Medium | Tech stack, team size, hiring signals | | Tier D: Sentiment | Reddit, Glassdoor, Twitter/X, Slack communities | Low | Cultural signals, internal pain points (treat as hypothesis, not fact) |

Verification rule. Any claim in Sections 1-3 should have a Tier A or Tier B source. Sections 4-5 can rely on Tier C. Tier D goes in Section 6 only as hypothesis ("BDR should validate on first call: rumors of friction with current GRC vendor").

Anti-hallucination rule. If the brief generator can't find a source for a claim, the claim doesn't go in the brief. "Likely" and "probably" are flags to either find a source or remove the claim — or mark the claim as hypothesis explicitly. Brief credibility dies on the first fabricated detail a BDR mentions in outreach.

Signal freshness. Every claim should carry an implicit freshness rating. Funding rounds older than 12 months are stale. Executive hires older than 6 months are s

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Stallin-Sanamandra
• Source: Stallin-Sanamandra/b2b-saas-marketing-skills
• License: MIT

Install and usage instructions live in the source repository linked above.