Clay for GTM Engineers: A Practical Guide
Clay is a spreadsheet-shaped orchestration layer for go-to-market data: each row is an account or contact, each column an enrichment, lookup, or AI step. Used well it is the fastest way to build a signal-to-action loop. Used badly it becomes an unversioned, unmonitored production system nobody can debug.
- One table, one job. Tables that do prospecting, enrichment, scoring, and sending at once become unmaintainable fast.
- Order columns cheapest-first. Filtering before expensive enrichment is where nearly all credit savings come from.
- AI columns need a constrained output and a validation column behind them, always.
- Clay is not a system of record. Write results out to the warehouse or CRM.
- Move to a real pipeline when a table becomes load-bearing, needs version control, or must run reliably unattended.
What Clay actually is
Clay is an orchestration layer that looks like a spreadsheet. Each row is an entity — usually an account or a contact — and each column is a step: an enrichment lookup, an API call, a formula, an AI prompt, or a write-out to another system. Rows flow through columns left to right.
That interface is the reason it won. It makes data pipelines legible to commercially-minded operators who would never have written the equivalent in code, which collapsed the time from idea to working play from weeks to hours.
It also creates the characteristic failure mode: because it looks like a spreadsheet, people treat it like one — and then it quietly becomes production infrastructure with no version control, no monitoring, and no owner.
Table design
The single most useful discipline is one table, one job. Tables that prospect, enrich, score, personalise, and send all at once become impossible to debug within a couple of months, because a failure anywhere shows up as bad output at the end.
| Table | Job | Output |
|---|---|---|
| Source | Bring in accounts from one signal or list source | Deduplicated domains with the signal and timestamp |
| Enrich | Build the account and contact record via a waterfall | Complete records with provenance and cost |
| Score | Apply fit and intent logic, then filter | Only records above the threshold |
| Activate | Generate personalisation and push to the sequencer and CRM | Records in the engagement system |
Four tables chained is more work to set up and dramatically less work to maintain. When something breaks — and it will — you can see immediately which stage produced the bad output.
Credit economics
Clay bills on credits, and nearly all overspend comes from one mistake: running expensive columns before filtering. Ordering columns cheapest-first is the highest-leverage optimisation available.
- 01Free and cheap filters first
Domain validation, formula-based exclusions, suppression against existing customers and open opportunities. Every row removed here is a row you never pay to enrich.
- 02Cheap firmographic enrichment
Headcount, industry, and location, to apply the fit criteria. Still inexpensive per row and it removes the bulk of a typical list.
- 03The fit filter
Apply it here, before anything expensive. On a typical raw list this removes 60–80% of rows, which is where the actual saving lives.
- 04Contact-level waterfall
Now find people and their contact details across a provider waterfall. Expensive per row, and you are only running it on records you have already decided are worth having.
- 05AI research last
The most expensive column type. Run it only on rows that will definitely be actioned this cycle.
Waterfalls in Clay
Clay's waterfall feature queries providers in sequence and stops at the first acceptable result. Three things to get right:
- Order by cost per successful match on your own data, not by provider reputation. Run a 500-row test and measure hit rate per provider on your specific market before fixing the order.
- Set a real confidence threshold. A returned value is not a good value. Without a threshold, a weak match from provider one blocks a strong match from provider three.
- Verify emails as a separate step. Do not treat a waterfall result as deliverable. The full mechanics are in waterfall enrichment.
Using AI columns without creating a mess
AI columns are where Clay does something genuinely impossible at scale rather than merely faster: reading a company's site or job posts and returning a structured answer about how they operate. Three rules keep it safe.
| Rule | Why | How |
|---|---|---|
| Constrain the output | Free text produces forty variants of the same answer within a month | Force selection from a fixed list, or a strict format |
| Add a validation column | Models fail by returning confident nonsense, not by erroring | A formula or second pass that checks format and plausibility |
| Ask one question per column | Multi-part prompts fail partially and silently | Separate columns for separate facts |
The second row is the one people skip. A model that returns 'yes' for every row because your prompt was ambiguous looks exactly like a model that is working, until someone reads the output. Turning those structured facts into a message a buyer will actually read is covered in personalised outreach at scale.
Clay is not a system of record
Results should be written out — to the CRM for records above your entry threshold, and to the warehouse for everything, including the rows you rejected and why.
Rejected rows are more valuable than most teams realise. They are the negative training data for your fit model, and without them you can only ever learn from accounts you contacted. Where this sits in the wider architecture is covered in the GTM tech stack.
When to move off a table
Clay is excellent for building and proving a play. It is not the right home for a play that has become infrastructure. Four signals it is time to move the logic into a real pipeline:
- It is load-bearing. Revenue depends on it running, and nobody would find out promptly if it stopped.
- You need version control. Two people are editing it and you cannot tell what changed or revert.
- It must run reliably unattended, on a schedule, with retries and alerting.
- The credit cost exceeds engineering time. At high volume, running the same logic against provider APIs directly is often cheaper.
The healthy pattern is Clay as the prototyping and proving layer, with proven plays graduating into monitored pipelines. Teams that never graduate anything end up with a dozen critical tables nobody dares touch; teams that build everything in code from the start move far too slowly to find out which plays are worth having.
If you are evaluating whether Clay is the right orchestration layer at all, Clay alternatives compares the realistic options.
Want this diagnosed on your own numbers?
The RADAR™ Scan scores your revenue engine in 2 minutes — 12 questions, a 0–100 score, and your gate verdict. No email required.
Run your RADAR™ Scan→Questions this raises.
What is a Clay table?
How do you reduce Clay credit costs?
How should you structure Clay tables?
How do you use AI columns in Clay safely?
When should you stop using Clay for a play?
Related guides.
Four categories of alternative, what each is genuinely better at, and the honest answer on when to build it yourself.
GTM EngineeringQuery providers in sequence, stop at the first good answer, and pay a fraction of what a single-vendor contract costs — done properly.
GTM EngineeringSeven layers, how data should actually flow between them, realistic costs by stage, and the three failure modes worth designing out.
GTM EngineeringFirst we build your pipeline. Then we build the machine that scales it.
Every engagement starts with the RADAR™ Reveal — a 2-week audit with a scored report, gate verdict, and roadmap. Yours to keep, whatever you do next.