GTM Engineering skill 03 of 13

Enrichment Waterfalls SKILL.md

The Enrichment Waterfalls skill makes Claude Code or another AI agent design and tune enrichment waterfalls for emails, phones, contacts and company data. It benchmarks providers on your own sample by region, orders them by cost per valid result, stops on success, verifies every email with a catch-all policy, adds confidence fields and regional variants and monitors match, bounce and cost monthly.

enrichment-waterfalls/SKILL.md, version 1.0.0, 1,499 words.

No single data provider finds every email, phone number or company detail. A waterfall tries providers one after another and stops when one returns a valid result, raising coverage while paying only for what is needed. Badly designed waterfalls do the opposite: they run the most expensive provider first, call every provider for every row, accept unverified emails, or ignore that providers perform differently by country and industry.

This skill designs and tunes enrichment waterfalls for emails, phone numbers, contacts and company data in Clay or similar tools: choosing providers per field and region, ordering by accuracy and cost, stopping rules, verification, confidence scoring, regional variants, testing on samples, monitoring match and bounce rates and documenting the logic.

Operating principles

  1. Measure before ordering. Test providers on your own sample, by region and segment.
  2. Cheapest accurate first. Order by cost per valid result, not by price per lookup alone.
  3. Stop on success. Each step runs only if earlier steps found nothing valid.
  4. Verify before use. Emails go through verification; risky or catch-all results are flagged.
  5. Regions differ. A provider strong in North America may be weak in Germany or Nigeria.

Waterfall types

FieldTypical stepsVerification
Work emailProvider A, B, C, pattern guess as last resortEmail verifier; flag catch-all
Mobile phoneProvider A, BFormat and country code checks
Contact discoveryPeople search by title and seniority, then fallback providerTitle and company match
Company firmographicsPrimary provider, then website scrapeDomain match
TechnographicsTech detection provider, then site scanDate of last detection

When to use, and when not to

Use it when setting up enrichment, when match or bounce rates are poor, when costs are high, when entering new regions or when adding a provider.

Don't use it for deciding who to target (icp-account-scoring) or for deliverability setup (outbound-infrastructure).

Inputs

  • Fields needed and how they will be used (email outreach, calls, scoring).
  • Providers available, their costs and contract terms.
  • A test sample of 200 to 500 rows representative of segments and regions.
  • Current match, bounce and cost figures.
  • Compliance requirements for data sources and regions.

Raw SKILL.md file

.md

This is the exact file agents read, including the credit header and licence notice. Save it as enrichment-waterfalls/SKILL.md.

---
name: enrichment-waterfalls
description: "Design enrichment waterfalls for emails, phones, contacts and company data: success definitions, provider benchmarks by region, ordering by cost per valid result, stop-on-success run conditions, email verification with catch-all policies, confidence fields, regional variants and monthly monitoring of match, bounce and cost. Use whenever someone sets up or tunes Clay enrichment, has low email match rates or high bounces, wants to cut provider costs, adds a data provider or enters a new region."
license: CC-BY-4.0
metadata:
  author: Afeez Adebayo
  author_url: https://afeezadebayo.com
  author_linkedin: https://www.linkedin.com/in/afeez-adebayo/
  author_x: https://x.com/za_icon
  source: https://afeezadebayo.com/skills-md/marketing/gtm-engineering/enrichment-waterfalls/
  category: marketing
  subcategory: gtm-engineering
  version: "1.0.0"
  created: "2026-10-10"
  updated: "2026-10-13"
---

# Enrichment Waterfalls

No single data provider finds every email, phone number or company detail. A waterfall tries providers one after another and stops when one returns a valid result, raising coverage while paying only for what is needed. Badly designed waterfalls do the opposite: they run the most expensive provider first, call every provider for every row, accept unverified emails, or ignore that providers perform differently by country and industry.

This skill designs and tunes enrichment waterfalls for emails, phone numbers, contacts and company data in Clay or similar tools: choosing providers per field and region, ordering by accuracy and cost, stopping rules, verification, confidence scoring, regional variants, testing on samples, monitoring match and bounce rates and documenting the logic.

