9 Signs Your Enrichment Waterfall Is Bleeding Money

A wasteful enrichment waterfall almost never throws an error. The Clay bill stays inside budget, the dashboards look fine, and the money leaks out anyway, one over-enriched row at a time. That is what "bleeding money" means here: not a failure state, a cost structure nobody is checking.

Data enrichment wasting budget rarely announces itself. It shows up months later, as a spend nobody remembers approving and a cost-per-usable-row number nobody can quote on demand.

The nine patterns below are the ones I keep running into. Each gets a way to spot it in your own table this afternoon, and the fix.

1. Duplicate provider calls on the same row

Spot it: the same contact gets enriched twice because two workflows both touch the table, or because nobody ran identity resolution first and one person's three email addresses get treated as three records. Each pass burns full-price credits on someone you already had.

A waterfall is supposed to prevent this. Clay's own guide to waterfall enrichment describes the sequential design as the built-in defense: the second provider only sees what the first one missed. But that protection only holds when there is truly one entry point into the table, not two workflows writing to it under different names. Two automations writing to the same table quietly defeats it.

Fix it: one entry point per table, deduped before the waterfall runs. Not after.

2. Credit spend on rows that were never going to be worked

Spot it: enrichment runs on a full list export the moment it lands, before anyone filters for ICP fit or list hygiene. A thousand-row export becomes a thousand-row enrichment job, and a third of those rows were disqualified, wrong size, wrong region, already a customer, before the waterfall ever touched them.

Filter first. Then enrich only the subset that will get worked. That is where the 200 to 500 row discipline earns its keep: small enough to review, large enough to run a real campaign against.

But enrichment spent on a row nobody will contact is not a rounding error. Not at scale. It is most of the waste.

3. No match-rate threshold set per provider

Spot it: every provider in the chain accepts whatever it returns, so a low-confidence guess from provider three looks identical to a verified hit from provider one. And nobody can tell which rows to trust without opening each one by hand.

The fix is setting a confidence floor per provider, and routing anything under that floor to the next step instead of accepting it. A provider that returns a match confidence score is telling you something. Use it. But ignoring it defeats the reason a waterfall has more than one provider in the first place.

Thresholds do not need to match across providers, either. Tune per field, not across the board.

4. Wrong provider order for the segment

Spot it: the waterfall runs the same provider sequence against every segment, no matter where that segment's data lives. And an EU-weak provider going first against a European list burns its call on almost every row.

The fix is ordering by segment, not by habit: cheapest and best-covered provider first, expensive precision providers seeing only what is left. Not the other way around. Clay's own guide to waterfall enrichment shows the shape of this: cheapest-and-best-coverage first held 94% usable coverage at $39 total on a 100-record sample, against a higher cost when an expensive provider ran first. That is one vendor's worked example, not a universal number. But the direction holds: order by fit for the segment, not by however the table got built.

5. Re-enriching stale rows on a fixed schedule instead of on signal

Spot it: a recurring job re-runs the full waterfall on a calendar cadence, weekly or monthly, regardless of whether anything about the row changed. Most of what comes back is identical to what you already had, at full price.

The fix is refreshing on a trigger instead of a date: a job change, a funding event, re-entry into an active campaign. Those are the moments a record is likely to have changed. But a calendar cannot tell you that. A trigger can.

A quarterly full-file refresh still has a place for hygiene, catching bounced domains and dead companies. But it should not carry the bulk of the spend.

6. Enrichment before qualification, not after

Spot it: full-record enrichment happens before anyone checks whether the account or contact fits the ICP at all. The waterfall does its job well. But it is just doing that job on rows that should never have reached it.

And the fix is running a qualification pass before you enrich: a cheap firmographic filter and an exclusion list first, full waterfall only on what survives.

This is not quite Sign #2's problem. That one filters a raw export before it touches the waterfall. This one sequences inside a list that already passed that filter, checking fit at the account or contact level before spending waterfall credits on it.

7. No cost-per-usable-row number anyone tracks

Spot it: the team can quote last month's Clay bill from memory but cannot say what it cost to produce one usable, verified row. Total spend divided by rows attempted is not the same number. But it flatters a wasteful waterfall.

The fix is dividing total spend by usable rows delivered, not rows attempted, and checking that number after every change: a new provider added, a threshold adjusted. Clay's own worked example, cheapest-first ordering reaching 94% usable coverage at $39 on a 100-record sample, is a useful shape for the calculation, not a benchmark to hit.

Credit expiration with no rollover compounds this. Unused capacity from a slow month does not carry forward, per ForMaNorden's comparison of enrichment tools, and next month's real cost per row goes up before the waterfall even runs.

8. No identity resolution before the waterfall runs

Spot it: the same person shows up under two or three email addresses across systems, and the waterfall enriches each one separately, at full cost, before anyone notices they are the same contact.

A standard waterfall has no built-in way to catch this. Not without help. Without an identity-resolution step first, per GTME Pulse's review of B2B data waterfall tools, it treats one person's multiple email addresses as separate records, each running the full provider chain on its own.

And the fix is resolving identity before enrichment starts: match on name, company, and any shared identifier you already have, collapse to one record, then run it once. Deduping the output instead of the input has already spent the money it was supposed to save.

9. Nobody owns the spend

Spot it: the enrichment tool got set up once, works well enough that nobody revisits it, and slowly becomes infrastructure nobody questions.

Tools set up without a dedicated owner become, in ForMaNorden's phrase, "expensive shelfware within a quarter." But a waterfall with nobody watching it drifts the same way: a provider added and never removed, a threshold loosened under deadline pressure and never tightened back.

The fix is naming an owner and putting cost-per-usable-row on a recurring review. Monthly is enough for most teams. Kill or retune whatever is not earning its keep. Without that review, the provider nobody removed keeps getting called every cycle, and the threshold loosened under last quarter's deadline never tightens back on its own.

None of this requires ripping out your stack. Most of it is sequencing and ownership, not tooling. And if you want the mechanics behind two of these signs, the API-vs-orchestration cost question covers what changes when you call providers directly instead of through Clay's UI. How Clay's credit and Actions pricing actually works explains the model several of these patterns exploit.