Clay's power is that it can call dozens of data providers and language models from a spreadsheet-like table, in sequence, per row. Its danger is the same: a table with fifty columns running on five thousand rows spends credits like water. Good Clay work is about ordering the steps so each row is enriched only as far as it deserves.

Start from accounts, then people

One table of companies from your ICP filters — sourced from Apollo, LinkedIn, Crunchbase or a CSV — enriched with the firmographic and signal columns you route on. Only companies that pass the filters flow to a second table of people at those companies, with role filters applied before any contact-level enrichment runs.

Order the waterfall by cost and hit rate

For email finding, run the cheapest provider with the best hit rate first, and let the waterfall try the next only on misses. Verify at the end, once, and drop unverified rows before anything expensive runs. Conditional runs — 'only if the previous column is empty' — are the difference between a fifty-credit row and a five-credit row.

AI columns that produce usable output

Give the model a specific source column (the job post text, the recent post, the website's about page) and ask for one specific output in a fixed shape — a one-sentence observation, a yes/no classification, a category from a list. Test on twenty rows, fix the prompt, then run. Never ask an AI column to 'write a personalised email'; ask it for the fact the email will use.

Push clean, push once

Only rows with a verified email, a passing fit score and a filled observation column go to the sequencer, with the fields mapped to sequence variables. Log the push so the same person is never added twice. Keep the table as the system of record for the batch, and refresh signals on a schedule rather than rebuilding from scratch.