How to Build a Cost-Efficient Waterfall Enrichment Table in Clay

Clay's core advantage over a single-vendor data provider is waterfall enrichment: chaining multiple providers so each one fills in what the last one missed, which genuinely does push match rates well above what any single source achieves alone. It's also the single easiest place to overspend Clay's dual credit system, since a waterfall built without cost discipline runs every provider on every row regardless of price, and Clay's credit-based billing means that inefficiency shows up directly on the invoice rather than staying invisible the way it might in a flat-rate tool. Here's the setup that gets the match-rate benefit without the unnecessary spend.

For background on what Clay is, how its dual credit system actually works, and who it's built for, see our full Clay profile.

The steps below assume you already have a specific enrichment goal in mind, a particular field or research question the waterfall needs to resolve, rather than building the table first and figuring out what to do with the data afterward. Clay's flexibility makes it tempting to enrich broadly "just in case" a field turns out useful later, but every additional column in the waterfall is additional credit spend across every row, whether or not that data ends up used in the final outreach or CRM record.

Step 1: Start With a Clean Seed List, Not a Raw Export

Import the base list of leads or accounts into a Clay table from a CRM export, a source query, or another upstream tool, and do a basic quality pass before enrichment starts, removing obvious duplicates or clearly invalid rows. Every row that enters the waterfall consumes credits regardless of whether it was a genuinely useful record to enrich in the first place, so cleaning the seed list before enrichment begins is the cheapest cost-control step available, and the one most often skipped in favor of just importing everything and letting the waterfall sort it out.

Step 2: Add a Waterfall Column and Order Providers Cheapest-First

Add a new column, select Waterfall as the column type, and set the required data type and input fields it needs (an email address or a LinkedIn URL, for instance). The critical decision here is provider order: put lower-cost, high-coverage providers first, since they'll resolve a large share of rows on their own, and place premium, more expensive providers later in the sequence so they only fire on the rows the cheaper providers couldn't resolve. Ordering by perceived data quality instead of cost, running an expensive premium provider first "to be safe," means paying premium rates on every single row, including the majority a cheaper provider would have resolved just as well.

Step 3: Configure Output and Run Settings Deliberately

Set the waterfall to optionally output which specific provider successfully resolved each row, and hide the individual provider columns once configured so the table stays readable rather than cluttered with intermediate data. Configure run settings, whether the column auto-updates continuously or only runs under specific conditions, deliberately rather than leaving it on a default that might re-run enrichment repeatedly on rows that already resolved successfully, silently consuming credits for data that hasn't changed.

Step 4: Reserve Claygent for Genuinely Unstructured Research

Use Claygent, Clay's AI research agent, specifically for questions a structured data provider can't answer directly: whether a company mentions a specific technology on its site, whether it offers a free trial, or a synthesized read on recent news relevant to a specific outbound angle. Running Claygent for data a standard enrichment field already covers, like a basic firmographic lookup a waterfall provider handles more cheaply and reliably, spends AI-action credits on a job a data-credit lookup would have done for less, and produces a less consistent result in the process.

Step 5: Structure AI Formula Outputs Instead of Freeform Text

When using an AI formula column to extract, score, or restructure information already present in the table, set the output format to a structured form, a JSON object with fields like a score and a reasoning string, rather than freeform prose. A structured output lets downstream columns and conditional logic actually filter and route on the result, a qualification score above a threshold routing to one track, below it to another, in a way that unstructured text output makes far harder to build reliable logic around.

Step 6: Revisit Provider Order Periodically, Not Just Once

Data provider coverage and pricing shift over time, a provider that was the most cost-effective option when the table was first built can lose that position as coverage changes or pricing updates. Treat the waterfall's provider order as something to review periodically against actual match-rate and cost data from the table's run history, rather than a decision made once at setup and left untouched indefinitely. A quarterly check against which providers are actually resolving which share of rows, at what cost, is enough to catch drift without turning table maintenance into a constant task.

Step 7: Test the Full Table on a Small Row Sample First

Before running a newly built waterfall and Claygent workflow against the full list, run it against a small sample, twenty to fifty rows, and manually check the results for accuracy and unexpected credit consumption. Credits are spent per row per column, which means a misconfigured column, a provider ordering mistake, or a Claygent prompt that's more expensive or less accurate than expected shows up immediately and cheaply on a small sample, rather than expensively across the entire list after a full run.

Step 8: Filter Before Pushing the Table Downstream

Before exporting or syncing the enriched table into an outbound tool or CRM, filter out rows where enrichment genuinely failed across every provider in the waterfall, rather than pushing the entire list forward regardless of data completeness. A downstream outbound sequence built to reference a specific enriched field, a job title, a tech stack detail, produces a broken or generic message for any row that field never actually resolved, which undermines exactly the kind of specific, evidence-backed personalization the enrichment work was meant to support in the first place.

A Few Mistakes That Undo the Cost Savings

A handful of habits reliably undo the discipline above even in an otherwise well-built table. Reordering the waterfall to put a "better" provider first whenever a specific row fails, rather than adjusting the fallback sequence systematically, turns a carefully cost-ordered waterfall into an inconsistent one over time as one-off exceptions accumulate. Leaving auto-update enabled indefinitely on columns that don't need continuous refreshing means credits get spent re-resolving data that hasn't meaningfully changed, quietly inflating a monthly bill for no added value. And treating Claygent as a default first step for every research question, rather than reserving it for genuinely unstructured queries a data provider can't answer, is the single fastest way to burn through action credits on work a cheaper, more reliable waterfall lookup would have handled just as well.

What This Workflow Actually Produces

Set up this way, a Clay table delivers the genuine match-rate advantage of waterfall enrichment across many providers, without the unpredictable credit spend that comes from running every provider on every row regardless of cost. That's a meaningfully more sustainable setup than a table built once with default ordering and never revisited, and it's the difference between Clay's flexibility paying for itself and its dual credit system quietly becoming the most expensive part of the outbound stack.

One caution worth carrying past the credit math itself: a well-built enrichment table is only the raw material for outreach, not finished personalization on its own. Our piece on why AI-personalized cold outreach is backfiring even when it's accurate covers why restating an enriched fact directly into an email, however cleanly Clay resolved it, tends to underperform outreach built on an actual inference about what that fact implies for the recipient.

If you're still deciding whether Clay's flexibility is worth the setup time compared to a single-vendor database, our Clay tool profile covers the full credit-based pricing breakdown in more detail.