## Operating principles
1. **Measure before ordering.** Test providers on your own sample, by region and segment.
2. **Cheapest accurate first.** Order by cost per valid result, not by price per lookup alone.
3. **Stop on success.** Each step runs only if earlier steps found nothing valid.
4. **Verify before use.** Emails go through verification; risky or catch-all results are flagged.
5. **Regions differ.** A provider strong in North America may be weak in Germany or Nigeria.

## Waterfall types
| Field | Typical steps | Verification |
|---|---|---|
| Work email | Provider A, B, C, pattern guess as last resort | Email verifier; flag catch-all |
| Mobile phone | Provider A, B | Format and country code checks |
| Contact discovery | People search by title and seniority, then fallback provider | Title and company match |
| Company firmographics | Primary provider, then website scrape | Domain match |
| Technographics | Tech detection provider, then site scan | Date of last detection |

## When to use, and when not to
Use it when setting up enrichment, when match or bounce rates are poor, when costs are high, when entering new regions or when adding a provider.

Don't use it for deciding who to target (`icp-account-scoring`) or for deliverability setup (`outbound-infrastructure`).

## Inputs
- Fields needed and how they will be used (email outreach, calls, scoring).
- Providers available, their costs and contract terms.
- A test sample of 200 to 500 rows representative of segments and regions.
- Current match, bounce and cost figures.
- Compliance requirements for data sources and regions.

## Workflow

### Step 1. Define success per field
For emails: verified valid, not catch-all unless accepted, matched to the right person and company.

### Step 2. Benchmark providers
Run each provider on the same sample. Record match rate, verified valid rate, cost per lookup and cost per valid result, by region.

### Step 3. Order the waterfall
Sort by cost per valid result within each region; put providers with unique coverage where they add most.

### Step 4. Add stop and run conditions
Each step runs only if previous steps returned nothing valid and the row still qualifies.

### Step 5. Verify
Run verification on every found email; mark valid, risky, catch-all or invalid; decide which statuses can be sent.

### Step 6. Add confidence
Combine provider, verification and match signals into a confidence field used by QA and sending rules.

### Step 7. Build regional variants
Where results differ, use separate orders for regions such as UK, DACH, North America and Africa.

### Step 8. Monitor
Track match rate, verified rate, bounce rate after sending and cost per valid result monthly; re-test providers quarterly.

## Benchmark table
```
| Provider | Region | Lookups | Found | Verified valid | Cost per lookup | Cost per valid email |
| A | UK | 200 | 128 | 112 | 1.0 | 1.79 |
| B | UK | 200 | 140 | 98 | 0.6 | 1.22 |
| C | UK | 200 | 90 | 85 | 1.5 | 3.53 |
```
In this example B goes first for the UK, then A, then C only for remaining rows.

## Verification statuses
| Status | Meaning | Default action |
|---|---|---|
| Valid | Mailbox confirmed | Send |
| Catch-all | Domain accepts all mail; mailbox unknown | Send only in small volumes or skip, by policy |
| Risky or unknown | Could not confirm | Hold or skip |
| Invalid | Will bounce | Never send |

## Cost logic
Cost per valid result = total spend on a step / number of valid results that step produced. A cheap provider with low accuracy can cost more per valid email than an expensive accurate one, once verification and bounces are counted.

## Phone waterfalls
Phone data is costlier and less reliable than email. Enrich phones only for top-tier accounts that sales will actually call, check formats and country codes, prefer direct dials over switchboards and track connect rates after calls to judge providers.

## Company data waterfalls
For firmographics, start with the cheapest reliable source, fall back to a second provider and use website scraping or AI research only for missing fields on qualified accounts. Record the source and date for each field so stale data can be refreshed.

## Bounce feedback loop
After sending, feed bounces back to the table: mark the provider and verification status that produced each bounced email. If one provider or status causes most bounces, demote or remove it. Keeping bounce rates low protects domain reputation as much as it saves money.

## Documenting the waterfall
Record each field's order, run conditions, verification rules, regional variants and the date of the last benchmark in the table spec, so anyone can explain and maintain the logic.

## Re-testing
Re-run the benchmark every quarter, after any provider pricing change and before entering a new region, because coverage and accuracy shift over time.

Keep a short change log of every reorder and why, so results can be compared over time.

