Clay review
excellent at the denominator, silent on the model

What Clay is and who builds it

Clay is built by a New York company founded by Kareem Amin, and the product is best understood as a spreadsheet that can call the internet. You start with a table of companies or people, add columns, and each column runs something: a lookup against a data provider, an API call, a formula, or a research prompt handed to its agent, Claygent. The distinguishing mechanism is waterfall enrichment. Rather than binding you to one data vendor, a single column can try several in sequence and stop at the first that returns a usable value, which is why coverage on a Clay table is typically better than coverage from any individual provider feeding it.

The category label matters for how you should evaluate it. Clay is not a database you rent, and comparing it to one produces a confused answer. It is an orchestration layer that sits above databases, scrapers and language models, with a consumption meter attached and outbound connectors on the far side into CRMs and sending tools. You are buying the ability to ask an arbitrary question about a list of companies and get a filled column back, not the ability to download a market.

For a site about go to market arithmetic, that capability lands on one specific line of the model. Every plan here runs revenue backwards to a required send volume, and then checks that volume against two ceilings: what your team can physically send, and how many qualified companies exist to send it to. The second ceiling is the one nobody checks, and Clay is the tool that lets you check it in an afternoon rather than in a quarter of disappointing results.

Who Clay genuinely suits

Teams whose segmentation is a hypothesis rather than a habit. If you can articulate what you believe distinguishes a good account from a bad one, Clay turns that belief into a column, a count and a filter, and you find out within a day whether the segment is large enough to fund. Across the scoping work we do inside the group, clients underestimate their addressable market by 10 to 50 times with striking regularity, almost always because their target list was built from customers who had already found them. Clay is the fastest way we know to correct that error before it becomes a budget.

• Operators testing several segment definitions against each other before committing volume to one
• Teams that need a defensible account count for a channel selection decision rather than a plausible one
• Agencies and in house teams with a named person who owns data as part of their job
• Anyone whose plan currently rests on a total addressable market slide nobody has rebuilt in a year
• Teams running account research at a depth that a single provider cannot cover, particularly outside North America

Credit where it is due, and it is significant credit. Clay collapsed the distance between a targeting idea and a testable list from weeks to hours, and it did that for the whole category rather than for its own customers. The knock on effect on planning quality is real: when a market count costs an afternoon instead of a procurement cycle, teams actually check it, and checking it is what stops a plan being approved for a market that cannot supply the volume.

Where Clay is weak or the wrong choice

It is a supply side tool with no view of the demand side, and that limitation is structural rather than a gap in the roadmap. Clay does not know your win rate, your average closed won value, your meeting to opportunity conversion or your show rate. So it can tell you that 46,000 companies match your filter and it cannot tell you that your model only needed 9,000 of them, or that your deal size does not support reaching any of them through a human sales process. The tool is upstream of the arithmetic, and it will not stop you building at a scale the arithmetic never justified.

The consumption model deserves a specific warning that is not a criticism of the pricing, which we do not discuss on this site. It is a criticism of a measurement habit. Credits are spent per run, per column, per row, and the number you actually need for planning is cost per usable record: spend divided by rows that survived your own quality bar and produced a send. Waterfalls, retries and research columns all sit between those two numbers. If you never compute the second one, you will conclude that enrichment is cheap while quietly running a build cost that changes the channel selection answer.

Enrichment coverage is uneven in ways that matter for the model rather than for the demo. Coverage tends to be strongest on North American mid market companies and thinner on smaller European firms, on non English language markets and on operational job titles below the executive layer. That unevenness is not Clay inventing data badly, it is the underlying providers having different maps, and the waterfall genuinely mitigates it. But it means a market count from Clay carries a coverage bias, and if you are sizing a European or an operator level segment you should treat the returned count as a floor rather than as the market.

Finally, it rewards an operator and punishes a dabbler. The table metaphor makes the first hour easy and the tenth hour is a different product: conditional runs, deduplication logic, fallbacks and a research prompt that returns a clean value rather than a paragraph. A team without someone who owns this will build one good list, fail to rebuild it, and end up back where they started with a stale file. If nobody on your team wants that job, buy a simpler database or hire the work out.

Disclosure: we sell a competing service