Clay Automation Tutorial: Build a Table That Runs Itself

A Clay table is a pipeline that looks like a spreadsheet

Search for a Clay tutorial and you get a tour of the interface: how to add an enrichment column, how to run a waterfall, how to write an AI formula. You finish with a clean, enriched list and the sense that you have learned the tool.

You have learned the calculator. You have not learned the build.

The trouble shows up a few weeks later. B2B contact data degrades at roughly 2.1% a month, which annualizes to about 22.5% a year by HubSpot's database decay model. The list you enriched in January is meaningfully wrong by spring. People change jobs, companies get acquired, domains change. A one-time enrichment is a photograph of a thing that keeps moving.

The skill worth learning is not running enrichments. It is building a Clay table as an automation: a pipeline that wakes up to an input, qualifies before it spends a credit, enriches only the rows that earn it, and routes the result somewhere a person or a sequence acts on it. Clay's own training organizes the work into four named stages it calls FETE: you find accounts, enrich them, shape the data, then export it. The part the tutorials skip is the wiring between those stages and the logic that lets the whole thing run without you sitting over it. That wiring is what this walkthrough is about.

Start with the input, not the enrichment

The first decision in any Clay build has nothing to do with data providers. It is the input contract: what populates this table, and how often.

Most tutorials start you with a CSV import or a one-time pull from Clay's built-in sources. That is fine for a test. It is the wrong default for anything you want to keep. The moment you treat a table as a place to store a static list, you have signed up to re-import it by hand every time the data rots, which by the decay math above is constantly.

Decide instead what kind of table this is:

• A recurring source table that re-pulls from a saved search on a schedule, so new accounts matching your criteria flow in on their own.
• A signal-fed table that an inbound trigger writes to, such as a webhook from a form fill, a job-change alert, or a website visit your tracking flags.
• A one-shot project table that you genuinely only need once, for a campaign with a fixed list.

Only the third one is allowed to be a manual import, and you should be honest about how rare that actually is. Naming the input contract first changes everything downstream, because a table that refills itself needs conditional logic that a static list does not. You are building a process, and the input is the thing that keeps the process alive.

Qualify before you spend a credit

Here is the step that separates a Clay build that compounds from one that quietly burns money: the qualify gate.

Every enrichment column costs credits. A waterfall that hits three or four providers to find a verified email can run real money across thousands of rows. The instinct is to enrich everything and filter afterward. That is backwards. You filter first, on the data you already have, and you enrich only what passes.

Clay supports this directly through conditional runs, where a column only executes on rows that meet a condition you set. Native filters and AI formulas that work on existing fields cost nothing to run, so a fit check on headcount, industry, geography, or a title pattern is free. Put that check before the paid waterfall, and the providers only ever see rows worth paying for.

The economics are stark. On a 5,000-row table where only 800 accounts actually fit your profile, gating before the waterfall means you pay to enrich 800 records instead of 5,000. For the same usable output, that is the difference between a modest monthly Clay bill and one that makes you question the whole exercise. I dug into the credit math behind this in the Clay enrichment breakdown, and the headline holds: your cost is dominated by the filter step that runs before the waterfall rather than by the waterfall itself.

Qualifying first also protects the rest of the system. Off-fit rows that slip through do not just waste credits. They reach your sequencer, drag down your reply rates, and raise the spam complaints that decide whether your email lands at all. The gate is the cheapest place to stop a bad lead, so it belongs at the front.

Enrich, format, then route to where the work happens

Once a row passes the gate, the middle of the pipeline does its job. The waterfall finds the email or phone by querying providers in sequence until one returns a match, so you pay per match rather than per attempt. The mechanics of designing that sequence by match rate and cost are their own topic, and I covered the ordering logic in the waterfall enrichment guide.

The formatting stage is where you turn raw fields into something usable. Standardize job titles and fix inconsistent company names, then use an AI formula to pull one relevant detail for personalization. Keep this honest. One specific, verifiable line beats a paragraph of generated flattery, and a formatting step that invents detail is worse than skipping it.

Then comes the stage that every interface tour treats as an afterthought and that actually justifies the whole build: export. The enriched, qualified record has to land somewhere a person or a sequence acts on it. A CRM record with an owner and a next step. A sequencer enrollment. A Slack alert to a rep. If the data stops inside Clay, you have run a research project rather than built an automation.

This is also where governance earns its keep. Gartner estimates that poor data quality costs the average organization $12.9 million a year, and an automation that writes unchecked records into your CRM is a machine for manufacturing that problem at speed. Validate before write-back. Standardize your field formats so the CRM does not choke. Decide which records auto-enroll and which wait in a review queue. The export step is the boundary between your clean pipeline and the system everyone else relies on, so treat it like one. How those routing rules connect to follow-up is the subject of the CRM automation guide.

Make it run without you

A pipeline you have to launch by hand is a manual process with extra steps. The automation only counts once it runs on its own, and getting there is a matter of three settings most tutorials never reach.

First, the trigger. A recurring table runs on a schedule you set. A signal-fed table runs when its webhook fires. Either way, you decide the cadence and Clay handles the rest, pulling new rows, qualifying them, enriching the survivors, and exporting the result on the clock instead of on your attention.

Second, the human checkpoint. Full autonomy is a trap at the wrong step. The right move is to find the one decision where being wrong is expensive, and keep a person there while automating everything around it. Auto-enroll a clearly qualified, well-enriched lead. Hold an ambiguous one for a thirty-second human glance. You are not choosing between manual and automated. You are placing the human at the one decision that carries the most risk and letting the machine own the rest.

Third, monitoring. Because the data underneath keeps decaying, the pipeline needs a health check: match rates by provider, the share of rows that clear the gate, validation failures on write-back. When a provider's match rate drops or a source dries up, you want to know from a dashboard, not from a rep asking why their list went quiet.

The payoff is the time itself. Salesforce's State of Sales report finds reps now spend about 60% of their time on non-selling work, much of it the manual research and data entry a build like this absorbs. The same research has teams expecting AI to cut prospect research time by 34% once it is properly wired in. A Clay table that runs itself is one concrete way to claim that hour back, because the prep happens before anyone logs in.

Where this fits

A self-running Clay table is one component, not a growth strategy. It feeds the pipeline. What it feeds matters just as much: the outreach that works the enriched accounts, the follow-up that catches the replies, and a single number that tells you whether any of it is producing booked conversations. I spent seven years running marketing for an Inc. 5000 company from startup through exit, and the lesson that stuck is that isolated automations rarely move the number. A data pipeline wired to outreach and follow-up does.

If you want the build patterns we use to wire enrichment into the rest of that system, the AI automation playbook lays them out, and our AI automation service covers how we run them for clients. Start with the input contract, gate before you spend, route to where the work happens, and put the human where being wrong is expensive. Do that and you have built an automation instead of a very expensive spreadsheet.