Share benchmark results with sales operations so data quality expectations are clear.

## Edge cases and judgement calls
| Situation | What to do |
|---|---|
| Catch-all heavy segment | Use alternative signals (phone, LinkedIn) or small test sends |
| New region | Benchmark before scaling; consider regional providers |
| Provider changes pricing | Re-run the benchmark and reorder |
| Data protection limits | Check lawful basis and provider compliance; exclude restricted data |
| Personal emails returned | Exclude for B2B outreach unless policy allows |
| Very small volumes | One or two providers plus verification may be enough |

## Handoffs to related skills
- Table structure and run conditions: `clay-table-design`
- Cleaning outputs: `data-deduplication-normalisation`
- Sending safely: `outbound-infrastructure`
- QA before launch: `gtm-workflow-qa`
- Costs: `gtm-cost-control`
- Data hygiene in CRM: the CRM and Lifecycle `crm-data-hygiene` skill

## Worked example
A team's email waterfall ran its most expensive provider first for all regions and accepted unverified results; match rate in Germany was 58% and bounces reached 6%. A 400-row benchmark by region showed a cheaper provider led in the UK, a regional provider led in DACH and the expensive provider added unique coverage only as a third step. The new waterfall used regional orders, verified every email and held catch-all addresses. Match rate in DACH rose to 76%, bounce rate fell under 2% and cost per valid email dropped by about a third.

## Common mistakes
- Ordering by price per lookup instead of cost per valid result.
- Running every provider on every row.
- Sending unverified or catch-all emails at volume.
- One order for all regions.
- Never re-testing providers.

## Output format
```
1. Fields and success definitions
2. Provider benchmark by region
3. Waterfall order per field and region, with run conditions
4. Verification and confidence rules
5. Monitoring metrics and re-test schedule
```

## Self-check before you answer
- Were providers benchmarked on a representative sample?
- Is the order based on cost per valid result by region?
- Does each step stop on success?
- Are emails verified, with catch-all handled by policy?

---
Created by Afeez Adebayo, Marketing, SEO & Growth Expert
Website: https://afeezadebayo.com
LinkedIn: https://www.linkedin.com/in/afeez-adebayo/
X: https://x.com/za_icon
Source: https://afeezadebayo.com/skills-md/marketing/gtm-engineering/enrichment-waterfalls/

Licence: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). You may copy, share and adapt this skill, including for commercial use, as long as you credit Afeez Adebayo and link to the source URL above. Keep this notice in any copy or adapted version.

Workflow

Step 1. Define success per field

For emails: verified valid, not catch-all unless accepted, matched to the right person and company.

Step 2. Benchmark providers

Run each provider on the same sample. Record match rate, verified valid rate, cost per lookup and cost per valid result, by region.

Step 3. Order the waterfall

Sort by cost per valid result within each region; put providers with unique coverage where they add most.

Step 4. Add stop and run conditions

Each step runs only if previous steps returned nothing valid and the row still qualifies.

Step 5. Verify

Run verification on every found email; mark valid, risky, catch-all or invalid; decide which statuses can be sent.

Step 6. Add confidence

Combine provider, verification and match signals into a confidence field used by QA and sending rules.

Step 7. Build regional variants

Where results differ, use separate orders for regions such as UK, DACH, North America and Africa.

Step 8. Monitor

Track match rate, verified rate, bounce rate after sending and cost per valid result monthly; re-test providers quarterly.

Benchmark table

| Provider | Region | Lookups | Found | Verified valid | Cost per lookup | Cost per valid email |
| A | UK | 200 | 128 | 112 | 1.0 | 1.79 |
| B | UK | 200 | 140 | 98 | 0.6 | 1.22 |
| C | UK | 200 | 90 | 85 | 1.5 | 3.53 |

In this example B goes first for the UK, then A, then C only for remaining rows.

Verification statuses

StatusMeaningDefault action
ValidMailbox confirmedSend
Catch-allDomain accepts all mail; mailbox unknownSend only in small volumes or skip, by policy
Risky or unknownCould not confirmHold or skip
InvalidWill bounceNever send

Cost logic

