Why Clay implementations fail, from someone who gets called in to fix them

We are a certified Clay Artisan Partner, and a meaningful share of our work is rescue work: somebody calls because credits are gone, coverage is poor, or sales has stopped trusting the records landing in the CRM. The patterns repeat. Here they are.

Pattern one: tables were built before the ICP was written down#

This is the origin of most of the others.

Clay is a very good tool for answering a question about a defined set of companies. It is a very bad tool for working out what that set should be, because it will return data on anything you point it at and none of that data tells you whether the company should have been on the list. Teams that open a table before agreeing the ICP end up using enrichment as a substitute for a decision, and enrichment is not a decision, it is a bill.

The version of this we see most often is a target list built from a firmographic filter that nobody argued about. No disqualifiers, no minimum size, no exclusion for companies that already bought a competitor. The list looks defensible in a slide and produces a reply rate that nobody can explain, because it contains four different buyers with four different problems.

Pattern two: the waterfall is ordered by habit, not by cost#

A waterfall exists so that a cheap provider answers first and an expensive one is only asked when the cheap one comes back empty. That is the entire point of the structure.

What we find instead is waterfalls ordered by whichever provider the team trusts most, which usually means the most expensive one runs first on every row and the cheaper fallbacks almost never fire. Coverage looks fine, because it is fine. The cost per enriched record is several times what it needed to be, and nothing in the interface flags that, because from Clay's point of view the table is working exactly as configured.

The diagnostic takes about twenty minutes: for each waterfall, list the providers in the order they run and the cost of each, then check whether that order is ascending. It usually is not.

Pattern three: paid enrichment runs on rows that were never going to qualify#

Run conditions are the single largest lever on Clay spend, and they are the thing most often missing from a build we are asked to fix.

Without one, every row in the table reaches every paid step. A company with the wrong headcount, in the wrong country, in an industry you disqualified on the first call, still gets an email lookup, a technographic check, and whatever else the table does, at full price. The row is then filtered out three columns later, after you have paid for all of it.

The ratio worth calculating, which almost nobody has: rows enriched divided by rows actually contacted. If you enriched ten thousand and sequenced eight hundred, you bought nine thousand two hundred rows of data in order to reach a conclusion your filters could have reached for free.

Pattern four: the CRM sync went live before the matching logic was right#

This is the most expensive failure of the four, because the damage is not in Clay.

Clay makes it easy to push records into HubSpot, Salesforce or Attio, and the push works immediately, which is the problem. Duplicate companies arrive under slightly different names. Contacts attach to the wrong account. Fields overwrite values a human entered. Two months later the CRM is a source nobody trusts, reps have gone back to their own spreadsheets, and the enrichment programme gets blamed for a data quality problem it merely delivered at speed.

Cleaning that costs more than the enrichment did, and it costs it in the currency you have least of, which is the sales team's confidence in their own system.

The Vidyard build is the counter-example worth reading: a migration to Clay across marketing, sales and post-sales, with the matching and deduplication logic settled before anything wrote to the CRM. It produced a 13% win rate lift in target segments and flagged 120 plus at-risk accounts early, and it did that because the records reps saw were ones they believed.

“

We were able to improve our win rates, which resulted in an improvement in our business performance. We were able to identify accounts at risk of churn in advance.

”

What does a rescue actually involve?#

Less rebuilding than people expect.

In most of these jobs the tables themselves are fine. What is missing is the layer above them: a written ICP with disqualifiers, run conditions gating every paid step, a waterfall ordered by cost, and a deduplication pass that runs before anything reaches the CRM. Those are four changes, and none of them is technically difficult.

The hard part is the first one, because it is not a Clay task. Agreeing who the customer is, in writing, including who is explicitly out, is a commercial decision that a table cannot make for you and that enrichment will quietly paper over for as long as you keep paying for it.

When is Clay the wrong tool entirely?#

Below a few hundred accounts a month, Sales Navigator and a spreadsheet are genuinely fine, and we have told people that.

Clay earns its cost when you need many sources combined, custom scoring applied, and something orchestrated afterwards. If you need one database and a way to send from it, Apollo is cheaper and simpler and you give up the waterfalls you were not going to build anyway. If you have engineering capacity and high volume, enrichment APIs wired through n8n cost less per record, at the price of owning the retries and provider fallbacks Clay handles for you.

The failure mode is buying Clay hoping it will tell you who your customer is. It will not, it will bill you for asking, and that is the sentence underneath all four patterns above.

---

Questions we get asked about this

Is Clay the problem, or are we using it wrong?

Almost always the second, which is not a comfortable answer but is the useful one. Clay is unusually good at combining scattered sources into one scored record and unusually easy to spend money on, because it will happily enrich ten thousand rows that were never going to qualify. The tool does what you tell it. Most failed builds told it something expensive.

Why are our Clay credits disappearing so fast?

Two causes account for most of it. Enrichments running without a run condition, so every row reaches a paid provider whether or not it passed the ICP check, and waterfalls ordered by preference rather than by cost, so an expensive provider answers a question a cheap one could have answered. Fixing both usually cuts spend substantially without reducing coverage.

How do we know if our ICP is too broad for Clay?

Look at what share of enriched rows you actually contact. If you are enriching ten thousand records and sequencing eight hundred, you paid for nine thousand two hundred rows of data to reach a conclusion your filters could have reached for nothing. That ratio is the cheapest diagnostic available and most teams have never calculated it.

Should we push Clay data into the CRM automatically?

Eventually, and last. Clay makes it easy to write records into HubSpot or Salesforce before the matching logic is right, and cleaning a polluted CRM costs considerably more than the enrichment that polluted it. Get deduplication and field mapping correct on a sample first, then turn the sync on.

Do we need a partner to implement Clay?

No. Plenty of teams run it themselves and should. A partner is worth paying for when the cost of a slow or wrong build is high: when credits are already being wasted at volume, when the CRM sync has to be right the first time because sales is live on that data, or when nobody internally has the hours to own it.

How long does it take to fix a broken Clay build?

The diagnosis is usually a week and the rebuild is usually not a rebuild. In most rescue jobs the tables are recoverable and what is missing is the layer above them: a written ICP with disqualifiers, run conditions on the paid steps, and a cost-ordered waterfall. The expensive part is the agreement about who the customer is, and that is not a Clay task.