Waterfall Enrichment: Stop Paying for Empty Rows
Waterfall enrichment is a fallback chain, not a Clay tutorial. Verify after finders, park catch-alls, and stop paying for empty sendable rows.

Waterfall enrichment is a fallback chain: you query several data providers in a fixed order and keep the first result that clears your confidence bar. A single finder is a coin flip on coverage. The chain only earns its keep if you verify after the finders, park catch-alls, and stop treating a filled cell as a lead.
Most pages on this keyword are Clay tutorials. They teach you how to stack logos. They skip the part that actually protects a sending domain: a filled row is not a sendable one. Hunter sits inside a lot of those stacks and is blunt about it - a waterfall guarantees coverage, not accuracy. Eager finders fill the list first. You meet them again as hard bounces.
This is the operator version. Finder, then verifier, then catch-all handling. Not the integration tile.

What is waterfall enrichment?
Waterfall enrichment queries more than one data provider for the same field, in a set order, and stops at the first result you are willing to keep. If provider A returns nothing usable, the record falls to B, then C, until something lands or the chain runs out.
It is sequential. It is not five finders enriching the same row while you pick a winner afterward. The second provider should only see what the first missed.
The field is usually a work email. The same shape works for phones or firmographics. For cold email, email is the field that can wreck the domain, so that is the waterfall this page is about.
A useful result has three properties:
- It came from a real lookup, not a pattern guess you treated as fact.
- It survived an independent verifier, not the finder's own confidence badge.
- You can name the source later when it bounces.
If you cannot point to the provider that produced the address, you cannot drop the bad one. You just keep paying the whole stack.
Why not use a single data provider?
Because no vendor wins coverage and quality on the same sample. Clay's own 2025 work-email benchmark is the cleanest public version of that claim: no single provider cleared both 95% quality and 90% coverage. Pick one tool and you pick a failure mode - a clean list with a hole, or a full list you should not send.
PhantomBuster's ranges (treat as industry bands, not a promise) put single-source raw match around 40-70% and a waterfall around 80-95%. After verification the bands drop: roughly 35-60% versus 70-85%. The extra rows are why people build the chain. They are also where bounce rate hides if you skip the next two stages.
A single provider is fine when:
- Your ICP is one geography and one company size that vendor already covers well.
- The list is small enough that you can fill gaps by hand.
- A missing row costs you less than a hard bounce.
Otherwise you are paying for empty sendable rows even when the CSV looks full. A B2B email finder returns a lookup. A Ken lead is a qualified contact with a valid email. Mixing those units is how a credit pack "covers 2,000 searches" and still cannot fill a sequence you would put a warmed inbox behind.
What order should a waterfall run in?
Order is the whole design. Cheap-first is the Clay default because early levels run on every record and late levels run on almost none. That is a budget rule. It is not a deliverability rule.
For cold email, a wrong address costs more than a gap. Hunter's warning is the one Clay tutorials bury: the most forgiving finder claims the biggest share of the list, because every record it "finds" never reaches the stricter tools behind it. Those guesses become your bounce report.
Run three stages, not one mega-column of finders.