Cost per valid result = total spend on a step / number of valid results that step produced. A cheap provider with low accuracy can cost more per valid email than an expensive accurate one, once verification and bounces are counted.

Phone waterfalls

Phone data is costlier and less reliable than email. Enrich phones only for top-tier accounts that sales will actually call, check formats and country codes, prefer direct dials over switchboards and track connect rates after calls to judge providers.

Company data waterfalls

For firmographics, start with the cheapest reliable source, fall back to a second provider and use website scraping or AI research only for missing fields on qualified accounts. Record the source and date for each field so stale data can be refreshed.

Bounce feedback loop

After sending, feed bounces back to the table: mark the provider and verification status that produced each bounced email. If one provider or status causes most bounces, demote or remove it. Keeping bounce rates low protects domain reputation as much as it saves money.

Documenting the waterfall

Record each field's order, run conditions, verification rules, regional variants and the date of the last benchmark in the table spec, so anyone can explain and maintain the logic.

Re-testing

Re-run the benchmark every quarter, after any provider pricing change and before entering a new region, because coverage and accuracy shift over time.

Keep a short change log of every reorder and why, so results can be compared over time.

Share benchmark results with sales operations so data quality expectations are clear.

Edge cases and judgement calls

SituationWhat to do
Catch-all heavy segmentUse alternative signals (phone, LinkedIn) or small test sends
New regionBenchmark before scaling; consider regional providers
Provider changes pricingRe-run the benchmark and reorder
Data protection limitsCheck lawful basis and provider compliance; exclude restricted data
Personal emails returnedExclude for B2B outreach unless policy allows
Very small volumesOne or two providers plus verification may be enough
  • Table structure and run conditions: clay-table-design
  • Cleaning outputs: data-deduplication-normalisation
  • Sending safely: outbound-infrastructure
  • QA before launch: gtm-workflow-qa
  • Costs: gtm-cost-control
  • Data hygiene in CRM: the CRM and Lifecycle crm-data-hygiene skill

Worked example

A team's email waterfall ran its most expensive provider first for all regions and accepted unverified results; match rate in Germany was 58% and bounces reached 6%. A 400-row benchmark by region showed a cheaper provider led in the UK, a regional provider led in DACH and the expensive provider added unique coverage only as a third step. The new waterfall used regional orders, verified every email and held catch-all addresses. Match rate in DACH rose to 76%, bounce rate fell under 2% and cost per valid email dropped by about a third.

Common mistakes

  • Ordering by price per lookup instead of cost per valid result.
  • Running every provider on every row.
  • Sending unverified or catch-all emails at volume.
  • One order for all regions.
  • Never re-testing providers.

Output format

1. Fields and success definitions
2. Provider benchmark by region
3. Waterfall order per field and region, with run conditions
4. Verification and confidence rules
5. Monitoring metrics and re-test schedule

Self-check before you answer

  • Were providers benchmarked on a representative sample?
  • Is the order based on cost per valid result by region?
  • Does each step stop on success?
  • Are emails verified, with catch-all handled by policy?

When to use this skill, and when not to

Use it when setting up enrichment in Clay or a similar tool, when match rates are low or bounces high, when costs climb, when entering a new region or when adding a provider.

No provider finds every email. Badly designed waterfalls run the most expensive provider first, call every provider on every row and accept unverified results.

For who to target, use ICP and Account Scoring.

Example prompts

  • “Design an email waterfall for UK and DACH.”
  • “Benchmark these three providers on 400 rows.”
  • “Our bounce rate is 6%. Fix our enrichment.”
  • “Which provider should run first?”
  • “Set a catch-all email policy.”

Example output

The skill returns a fixed structure. A shortened example for an imaginary site:

Benchmark: 400 rows by region
UK order: B, A, C | DACH order: regional provider, B, A
Verification: all emails; catch-all held
Results: DACH match 58% -> 76%, bounces 6% -> under 2%
Cost per valid email: down about a third

Providers are ordered by cost per valid result in each region, not by price per lookup.

What the agent needs from you

The skill asks for the fields you need and how they will be used, providers with costs and contracts, a 200 to 500-row test sample, current match, bounce and cost figures and compliance rules by region.

How this skill hands off to related skills

