# Account Research Brief Generator > > - **Type:** Skill - **Install:** `agentstack add skill-stallin-sanamandra-b2b-saas-marketing-skills-account-research-brief-generator` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [Stallin-Sanamandra](https://agentstack.voostack.com/s/stallin-sanamandra) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [Stallin-Sanamandra](https://github.com/Stallin-Sanamandra) - **Source:** https://github.com/Stallin-Sanamandra/b2b-saas-marketing-skills/tree/main/skills/account-research-brief-generator ## Install ```sh agentstack add skill-stallin-sanamandra-b2b-saas-marketing-skills-account-research-brief-generator ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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. 2. **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. 3. **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](https://github.com/Stallin-Sanamandra) - **Source:** [Stallin-Sanamandra/b2b-saas-marketing-skills](https://github.com/Stallin-Sanamandra/b2b-saas-marketing-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-stallin-sanamandra-b2b-saas-marketing-skills-account-research-brief-generator - Seller: https://agentstack.voostack.com/s/stallin-sanamandra - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.