Where Clay builds usually go wrong
The enrichment waterfall gets built before anyone decides which accounts matter, so the credits go to rows that were never going to be worked.
The second failure is the one nobody notices: the table is beautiful and nothing downstream consumes it. No sequence, no trigger, no owner.
How we use it
Clay sits inside our own daily campaigns rather than a demo account. It is on our public GTM Tools page for that reason, next to the rest of the stack we actually run.
A build starts from the account list you want to close, then the waterfall is designed around what those specific accounts need, and every table ends in a campaign that somebody owns.
How to evaluate a Clay workflow before expanding it
Start with a representative account sample and define what a usable record must contain. Review matching accuracy, missing values, source dates, exclusions and how failed steps are handled. Keep an unknown value visible instead of letting a generated guess pass as verified research.
Ask the operator to trace one accepted row into its downstream campaign or CRM destination, then trace a rejected row to the reason it stopped. Compare credits and review time per accepted record, not only per enriched row. Confirm access, ownership and the instructions needed to maintain the workflow in your workspace.
Frequently asked
Do you build inside our Clay workspace or yours?
Yours. What we build has to keep working when we stop, and that is not possible from our side of the wall.
Can you cut our Clay credit spend?
Usually yes, and the saving almost never comes from a cheaper provider. It comes from stopping enrichment on rows nobody was going to work.
Do we need Clay at all?
Not always. If your list is small and your ACV is high, a waterfall is overhead. We say that before selling a build.
Worked Clay Example: From Six Rows to One Reviewable Account
This simulated fixture shows the decisions behind an enrichment workflow. It is not a client result or a live Clay benchmark. The six fictional rows use reserved .example domains and contain no contact addresses.
Apply the sample ICP, normalization, duplicate and suppression rules before enrichment. S01 passes the sample fit review; S02 is a duplicate, S03 is outside the employee range and S04 is suppressed. S05 remains on hold because evidence is missing; S06 remains on hold because sources disagree. An unknown must not become an invented fact.
The reconciliation is six inputs, one accepted for review, three rejected and two held. None are ready to send. The example spends seven fictional lookup units: one on S01 and three each on S05 and S06. Seven divided by one accepted record is seven units per accepted record; these units are not actual Clay credits or prices.
Import the input CSV into a scratch table with sending integrations disconnected. Use the expected-output CSV to review decisions and reasons. Acceptance for review is separate from a verified address, contact authorization and campaign approval.
Simulated, not a result. All company domains end in .example and must not be contacted. Units are arithmetic teaching units, not Clay credits or prices.
