Most Clay waterfalls I audit share the same three problems: providers stacked in the wrong order, no cost ceiling per row, and no kill switch when the fill rate drops below break-even. They look clever on the canvas, but they burn credits on rows that will never convert, and they still miss the 20% of prospects that make the campaign work.
This is the exact waterfall structure I build for every new engagement, plus the three guardrails that keep credit spend predictable. It assumes a B2B list in the 2,000–10,000 prospect range and an ICP where verified work email is the bottleneck — not phone, not LinkedIn, not intent.
What “working” means here
Before I touch the table, I set three numbers:
- Verified-email fill target: 55–65% of rows. Anything above that means the ICP is too broad; anything below usually means the seniority or company-size filter is off.
- Credit cost ceiling per enriched row: $0.08–$0.12, depending on the tier. I cap it at row-level, not at the waterfall level.
- Total table credit budget: the enrich credits I’m willing to spend before pausing and reviewing quality. For a 5,000-row table, I cap this at 60% of the credits I’d need to run the full list.
If I blow any of those numbers in the first 500 rows, I stop and fix the upstream sourcing before continuing. That one discipline saves more credits than any fancy fallback logic.
Assumption: you already have a ranked list of prospects with first name, last name, and a company identifier (domain or LinkedIn URL). If you’re using Clay to source the list as well, that’s a separate waterfall — this piece covers the enrichment step after sourcing.
Days 1–2: Pick your providers by ICP, not by brand
The single biggest mistake I see is treating Clay like a magic button: people plug in every provider they have credits for and hope coverage emerges. It doesn’t. Each provider has a different coverage profile by region, company size, and seniority, and stacking them in the wrong order means you’re paying premium rates to confirm what the cheap provider already found.
Here is the order I actually use, and why:
Step 1 — Start with the cheapest high-coverage source
For US SMB (under 500 employees), that’s usually Apollo first. Apollo’s fill rate on US SMB is 70–75% in my lists, and the cost per enrichment is the lowest in the stack. Running Apollo first means about two-thirds of your rows never touch a second provider, and your average row cost drops to $0.04–$0.06.
For EU mid-market, I flip this: I lead with Cognism because Apollo’s EU coverage is sharply lower (especially for Germany, France, and DACH where GDPR-compliant sources matter).
For enterprise (1,000+ employees, Director+), I still start with Apollo but I expect a lower fill rate (~55%) — enterprise contact data rots faster, and the cheap providers aren’t refreshing at the pace the tier demands.
Step 2 — Add one mid-cost provider as a fallback
Only for rows where step 1 returned nothing. This is where Datagma or Hunter fits, depending on what your step-1 misses look like.
A specific rule I use: if step 1 returned a LinkedIn URL but no email, use Hunter’s email-from-LinkedIn lookup. If step 1 returned a company match but no person match at all, use Datagma’s person-search instead. These are two different failure modes and they need two different fallbacks. Sending every step-1 miss to the same step-2 provider is how credit budgets die.
Step 3 — Reserve one premium provider for the last 15–20%
This is ZoomInfo or Lusha for North America, Lusha or Kaspr for EU. These are 4–6x the cost per enrichment of step 1, which is why they’re last.
The rule is hard: premium providers only run on rows where (a) both prior steps returned nothing and (b) the row has a priority score above a threshold you set upstream (usually tier 1 accounts or matched ICP signals). Never let a premium provider run on a row you already decided wasn’t worth top-tier spend.
If you don’t have a priority score on the row, add one before you build this waterfall. Without it, step 3 will eat 60% of your credit budget on 15% of the list.
Step 4 — Verification pass
Every email that makes it out of steps 1–3 runs through a verifier — either NeverBounce, ZeroBounce, or Clay’s built-in verifier. This is not optional. The cost is $0.003–$0.008 per check, and it prevents your sequencer from hitting catch-alls and bouncing 8% of your sends into spam folders on day one.
I mark rows with three verification states:
- Valid — send.
- Catch-all — send with a different domain rotation, only after the other domains have warmed up. Never the lead-off send on a new domain.
- Invalid/unknown — drop, or push back to Clay for a re-enrichment run in 30 days.
Insider note: catch-all rates vary wildly by vertical. In software (engineering titles, startups under 200 employees) it’s 5–10%. In manufacturing and legal it’s 35–45%. If you’re running outbound to sectors with high catch-all rates, budget for it, and don’t let a clean-up engineer throw those rows away.
Days 2–3: Build the fallback logic, not the providers
A Clay waterfall is just a chain of conditional provider calls. The value isn’t in the providers — it’s in the conditions that gate each call. Get the conditions wrong and you’ll pay premium rates on rows that shouldn’t have gone past step 1.
Here’s the conditional logic I set for each step:
Between step 1 and step 2
Run step 2 only when:
– step_1.email is blank AND
– step_1.person_match_confidence < 0.8 AND
– row has a valid LinkedIn URL or verified domain
The third condition matters. If step 1 already told you the company doesn’t exist (bad domain, wrong LinkedIn URL), step 2 is going to waste credits proving the same thing.
Between step 2 and step 3
Run step 3 only when:
– Both step 1 and step 2 returned no email AND
– row.priority_tier = 1 or 2 (i.e. not tier 3 or disqualified) AND
– company employee count is above your ICP minimum (usually 50+)
That third condition keeps premium providers off your long-tail, which is where the ICP match is usually weakest anyway.
Before the verification step
Only send rows with a populated email to the verifier. Sending empty rows to a verifier is a free way to waste credits on nothing — it happens more often than it should, because people forget to gate the verifier call.
Days 3–4: Add the three cost-control guardrails
Now the waterfall is structurally sound. The remaining work is making sure it stops itself before it overruns the budget.
Guardrail 1 — Per-row cost ceiling
In Clay, use a formula column that sums the expected credit cost at each step (providers publish their per-enrichment cost in credits). If the sum would exceed your row ceiling (I default to $0.12), the row short-circuits and routes to a manual review queue.
This catches the bug where a row somehow runs through all three providers plus two verification rounds. It shouldn’t happen, but it does, and it’s always expensive.
Guardrail 2 — Fill-rate monitor
Run a summary every 500 enriched rows:
– Actual fill rate vs. your 55–65% target.
– Actual average cost per enriched row vs. your ceiling.
– Catch-all % vs. your tolerance.
If any of the three is off by more than 15%, pause the waterfall. Nine times out of ten the fix is upstream — the sourcing filter is too broad, the industry filter is missing, the seniority tier shifted. Fix sourcing first, not the waterfall.
Guardrail 3 — Total credit budget cap
Set a hard cap in Clay’s table settings equal to 60% of the credits a full run would take. The table pauses automatically when you hit it. You review, fix, and resume. You never get a “ran out of Apollo credits mid-campaign” call from your team at 2 pm on a Tuesday.
Days 4–5: Test, measure, calibrate
Run the first 500 rows end-to-end. Don’t run the rest of the table yet. What I’m looking at:
Quality signals
- Person-match confidence distribution. If 30%+ of step-1 matches are below 0.8 confidence, your input data is dirty. Usually this is a sourcing issue — wrong company domain, typos in first/last name, stale LinkedIn URLs.
- Catch-all distribution by domain. Sort the catch-alls by company domain. If 5 domains account for 40% of catch-alls, those domains are using a catch-all configuration — drop them or route them through a dedicated send schedule later.
- Verification mismatch. Any email that step 1 returned as “verified” but the independent verifier marked invalid. Under 5% is normal. Over 15% means step 1’s verification is unreliable for this ICP and you should verify everything.
Cost signals
- Actual per-row cost. Bucket by step: rows that stopped at step 1, step 2, step 3, or hit the manual queue. If more than 20% of rows hit step 3, your waterfall isn’t working — step 1 and 2 aren’t covering the ICP the way you expected. Time to reconsider provider order.
- Verifier spend. Should be 3–8% of the total enrichment spend. If it’s higher, you’re verifying too many rows (maybe you forgot the gate that drops empty emails), or your enrichment fill is unusually high and the list is smaller than expected.
Calibration
After the first 500 rows:
- If fill rate is low and quality is good: add another step 1 fallback (a second cheap provider before step 2). Saves premium spend.
- If fill rate is fine but cost is high: tighten the step 3 gate. You’re letting premium providers run on rows that shouldn’t qualify.
- If quality is bad across the board: fix sourcing. The waterfall can’t save a bad list.
The final checklist
Before I let a waterfall run unattended on a full table, every one of these has to be true:
- [ ] Providers ordered by cost, cheapest first, most expensive last.
- [ ] Each fallback call is gated by a specific condition, not just “if the prior step was blank.”
- [ ] Verification is mandatory on every email that makes it out of enrichment.
- [ ] A priority-tier column exists and gates premium provider calls.
- [ ] Per-row cost ceiling is set and enforced.
- [ ] Fill-rate + cost monitor runs every 500 rows.
- [ ] Total credit budget cap is set to 60% of full-run expected spend.
- [ ] First 500 rows have been sanity-checked before the rest of the table runs.
Skip any of these and the waterfall will technically work. It just won’t work the way your credit budget needs it to.
When this doesn’t apply
Two scenarios where I build something different:
-
Very small lists (under 300 rows). The overhead of a 3-provider waterfall is worse than just running Apollo + verifier and accepting the 25–30% that come back empty. Handle those by hand. A waterfall is amortization logic — below 300 rows, there’s nothing to amortize.
-
Signal-rich sourcing (hiring, funding, technographic). When the list is already narrow because of a strong signal upstream, I often skip straight to a premium provider + verifier. The ICP match is so tight that the premium cost is justified, and the cheap providers’ lower data freshness hurts more than their lower cost helps. This happens more often than you’d think, especially in executive and fractional-leader campaigns.
What to build next
Once the waterfall is stable, the next upgrade is intent signal layering on top — pulling hiring, funding, and technographic signals from Clay’s sources and using them to re-rank your enriched list before it goes into a sequencer. That’s a separate playbook. But the prerequisite is a waterfall that produces reliable, cost-predictable enriched data in the first place.
Get this piece right and everything downstream is easier. Get it wrong and no amount of clever copy will save the campaign.