| Stage | Job | Keep when | Fail action |
|---|---|---|---|
| 0. Inputs | Name, domain, LinkedIn URL, one row per person | Fields are real and de-duplicated | Do not enrich. Fix the file. |
| 1. Finders | Resolve a work address from those inputs | A candidate exists | Fall to the next finder, then stop |
| 2. One verifier | Same tool, every row, whatever finder won | Valid / safe on a domain that rejects fakes | Drop invalid. Do not retry from another finder as if that were verification |
| 3. Catch-all handling | Separate the maybe pile | Confirmed inbox, or a parked pool | Never mix accept-all into the primary send |
Two ordering rules that actually hold:
- Finders: coverage, then cost. Put a source that returns trustworthy data on your ICP first if you can afford it. Put a cheap broad source first only if you will still verify. Cap the finder chain at two or three. Hunter's point on diminishing returns is right - later providers often share upstream data.
- Confidence is a later stage. Do not let a finder mark a row "done." "Found" means "has a string in the email column." "Done" means a verifier you trust said valid, and catch-alls are out of the primary list.
Do not verify inside every finder. That double-bills and produces conflicting statuses. One verifier at the end, so "valid" means one thing in the sheet.
Record the source on every keep. When a campaign's hard bounces spike, you want to kill a provider, not the whole motion.
Do you get charged when a provider returns nothing?
It depends on the tool, the year, and whether you actually built a waterfall.
Clay's own 2026 waterfall guide says they bill the lookup that returns the match, not the cheaper sources that came back empty. Independent write-ups after Clay's March 2026 pricing change report the same hit-only rule for marketplace data credits. Older posts, and a lot of live tables, still describe per-attempt burn. Both can be true in the same week: the product bills hits, and a table with no run condition still fires every provider on every row.
Other stacks still charge per attempt. If your "waterfall" is five always-on columns, you bought five lookups whether or not anyone found the person.
Check three things before you argue about credits:
- Does this vendor bill on empty, on hit, or on every column that ran?
- Did you condition each fallback on the previous cell being empty?
- Did you de-duplicate and normalize domains before any paid call?
A miss on a malformed domain is not a data problem. It is you paying to look up junk. Clean inputs are cheaper than a fourth finder.
The unit that matters is still not credits. It is cost per sendable row: qualified person, valid email, you would actually send. Ken's pricing page uses that definition on purpose. Load 10,000 profiles, qualify down, keep the ones with a valid email, and you were billed for those leads - not the attempts.
If you want ten already-finished rows instead of another credit spreadsheet, Ken Daily drops 10 verified ICP leads in your inbox every morning, free, no card.
How does waterfall enrichment affect bounce rate?
A waterfall can lower bounce rate. It can also raise it. The chain does not care. Your confidence bar does.
Hard bounces are a list verdict. Under 2% is the hygiene floor we use in cold email bounce rate; under 1% is the operating target on a verified B2B list. Crossing 5% is how Gmail and Outlook start treating the domain like a scraper.
Three ways a waterfall makes that number worse:
- Stop at first answer. A pattern-guess that looks like an email never reaches a stricter finder.
- Mixed statuses. One vendor calls accept-all "valid." Another calls it "risky." You ship the maybe pile because the cell is green.
- No source column. You cannot tell which provider produced the 550s, so you keep it in the stack.
Three ways it makes the number better:
- Coverage of verified rows goes up, so you stop padding the sequence with role accounts and dead companies just to hit volume.
- One verifier at the end, with catch-alls parked, is the same pipeline as getting verified B2B email leads: syntax, MX, mailbox check, catch-all flag, role-based, disposable.
- You send fewer empty-of-person rows. Bounce rate is what happens when Gmail runs the qualification step you skipped.
Catch-alls need their own rule, not a waterfall opinion. A catch-all domain accepts every local-part at SMTP time, so a verifier cannot confirm the mailbox. Treat unknown / risky / accept-all as not sendable on the primary campaign. Park them. The long version is catch-all email verification.
PhantomBuster's comparison table puts common hard-bounce after activation around 3-8% on single-source lists and 1-3% on a waterfall that actually verifies. Use that as a reason to measure your own first 1,000 sends, not as a number to put on a sales deck.
Is Clay the only way to run a waterfall?
No. Clay is the most documented way to orchestrate one. It is a spreadsheet that talks to a marketplace. It is not a data provider, and it does not send.
You can run the same shape with:
- Two or three finder APIs plus one verifier, conditioned in your own sheet or script.
- A vendor that already chains sources behind one "find email" button (Apollo, FullEnrich, BetterContact, and a long tail of Clay clones).
- A done-for-you motion that runs multi-source enrichment and verification as part of the list, not as a weekend project.
Clay is the right object if you want to operate the machine - pick providers, watch credits, own the source column. It is the wrong object if you thought buying a waterfall tutorial would produce meetings. We already ran that comparison in Clay alternatives: the credit bill is the enrichment layer; sending, warmup, and copy still sit on other invoices.
Ken's public product does the enrichment job as part of the motion: Smart Targeting over 300M+ profiles, enrichment from LinkedIn / web / tech / posts, and triple email verification including catch-alls. A lead on ken.so/pricing is finished output - qualified, valid email - not a credit. Core is $597/mo done-for-you (or $1,497/quarter), same software limits as VIP. You can also run the same motion in the app. That is not a self-serve plan ladder. It is the same stack with a human still writing and approving the email.
If you only need the list habit, start with Ken Daily. Ten verified ICP leads a morning is a better teacher than a 12-column Clay table you never quite trust.
A waterfall you can actually run this week
Keep it ugly and short.
- De-duplicate people. Normalize domains. Drop rows missing a name or a company.
- Run finder A on the whole list. Finder B only where A is empty. Stop. Do not add a fourth "just in case."
- Copy the first non-empty email into one column. Keep a
sourcecolumn next to it. - Verify that column with one tool. Valid goes to the primary send. Invalid is dead. Catch-all / unknown / risky goes to a parked list.
- Send the valid pile. Watch hard vs soft bounce for a week. If a source is over-represented in the 5xx codes, drop it from stage 1.
That is the whole job. The logos are optional.
FAQ
What is waterfall enrichment in plain English?
You ask several data vendors for the same field, one after another, and keep the first answer you trust. If the first vendor has nothing usable, the record falls to the next. Most teams use it to find work emails.
Does a waterfall replace email verification?
No. Finding is not verifying. Run finders until you have a candidate, then run one verifier on every candidate. Verifying inside each finder wastes money and gives you three different words for "maybe."
Should I put the cheapest provider first?
Only if you still verify. Cheap-first is a cost tactic. For cold email, an eager cheap finder will fill rows the stricter tools never get to see. A gap is cheaper than a hard bounce on a domain you care about.
How many providers belong in an email waterfall?
Two or three finders plus one verifier is enough for most B2B lists. After that you are often paying for overlapping databases. Add a specialist only when you can show it recovers verified rows your current chain misses.
What do I do with catch-all results in a waterfall?
Park them. Do not let a finder or a verifier relabel accept-all as valid on the primary list. Confirm the person exists some other way, and if you send at all, use spare inboxes - not the domain that books meetings.
Is Clay required to run waterfall enrichment?
No. Clay is one orchestrator. APIs, other GTM workbenches, and done-for-you stacks all implement the same fallback idea. Judge the output: verified, qualified, you would send it. Not the number of providers in the screenshot.