Enrichment credits are a tax on bad filtering

Every enrichment API charges per lookup. That’s the model, and the model is fine. The problem is that most teams spend those lookups on companies they should have filtered out before enrichment ever started. Enrichment credits aren’t a data cost. They’re a tax on bad filtering.

Here is where the money leaks. A team pulls a broad list, maybe from Apollo, maybe from a scrape. They load it into Clay. They enrich every row: company firmographics, contact discovery, email finding. Then they filter. The filtering removes a third of the list as non-ICP, another chunk as duplicates, another as already in the CRM. All of those rows were enriched first, at full cost, and then thrown away. The credits are spent. The contacts were never going to be contacted. The spend bought information that was discarded in the same run.

This feels productive, because enriching produces rows, and rows feel like progress. It’s the opposite. It’s spending dollars to learn what pennies would have told you, every single run.

The fix is an order-of-operations problem, and the correct order is cheap-first. Filter before you enrich. The cheap operations, does this company fit the industry and size profile, is it in our geography, is it already in the CRM or an active deal, is it a competitor, are rules and regex and set lookups. They cost fractions of a cent, or nothing. They should run before a single enrichment credit is spent, because their entire job is to decide whether the enrichment credit is worth spending at all.

Then enrich the survivors. Then verify, because verification is the most expensive operation and the last one you want to waste. The progression is filter, enrich, verify, with the cost rising at each stage and the record count falling. By the time you’re paying for verification, you’re only paying for contacts that already passed two filters and an enrichment. The cost per qualified contact drops by a multiple.

The reason most teams do it backwards is that filtering is invisible and enriching is visible. Enriching fills a table. The table looks like work. Filtering empties a table, and an emptied table looks like you did less. So teams enrich first, because a full table feels like progress, and they eat the credit cost of every row they later delete. The discipline is to make the filter the gate, accept the smaller table, and measure cost per qualified contact instead of rows enriched.

There’s a second leak that runs alongside the first: duplicates. If you enrich the same contact twice because two sources returned them under slightly different identifiers, you pay twice. Dedup belongs at the write path, before enrichment, keyed on whatever stable identifier you actually hold, company domain, LinkedIn URL, provider primary key. Dedup after enrichment is a refund you’ll never get.

The metric that exposes the whole problem is cost per qualified contact. Take your monthly enrichment spend and divide by the number of contacts that actually passed verification and entered a sequence. Most teams have never run this division, and the result is usually two to three times what it should be, because the denominator is being shrunk by filtering that happened after the spend. Run the number once. If it’s high, the fix isn’t a cheaper vendor. The fix is moving the filter upstream of the credit.

I build the checkpoint that sits between the list and the enrichment. It’s the least glamorous part of the pipeline and the one that pays for itself fastest. Worth a 30-minute look at your stack? → Book a call.