Lead enrichment
Skill LeadMagic/gtm-skills/skills/prospecting/lead-enrichment
205 production GTM agent skills for Claude Code — sales, outbound, prospecting, RevOps, ABM, PLG, CS, automation. Framework-cited playbooks with artifacts + QA scripts.
npx -y skills add LeadMagic/gtm-skills --skill lead-enrichmentAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
Enrich prospect and account lists with company, contact, role, technographic, intent, funding, hiring, and confidence fields. Produces enrichment schema, waterfall order, QA thresholds, dedupe rules, and CRM-ready output. Use when turning raw lists into usable GTM data or improving data quality.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
21.7 KB, as published. Nobody here has run it
Lead Enrichment
Overview
The most common lead enrichment failure is sending every record to every provider — paying 3x the necessary cost while introducing conflicting data that requires manual reconciliation. The non-obvious rule of enrichment is the waterfall pattern: sequence providers from cheapest to most expensive, and from broadest coverage to most specialized, with each provider only firing when the previous one returned empty or low-confidence results. This approach maximizes coverage while minimizing cost per enriched record.
This skill provides a complete waterfall enrichment methodology that chains multiple data providers in a cost-optimized sequence. It specifies separate enrichment strategies for company data (firmographics, technographics, funding, revenue) and person data (contact details, job history, social profiles), with domain-based matching as the primary join key. Confidence thresholds determine when a record is "good enough" versus when it needs the next provider in the waterfall.
The deliverables include a Waterfall Configuration (provider sequence with trigger conditions), a Company Enrichment Table schema, a Person Enrichment Table schema, Confidence Threshold Rules for data quality gating, and a Normalization Protocol for reconciling conflicting data across providers. The methodology draws from DAMA-DMBOK data-quality dimensions and Ziellab's 3-waterfall architecture for production-grade enrichment pipelines.
When to Use
- User says "enrich these leads" or "append data to this list" → activate this skill
- User asks "how do I set up an enrichment waterfall" or "which enrichment providers should I use" → use this skill
- User mentions "Clay enrichment," "data enrichment," "contact enrichment," "company enrichment" → this skill applies
- User has a lead list from lead-finding and needs to fill in missing data
- User is building a Clay table and needs to configure enrichment columns
- User wants to normalize data from multiple enrichment sources
Do NOT use for:
- Finding email addresses for contacts without any existing data — use email-finding
- Verifying that email addresses are valid and deliverable — use contact-verification
- High-level strategy on which providers to buy — use data-enrichment-strategy
- Setting up the overall enrichment architecture — use waterfall-enrichment for Clay-specific implementation
Authoritative Foundations
-
DAMA-DMBOK — Data Quality Dimensions. Use accuracy, completeness, consistency, timeliness, uniqueness, validity, and lineage as the quality model for enrichment waterfalls and provider arbitration.
-
Ziellab — 3-Waterfall Architecture. The pattern of running three parallel waterfalls (Company, Contact, Technographic) that feed into a unified enriched record. This skill adopts the separate-company-and-person-tables architecture.
-
Winning by Design — Data Model. The GTM Index's Data Model component (scored 1-10) that measures how well an organization's data is instrumented. This skill raises the Data Model score by ensuring enrichment produces structured, normalized, confidence-tagged data.
-
Clay — Waterfall Enrichment Best Practices. The Clay-native approach to enrichment waterfalls: use formula columns for conditional logic, HTTP API columns for provider calls, and AI columns (Claygent/Claude) for normalization and gap-filling.
Prerequisites
- Upstream skills: lead-finding (provides the lead list to enrich). gtm-context (provides the ICP that determines what enrichment fields matter). icp-scoring (provides the dimensions to enrich against).
- Required inputs: A lead list with at minimum: company name, company domain, and (for person enrichment) person name and/or LinkedIn URL.
- Optional: API keys for enrichment providers (Apollo, ZoomInfo, PDL, Clearbit, LeadMagic). Clay account for workflow automation.
- Optional tools: LeadMagic Company Search and People Search APIs for enrichment with high-accuracy firmographic and contact data. LeadMagic Technographics API for technology stack enrichment.
Step-by-Step Process
Phase 1: Intake
Ask all questions at once:
- Provide the lead list to enrich. What fields are already populated? What fields are missing?
- What enrichment providers do you have access to? (Apollo, ZoomInfo, People Data Labs, Clearbit, Cognism, Lusha, Clay, LeadMagic, other.)
- What is your budget per enriched record? (This determines how many waterfall layers to use.)
- What enrichment fields are required vs nice-to-have? (Company: employees, revenue, industry, tech stack, funding. Person: email, phone, title, LinkedIn, seniority.)
- Are you enriching companies, people, or both?
- What is your target data quality threshold? (What confidence level is "good enough" for your use case?)
Phase 2: Research
Provider Coverage Analysis: Before configuring the waterfall, understand each provider's coverage profile:
- Apollo: Strong on US companies, tech-forward, funded. Weak on non-US, traditional industries, very small companies.
- ZoomInfo: Broadest coverage, strongest on mid-market and enterprise. Expensive per record. Weak on very early-stage startups.
- People Data Labs (PDL): Strong on person data, especially job history and skills. Company data is derived, not primary.
- Clearbit: Strong on company firmographics and technographics. Person data is good but limited coverage.
- Cognism: Strong on EMEA/UK coverage. GDPR-compliant. Weak on US coverage.
- Lusha: Good for contact data (email, phone). Company data is thin.
- LeadMagic: High accuracy on email finding, company search, and technographics. Strong coverage across segments.
Field Prioritization: Not all fields are equally important. Prioritize enrichment by field criticality:
- Tier 1 (Must have for any outreach): Company name, domain, employee count, industry. Person: name, title, email.
- Tier 2 (Important for qualification): Revenue, tech stack, funding data, LinkedIn URL, phone.
- Tier 3 (Nice to have for personalization): Job history, education, skills, social profiles, news mentions.
Phase 3: Execution
Step 1: Schema Design
Design separate Company and Person tables. Match on domain, not company name (names vary across providers; domains are stable).
Company Table Schema:
| Field | Type | Required | Source Priority |
|---|---|---|---|
| company_domain | text | Yes | Input data |
| company_name | text | Yes | Normalized from input |
| company_legal_name | text | No | Provider data |
| employee_count | integer | Tier 1 | Provider waterfall |
| employee_count_range | text | Tier 1 | Provider waterfall |
| revenue | integer | Tier 2 | Provider waterfall |
| revenue_range | text | Tier 2 | Provider waterfall |
| industry | text | Tier 1 | Provider waterfall (standardized) |
| sub_industry | text | No | Provider waterfall |
| sic_code | text | No | Provider waterfall |
| naics_code | text | No | Provider waterfall |
| company_description | text | No | Provider waterfall |
| founded_year | integer | No | Provider waterfall |
| funding_stage | text | Tier 2 | Provider waterfall |
| funding_total | integer | Tier 2 | Provider waterfall |
| last_funding_date | date | Tier 2 | Provider waterfall |
| technologies | array | Tier 2 | LeadMagic Technographics |
| hq_city | text | No | Provider waterfall |
| hq_state | text | No | Provider waterfall |
| hq_country | text | Tier 1 | Provider waterfall |
| linkedin_url | text | Tier 2 | Provider waterfall |
| website | text | Yes | Input data |
| alexa_rank | integer | Tier 3 | Provider waterfall |
| enriched_date | date | Auto | Current timestamp |
| enrichment_source | text | Auto | Provider that supplied most data |
| confidence_score | float | Auto | Calculated |
Person Table Schema:
| Field | Type | Required | Source Priority |
|---|---|---|---|
| person_id | text | Yes | Generated UUID |
| company_domain | text | Yes | Match key to company table |
| first_name | text | Yes | Input or enriched |
| last_name | text | Yes | Input or enriched |
| full_name | text | Yes | Normalized |
| title | text | Tier 1 | Provider waterfall |
| seniority | text | Tier 1 | Provider waterfall |
| department | text | Tier 1 | Provider waterfall |
| text | Tier 1 | LeadMagic Email Finder | |
| email_status | text | Tier 1 | LeadMagic Email Validation |
| phone | text | Tier 2 | Provider waterfall |
| linkedin_url | text | Yes | Input or enriched |
| location | text | Tier 2 | Provider waterfall |
| company_name | text | Yes | From company table |
| job_history | array | Tier 3 | PDL / Provider waterfall |
| education | array | Tier 3 | Provider waterfall |
| skills | array | Tier 3 | Provider waterfall |
| enriched_date | date | Auto | Current timestamp |
| enrichment_source | text | Auto | Provider that supplied most data |
| confidence_score | float | Auto | Calculated |
Step 2: Waterfall Configuration
Configure the enrichment waterfall in this sequence. For each provider, specify the trigger condition (when it fires) and the fields it populates.
Company Enrichment Waterfall:
Layer 1: Seed Data (no cost)
├── Input: company website/domain
├── Extract: domain normalization, basic URL parsing
└── Trigger: Always runs first
Layer 2: Public/Free Sources (no cost)
├── Clearbit Reveal (free tier) or similar
├── Extract: basic firmographics from domain
└── Trigger: Always runs after seed data
Layer 3: Broad-Coverage Provider (cost per record)
├── Apollo People Enrichment OR ZoomInfo
├── Extract: employee count, revenue, industry, description, location
└── Trigger: ENRICH when employee_count IS NULL OR industry IS NULL
└── Cost: $0.01-$0.05 per record
Layer 4: Specialist Provider (higher cost)
├── LeadMagic Company Search OR Clearbit Pro
├── Extract: fill remaining Tier 1 gaps, add technographics
└── Trigger: ENRICH when employee_count IS NULL OR industry IS NULL
└── Cost: $0.02-$0.10 per record
Layer 5: AI/Normalization (computation cost)
├── Claygent OR Claude
├── Extract: normalize company descriptions, standardize industries, fill description gaps
└── Trigger: ENRICH when company_description IS NULL OR industry IS NULL
└── Cost: $0.01-$0.05 per record
Person Enrichment Waterfall:
Layer 1: Seed Data (no cost)
├── Input: person name, company domain, LinkedIn URL
├── Extract: name parsing (first/last), domain matching
└── Trigger: Always runs first
Layer 2: Public/Free Sources (no cost)
├── LinkedIn URL parsing, public profile data
├── Extract: title, company, location from LinkedIn
└── Trigger: Always runs after seed data
Layer 3: Broad-Coverage Provider (cost per record)
├── Apollo People Search OR ZoomInfo People
├── Extract: title, seniority, department, phone
└── Trigger: ENRICH when title IS NULL OR seniority IS NULL
└── Cost: $0.02-$0.08 per record
Layer 4: Email Finding (cost per record)
├── LeadMagic Email Finder OR Hunter OR Findymail
├── Extract: email, email_status
└── Trigger: ENRICH when email IS NULL
└── Cost: $0.01-$0.05 per record
Layer 5: Deep Person Enrichment (higher cost)
├── People Data Labs (PDL) Person Enrichment
├── Extract: job history, education, skills
└── Trigger: ENRICH when job_history IS NULL (and Tier 1 records only)
└── Cost: $0.05-$0.15 per record
Layer 6: AI/Normalization (computation cost)
├── Claude normalization
├── Extract: standardize titles, normalize departments, fill gaps
└── Trigger: ENRICH when title IS NULL OR department IS NULL
└── Cost: $0.01-$0.03 per record
Step 3: Confidence Threshold Rules
Assign confidence scores to enriched fields based on provider and data freshness:
- Confidence = 1.0: Manually verified, or seed data from CRM.
- Confidence = 0.8-0.9: Direct API response with high provider confidence. LeadMagic direct match. ZoomInfo verified record.
- Confidence = 0.6-0.7: API response with medium confidence. Provider inferred or modeled data. Apollo modeled employee count.
- Confidence = 0.4-0.5: AI-normalized or inferred data. Claude normalization output. Domain-parsed data.
- Confidence = 0.1-0.3: Heuristic or guessed data. PDL derived data. Data older than 180 days.
Confidence Threshold Actions:
- Overall confidence ≥ 0.8: Record is enrichment-complete. No further providers needed.
- Overall confidence 0.6-0.79: Record is usable but could be improved if capacity allows.
- Overall confidence < 0.6: Record needs the next provider in the waterfall.
- Overall confidence < 0.4: Flag for manual review or discard.
Step 4: Normalization Protocol
When multiple providers return data for the same field, resolve conflicts:
Company Name Normalization:
- Strip legal suffixes: "Inc.", "Inc", "Corporation", "Corp.", "Corp", "LLC", "Ltd.", "Ltd", "Limited", "GmbH", "S.A.", "AG", "B.V.", "Pty Ltd"
- Normalize: "Corp" → "Corporation" (standardize to full form if preferred)
- Longest non-empty name wins (more specific is usually more correct)
- Exception: if one name matches the domain, prefer it
Employee Count Normalization:
- Use the most recent data point (check enriched_date per source)
- If providers disagree by <20%, use the average
- If providers disagree by >20%, flag for review and use the more reputable provider
- Provider reputation ranking: LeadMagic/ZoomInfo > Apollo > Clearbit > PDL
Industry Normalization:
- Map all provider industry taxonomies to a standard taxonomy (NAICS or custom)
- If providers disagree, use the industry with higher provider confidence
- AI normalization (Claude) is the tiebreaker for ambiguous cases
Title and Seniority Normalization:
- Map variant titles to standard roles: "VP of Engineering" == "VP Engineering" == "Head of Engineering"
- Map titles to seniority tiers: C-level, VP, Director, Manager, Individual Contributor
- Use the most recent title (check job history dates)
- Use AI normalization for ambiguous titles: "Growth Hacker" → "Marketing, Individual Contributor"
Step 5: Quality Gates
Before releasing enriched data to downstream systems:
- Required field completeness: All Tier 1 fields must be populated or explicitly NULL
- Domain validity: Company domain must be valid (no typos, no personal email domains for company matches)
- Cross-table consistency: Person's company_name must match Company table's company_name
- No test data: Filter out records with test names (e.g., "Test User", "John Doe at Acme Inc")
- Duplicate check: No duplicate person records (same person_id) or company records (same domain)
Phase 4: Delivery
Deliver the enriched data as two structured tables (Company and Person) with:
- Complete schema documentation
- Waterfall configuration that produced the data
- Per-record confidence scores and source attribution
- Normalization log showing how conflicts were resolved
- Quality gate pass/fail report
- Cost breakdown: total cost, cost per record, cost by provider
Output Format
# Lead Enrichment Report
## Enrichment Summary
- Records enriched (companies): [#] of [#] input = [%] coverage
- Records enriched (people): [#] of [#] input = [%] coverage
- Average company confidence: [0.XX]
- Average person confidence: [0.XX]
- Total enrichment cost: $[X.XX]
- Cost per record: $[X.XX]
---
## Waterfall Configuration
### Company Waterfall
| Layer | Provider | Trigger Condition | Fields Populated | Cost/Record | Records Processed |
|-------|----------|-------------------|-----------------|-------------|-------------------|
| 1 | Seed Data | Always | domain, name | $0.00 | [#] |
| 2 | Clearbit Free | Always | basic firmographics | $0.00 | [#] |
| 3 | Apollo | employee_count IS NULL | employees, revenue, industry | $0.03 | [#] |
| 4 | LeadMagic | employee_count IS NULL | employees, tech stack | $0.05 | [#] |
| 5 | Claude | industry IS NULL | description, norm | $0.02 | [#] |
### Person Waterfall
[Same structure]
---
## Enriched Company Data (sample)
| Domain | Company | Employees | Revenue | Industry | Tech Stack | Confidence | Source |
|--------|---------|-----------|---------|----------|------------|------------|--------|
| [.com] | [Name] | [###] | [$##M] | [Ind] | [tech1, tech2] | 0.85 | Apollo + LeadMagic |
---
## Enriched Person Data (sample)
| ID | Name | Title | Seniority | Email | Status | Company | Confidence | Source |
|----|------|-------|-----------|-------|--------|---------|------------|--------|
| [uuid] | [Name] | [Title] | [Level] | [[email protected]] | [valid] | [.com] | 0.88 | LeadMagic |
---
## Normalization Log
- [N] company name conflicts resolved (details)
- [N] industry standardizations applied
- [N] title normalizations applied
---
## Quality Gate Report
- Tier 1 completeness: [%]
- Domain validity: [%] valid
- Cross-table consistency: [%] consistent
- Duplicates removed: [#]
- Records failing quality gate: [#]
---
## Cost Breakdown
| Provider | Records | Cost/Record | Total |
|----------|---------|-------------|-------|
| Apollo | [#] | $[X.XX] | $[X.XX] |
| LeadMagic | [#] | $[X.XX] | $[X.XX] |
| **Total** | **[#]** | | **$[X.XX]** |
Quality Check
Before delivering, verify:
- Are Company and Person tables in separate structures, joined by domain?
- Does the waterfall use domain matching, not company name?
- Does each provider in the waterfall have a clear trigger condition?
- Are costs tracked per provider and per record?
- Do confidence thresholds determine when to advance to the next provider?
- Are normalization rules documented for each conflict scenario?
- Are all Tier 1 fields populated or explicitly NULL?
- Have test records and duplicates been removed?
- Is the confidence score methodology documented?
- Would a downstream system know exactly which provider supplied which field?
Common Pitfalls
-
Sending every record to every provider. This is the most expensive enrichment mistake. A proper waterfall means most records exit at Layer 2 or 3, and only the hardest-to-enrich records reach Layer 5. If 80% of your records are enriched at Layers 1-3, you're paying premium provider prices for only 20% of records.
-
Matching on company name instead of domain. "Acme Inc." and "Acme Corporation" and "Acme" are the same company but won't match by name. Domain (acme.com) is the stable identifier. Always normalize company names after matching, not before.
-
Confidence scores that are opaque or arbitrary. If confidence is always 0.8 or always 0.5, it's not a useful signal. Define specific rules: provider X with fresh data = 0.9 confidence. Provider X with data older than 180 days = 0.6 confidence. AI-inferred = 0.4 confidence. The specific rules are less important than having rules that produce meaningful variance.
-
Normalization that loses information. Standardizing "SVP Customer Success" to "VP" loses the functional specialization. Standardize to a taxonomy that preserves both seniority and function. "VP, Customer Success" is better than just "VP."
-
Ignoring data freshness. Enrichment data decays. Employee counts change. People change jobs. Technologies change. Every enriched record should have an enriched_date, and downstream systems should have a re-enrichment cadence (recommended: 90 days for active prospects, 180 days for nurture).
-
Same-waferfall for companies and people. Company enrichment needs different providers and different fields than person enrichment. The two waterfalls should be configured independently, even if they share some infrastructure.
-
Quality gates that are too permissive or too strict. Gates that let everything through defeat the purpose. Gates that block 50% of records create a bottleneck. Target: <5% of records failing quality gates in a mature pipeline. More than 10% indicates a problem in the enrichment waterfall, not in the gate.
-
Not tracking cost per provider. Without per-provider cost tracking, you can't optimize the waterfall over time. A provider that costs 3x more but enriches only 2% more records should be removed or moved to a later layer. Cost optimization is continuous.
Execution Artifacts
references/framework-notes.md— Named frameworks and reference tablestemplates/output-template.md— Deliverable shell for agent outputscripts/check-output.py— Lightweight deliverable validator
Related Skills
-
lead-finding: Run before this skill. Provides the raw lead list to enrich.
-
email-finding: Use as a provider in the person enrichment waterfall for email discovery.
-
contact-verification: Run after this skill. Verifies enriched email addresses are deliverable.
-
data-enrichment-strategy: Run before this skill for high-level provider selection. This skill is the implementation.
-
waterfall-enrichment: Run for Clay-specific waterfall implementation. This skill provides the methodology independent of Clay.
-
list-building: Run after this skill. Uses enriched data to build production-ready prospecting lists.