Building a waterfall enrichment in Clay that doesn't burn your credits

The first enrichment table I built in Clay was a credit bonfire. Five email providers, all running in parallel, on every single row. It found a lot of emails. It also found the same email four times and charged me for each.

The fix is boring and well known: a waterfall. Run the cheapest provider first, and only call the next one when the previous result is empty. What’s less obvious is how much the ordering and the stop conditions matter.

Waterfall enrichment: each provider only runs when the previous one came back empty

Order providers by cost per hit, not cost per call

The naive ordering is “cheapest call first”. But a cheap provider with a 15% hit rate on your segment is expensive per email found. What you actually want is cost per successful result.

I ran 300 rows from our ICP through each provider in isolation and tracked:

credits per call
hit rate on our specific segment (SaaS, 50–500 employees, EU)
how many of those hits survived verification

That last column reshuffled everything. One provider had a great hit rate and terrible deliverability — half its emails bounced. It went from first to last.

Make “empty” mean empty

A waterfall only works if each step knows when to stop. In Clay that means a run condition on every column after the first:

Run only if: {{Provider A email}} is empty

Two traps I fell into:

Catch-all domains. Some providers return a guessed email on catch-all domains. It’s not empty, so the waterfall stops — on an address you can’t trust. I now treat catch_all results as empty unless verification marks them as safe.
Error vs. no result. A rate-limit error is not the same as “no email found”. If you don’t separate them, a burst of errors silently skips the rest of the chain.

Verify once, at the end

Verifying after every provider doubles your verification spend. I merge all provider outputs into a single “best email” formula column, then run one verification step on that. Anything that fails verification gets one more pass through the remaining providers, and that’s it.

What it saved

On a 4,000-row table, the waterfall used about 38% fewer credits than the parallel version, for roughly the same number of verified emails. The ordering work took an afternoon. It paid for itself in the first week.

The general lesson: in GTM tooling, the expensive part is rarely the tool. It’s running it on rows that didn’t need it.