A waterfall in Clay asks several data providers for the same field, one after another, in an order you set, and stops as soon as one returns a result that passes your validation rules. Clay's documentation describes waterfalls as a way to "utilize multiple data providers in a predetermined sequence, so you don't duplicate tasks or spend extra credits" (Clay docs). That one sentence contains the whole design problem: the sequence and the definition of "valid" decide both your coverage and your bill.
If you are new to the tool, start with What is Clay?. This article goes one level down: what happens inside a waterfall, why coverage stops improving, and how to decide whether the next provider is worth adding.
In short
- A waterfall is a stop-on-success chain, not a parallel query. The stop condition is the most important setting in it.
- Clay's Work Email waterfall cascades across providers "stopping as soon as one returns a valid result," and the docs state you pay for the provider that finds the match (Clay docs).
- There is a free inference step before any paid provider runs. Most teams leave it off.
- Validation is part of the waterfall, not a cleanup job afterwards. Conservative, Balanced and Aggressive strategies change what counts as a stop.
- Cost has two meters: Actions for platform work and Data Credits for purchased data (Clay docs).
- Provider order should come from your own hit-rate log, not from a template.
What actually happens when a waterfall runs
Think of a row as a request that walks down a staircase. At each step it asks one provider a question: what is this person's work email? Three things can happen.
- The provider returns nothing. The row goes down one step.
- The provider returns something that fails validation. The row goes down one step.
- The provider returns something that passes validation. The row stops. Everything below never runs.
Case 2 is where budgets leak. A waterfall that treats "any string with an @ in it" as success stops early and often: high apparent coverage now, a high bounce rate two weeks later. A strict stop condition walks further down the stairs, costs more per row, and produces a list you can actually send to.
So the first design question is not "which providers?" It is what am I willing to accept as an answer?
The free step most teams skip
Clay's Work Email waterfall includes a setting called Infer Email. It builds a candidate address from a naming pattern before any paid provider runs; if that candidate passes validation, the waterfall stops there at no data-credit cost (Clay docs). The waterfall needs the person's name and the company domain, and the email pattern defaults to first.last@domain.com.
That default is the catch. Inference works when you already know the pattern for that domain — and in a list concentrated in one industry or one region, you often do. The practical move is to discover the pattern on a sample, then set it, rather than accepting the default and concluding inference doesn't work.
The same page documents two more cost settings worth turning on: showing which provider found each email, and a duplicate result threshold that stops the chain from burning credits when the same invalid address keeps coming back from provider after provider.
Validation is part of the waterfall
Clay's Work Email waterfall exposes validation as a strategy, not a checkbox. The documented options are Conservative (the safest, all verified email types), Balanced (moderate risk, includes catch-alls), Aggressive (higher risk, maximum coverage) and Advanced (manual configuration) (Clay docs).
To choose between them you need to know what the statuses mean. Clay documents five (Clay docs):
| Status | Clay's definition, in short | What we do with it |
|---|---|---|
| Valid | Specific, active addresses that can receive email | Send. This is the asset you are paying for. |
| Invalid | Addresses that do not exist | Delete from the sending list, keep the row for the record |
| Catch-all | Domains that accept all addresses, even unmonitored ones | Never mix into a cold sequence on a new domain; route to a lower-risk channel or a human |
| Unknown | Could not be verified, often a temporary mail-server issue | Retry later before discarding |
| Role-based | Tied to a function (info@, sales@) rather than a person | Treat as a company inbox, not a contact |
Two operating rules follow from that table. First, catch-all is a decision, not a status — the moment you accept catch-alls as a stop condition, you have decided to trade sender reputation for list size, and you should decide that deliberately per campaign, not once in a template. Second, statuses expire. Clay's docs advise re-verifying over time, which is the real argument for storing the verification date next to the address.
The three numbers that decide provider order
Clay lets you reorder, add and delete providers in a waterfall and toggle individual steps off (Clay docs). What it cannot do is tell you the right order for your market. That has to be measured.
Clay models the discipline itself: it publishes provider data tests that build separate datasets for small businesses and enterprises, score results by confidence, and compute cost per verified email — with a methodology that penalises a wrong match more heavily than a miss (Clay docs). Don't copy its results, because coverage shifts and your segment is not its dataset. Copy the method.
Three numbers per provider, per segment:
- Hit rate — of the rows that reached this step, what share did it answer with a result that passed validation?
- Marginal cost — what does it cost to run, and only on the rows that got that far?
- Downstream quality — of the addresses it supplied, what share bounced or produced a hard failure?
A provider with a 60% hit rate on rows nobody else could solve is more valuable than one with a 60% hit rate on rows the first provider already handled. Waterfall value is always marginal, which is why you cannot judge a provider by a standalone test.
The MitHub Waterfall Ledger
This is the artifact we teach people to keep. One row per provider, per segment, updated after every few hundred enrichments. It takes minutes and it turns an opinion into an argument.
| Provider | Segment | Rows reached | Valid results | Hit rate | Bounce rate on its results | Position now | Position next |
|---|---|---|---|---|---|---|---|
| A | US, 10–200 employees | — | — | — | — | 1 | ? |
| B | US, 10–200 employees | — | — | — | — | 2 | ? |
| C | LATAM, 10–200 employees | — | — | — | — | 1 | ? |
Three things make it work. Segment it — a provider that is excellent for US mid-market can be useless for a 15-person firm in Colombia, so one global order guarantees you are wrong somewhere. Record which provider answered — Clay can output the successful provider's name, and without that column the ledger is impossible. Set a review date — re-order quarterly or after a market change, not continuously.
How to run a provider bake-off
Clay's own cost guidance recommends testing new workflows on 10–20 records before scaling (Clay docs). For a provider comparison, go slightly bigger and be strict about the sample:
- Take 200 rows from the segment you actually sell to — not your easiest accounts.
- Run each candidate as its own column, in parallel, once. This is the only time you deliberately pay several providers for the same row.
- Score every result against the validation statuses above, and review the rows where providers disagree.
- Compute hit rate, cost per valid result, and overlap — how many rows only this provider solved.
- Order by cost per valid result, but promote any provider with high unique coverage: that is exactly what a later step is for.
- Send one small campaign and record the bounce rate per source provider. That number settles arguments.
The marginal contact test
A hypothetical, to show the arithmetic — not a MitHub result. Imagine a fourth provider adds 4 more valid emails per 100 rows, you get a reply from roughly 2% of the people you contact, and you close roughly 1 in 10 of those conversations. That is 0.008 deals per hundred rows. Multiply by your average deal value and compare it to what the provider costs across the rows that reach it.
Sometimes one deal pays for a year of enrichment and the answer is obviously yes. The point is that "add another provider" is an investment decision with a number attached, and most teams never compute it — the same backwards arithmetic taught in Follow the money, applied to one column.
Where waterfalls quietly waste money
Clay meters two different things: Actions, the platform work of running an enrichment, and Data Credits, the data bought from providers in its marketplace. Connecting your own provider API keys removes the Data Credit cost for those calls, but the docs are explicit that an Action is still consumed (Clay docs). So "bring your own key" reduces one meter, not both, and it never makes a badly ordered waterfall cheap.
The recurring leaks:
- Enriching before filtering. Clay's cost guidance says to narrow the dataset to relevant records first. A country filter costs nothing and can remove a third of the rows.
- Re-running rows that already have a valid answer. The docs describe running enrichments only when a field is empty, the data is outdated, or confidence is low — and waterfall run settings support conditions and auto-update (Clay docs).
- Enriching people at accounts that failed the fit check. Contact data is the expensive layer. It belongs after the score.
- Chasing the last 5% of coverage. That is where cost per contact rises fastest and quality falls.
- Enriching fields nobody uses. If a field feeds no score, message or routing rule, it is a hobby.
- No spend ceiling. Clay documents per-workbook Data Credit spend limits for enterprise admins; an unbounded table eventually runs away.
Beyond email: phones, firmographics and the same logic
Waterfalls are not an email feature. Clay's general guide references choosing "the data point you want to run a waterfall for (ex. Phone number)" and reusable waterfall templates that standardise a configuration across tables (Clay docs). The logic transfers; the stop condition changes:
- Phone numbers. "Valid" means a correctly formatted, callable line of the right type — and if you will dial it, local calling rules matter more than coverage.
- Firmographics (headcount, industry, location). Providers disagree here constantly, and stopping at the first answer hides the disagreement. For fields that drive scoring, pull two sources and flag conflicts instead.
- Anything no database ever recorded. That is not a waterfall job — it is research. See Claygent: using AI research agents in Clay.
Templates are what turn a good waterfall into a standard: a new teammate builds the table correctly by default instead of rediscovering the order. That is the difference between a task and a system, and the whole argument in build systems, not just tasks.
Checklist before you run a waterfall on 10,000 rows
- The stop condition is written down: which statuses count as success
- The free inference step is configured with the real pattern, not the default
- Rows are filtered before any paid step runs
- Contact enrichment runs only on accounts that passed the fit check
- The "which provider answered" column is on
- Duplicate-result thresholds are set
- Run conditions prevent re-enriching rows that already have valid data
- A 200-row bake-off backs the current order, with a review date
- The verification date is stored next to every address
- Someone owns the ledger, and the bounce rate is reported back into it
That last line is the one that separates a GTM engineer from a tool operator. The waterfall is not finished when the column fills. It is finished when the results come back from the campaign and change the order. If you want the full build discipline around that loop, read Clay for GTM engineering, and then decide where the enriched record should land in connecting Clay to HubSpot, Salesforce and Zoho.