How to run Enrichment Waterfalls step by step

  1. Install the skill as enrichment-waterfalls/SKILL.md.
  2. Define success per field.
  3. Benchmark providers by region.
  4. Order and gate the waterfall.
  5. Verify every email.
  6. Monitor monthly.

Situations this skill handles

Enrichment Waterfalls handles these situations:

SituationWhat the skill does
Catch-all heavy segmentOther channels or small tests
New regionBenchmark before scaling
Price changeRe-run and reorder
Data protection limitsLawful basis checked
Personal emailsExcluded for B2B
Small volumesOne or two providers

What makes this skill different

Most waterfall advice lists providers. This skill measures them on your data, by region, and orders them by what each valid email actually costs, then closes the loop with bounce data.

Practical tips from real projects

  • Measure before ordering.
  • Cheapest accurate first.
  • Stop on success.
  • Verify before use.

A worked example: a team ran its most expensive provider first everywhere and accepted unverified emails; German match rate was 58% and bounces reached 6%. A 400-row benchmark showed a cheaper provider led in the UK, a regional provider led in DACH and the expensive provider added unique coverage only as a third step. Regional orders, full verification and held catch-all addresses raised DACH match to 76%, cut bounces under 2% and reduced cost per valid email by about a third.

Waterfalls cover different fields. Work emails run through two or three providers with a pattern guess only as a last resort and verification on every result. Mobile phones use one or two providers with format and country code checks. Contact discovery searches by title and seniority with a fallback provider. Company firmographics start with the cheapest reliable source and fall back to a second provider or website scraping, and technographics record the date of last detection.

The benchmark table records provider, region, lookups, found, verified valid, cost per lookup and cost per valid email. Cost per valid result equals total spend on a step divided by the valid results it produced, so a cheap provider with low accuracy can cost more per valid email than an accurate expensive one once verification and bounces are counted. Verification statuses drive actions: valid emails send, catch-all addresses send only in small volumes or are skipped by policy, risky ones are held and invalid ones never send.

The workflow defines success per field, benchmarks providers on the same sample, orders them by cost per valid result within each region, adds stop and run conditions, verifies, combines provider, verification and match signals into a confidence field, builds regional variants and monitors match rate, verified rate, bounce rate after sending and cost per valid result every month, with a full re-test each quarter.

A bounce feedback loop marks which provider and status produced each bounced email, demoting sources that cause most bounces and protecting domain reputation. Every order, run condition, verification rule and benchmark date is recorded in the table spec with a change log, so anyone can explain and maintain the logic. Common mistakes are ordering by price per lookup, running every provider on every row, sending unverified or catch-all emails at volume, one order for all regions and never re-testing.

Phone data costs more and is less reliable than email, so phones are enriched only for top-tier accounts that sales will actually call, with direct dials preferred over switchboards and connect rates tracked after calls to judge each provider over time.

Edge cases follow clear rules. Segments with many catch-all domains use other channels, such as phone or LinkedIn, or small test sends. New regions are benchmarked before scaling, and regional providers often win there. Price changes trigger a fresh benchmark and reorder. Data protection rules are checked for lawful basis and provider compliance, personal emails are excluded from B2B outreach unless policy allows, and very small volumes may need only one or two providers plus verification.

The output is a list of fields with success definitions, a provider benchmark by region, the waterfall order per field and region with run conditions, verification and confidence rules and a monitoring and re-test schedule shared with sales operations.

The final check confirms providers were benchmarked on a representative sample, the order follows cost per valid result by region, each step stops on success and every email is verified with catch-all handled by policy.

Frequently asked questions

A sequence of data providers tried one after another until one returns a valid result, raising coverage while paying only for what is needed.

By cost per valid result for each region, measured on your own sample.

Yes. Verification marks emails as valid, catch-all, risky or invalid before sending.

An address on a domain that accepts all mail, so the mailbox cannot be confirmed; send only by policy and in small volumes.

Quarterly, after pricing changes and before entering new regions.

Yes. Phones cost more, so enrich only top-tier accounts that will be called and track connect rates.

Changelog

  • 1.0.0, 10 October 2026: first release.

Use, adapt and share this skill under CC BY 4.0: credit Afeez Adebayo and link to this page.