How Do You Cap Clay Credit Spend Per Lead?

How do you stop Clay from spending more on a lead than the lead is worth?

Set a credit budget per lead before you build the table, then design the table so it cannot exceed it. Qualify with cheap or free data first, look up what you already own, run paid enrichments only on rows that pass, and test on ten rows before you run a full column.

Most Clay bills I see are not caused by one expensive provider. They come from a table that enriches every row the same way, whether the row is a perfect fit or a student with a Gmail address. The spend is spread thin across leads nobody will ever call.

A per-lead cap fixes that. It turns credit spend from a monthly surprise into a design constraint, the same way a paid media team works from a target cost per lead. In this piece I will show how I set that number and how I build the table around it.

What does a per-lead credit cap actually mean?

A per-lead cap is the most credits you are willing to spend to turn one raw row into a lead your team will act on. It is a design rule, not a setting. You enforce it through the order of columns, run conditions, and which rows are allowed to reach the paid steps.

Clay does not hand you a single switch that says "never spend more than this on one row." What it gives you is a set of controls that, used together, produce the same result. Run conditions decide which rows a column touches. Auto-run decides whether new rows trigger spend on their own. Column order decides how much you know about a row before the paid step fires.

So the cap lives in your head and your documentation first. I write it at the top of the table description in plain words: "Target spend per qualified lead is X credits. Unqualified rows should spend close to nothing." Anyone who edits the table later can see the rule they are expected to keep.

How do you decide what one lead is worth in credits?

Work backward from revenue. Take your average deal value, multiply by the share of qualified leads that become deals, and you get a rough value per qualified lead. Then decide what small slice of that you will spend on data. The answer is usually far more generous than teams fear, or far stricter.

The math does not need to be precise. It needs to be written down. A team selling a high-value annual contract can justify a lot of enrichment on a strong-fit account. A team selling a low-priced self-serve plan cannot, and should lean on free signals and cheap filters.

The bigger insight is that the cap is per qualified lead, not per row. If one in five rows qualifies, the four that fail should cost almost nothing. When I audit a table, the first thing I look for is how much is spent on rows that were never going to qualify. That number is usually the whole problem.

Which columns should run before you spend any credits?

Run free and owned data first. Clay recommends using lookup columns to pull data already in your CRM or another table, so you avoid enriching the same record twice. After that, run cheap qualifying checks like domain type, country, and company size before any paid contact or email enrichment.

Clay's own guide to saving credits lists this directly: qualify leads before enriching, because "you can save credits by enriching only the leads that meet specific criteria." It also recommends lookup columns to avoid duplicate enrichments. That one habit removes a surprising amount of waste, especially in tables that get refreshed from the same source.

Duplicates are the quiet killer here. If the same company arrives from three sources, you can pay to enrich it three times. I covered the cleanup side of that in my piece on how to dedupe companies across Clay, Apollo, and HubSpot. Dedupe before the paid steps, not after.

My usual order is simple. Normalize the domain. Look it up in the CRM. Drop personal email domains. Check firmographic fit with the cheapest source you trust. Only then let a row reach the step that finds a person, an email, or a phone number.

How do run conditions keep paid enrichments off bad rows?

Every paid column gets a run condition. In Clay you add it in the column's Run settings, in the "Only run if" box, using a formula. The enrichment then runs only when the condition is true. Point the condition at your qualification column so failed rows never reach the paid step.

Clay's docs describe conditional formulas as a way to conserve credits "by ensuring that enrichments only run when specific conditions are met." They also note a "Use AI" option that writes the formula from a plain language description, which helps people who do not want to write formulas by hand.

The pattern I use is one boolean column called something like "Qualified for paid enrichment." It combines the checks above into a single true or false. Every paid column points at that one field. When the ICP changes, I edit one formula instead of hunting through ten run conditions and missing one.

Waterfalls work the same way. If you try several email providers in order, give each later step a run condition that checks whether the earlier steps came back empty. That way a row stops spending the moment it gets an answer. If you want to think through provider order itself, my piece on enrichment waterfall order, cost versus coverage goes deeper.

Why should auto-run be off while you build?

Because auto-run spends credits on every new row without asking. Clay's guide says auto-run lets it enrich new rows added to a table automatically, and advises turning it off while you build so rows added by mistake do not consume credits. Turn it back on only after the table is tested and the run conditions are in place.

This is the most common way I see budgets blown in a single afternoon. Someone imports a big list into a table that already has auto-run on and a dozen paid columns. Every column fires on every row before anyone notices the import included a test list or the wrong segment.

Clay's docs say you can turn auto-run off per column in Run settings, or at the table level, where the toolbar button then reads "Manual." I build in manual mode, test, then switch on auto-run column by column, starting with the free ones.

How do you test a table before you trust it with credits?

Run every new column on a small sample first. Clay's own guidance is to test about 10 rows before running the entire column, so you can catch errors before committing credits. Check the outputs by hand, confirm the run conditions skipped the rows they should, then run the rest.

I treat those ten rows as a deliberate mix, not the top of the list. Include a strong-fit account, a clear non-fit, a personal email, a duplicate, and a row with a messy domain. If the table handles those five kinds correctly, it will usually handle the full list.

After the test, look at what each column spent. Clay's credit usage docs say the table dashboard has a column view that shows your spend broken down by each column in your table. That is where the per-lead cap becomes a number you can check instead of a hope.

How do you watch spend after the table is live?

Review spend by column on a schedule and compare it to qualified leads produced. Clay shows usage at the workspace, table, and column level. It also warns before expensive runs, but only when a run costs at least 5% of your monthly budget and more than 500 credits, so do not treat the warning as your guardrail.

That warning threshold matters. Many small overspends never trigger it. A table that leaks a little on every refresh can drain a budget over a month without a single alert. The fix is a calendar reminder and a two-minute review, not a bigger alarm.

If people on your team use Clay through an MCP connection from an AI assistant, check the separate settings for that. Clay's credit usage docs point MCP users to Settings, then MCP users, for per-user credit limits and live usage tracking. Agent access is exactly where an unwatched loop can spend fast.

For tables that refresh on a schedule, the same rules apply with one more layer. Only refresh rows that are still in play. I wrote about that in how to schedule an enrichment refresh without wasting credits.

Should you bring your own API keys to Clay?

Sometimes. Clay's guide says that on a paid plan you can connect your own API keys for providers where you already have credits, and run those services on your own account. That makes sense when you already pay a provider. It does not make sense if it splits your spend tracking across too many places.

The trade-off is visibility. When every enrichment runs on Clay credits, one usage screen tells you the whole story. When half the spend runs on your own keys, you need to check each provider's billing too. For a small team, I would rather have one clear number than a slightly lower total I cannot see.

My rule is to bring a key only when the provider is one you would keep paying for even without Clay. Otherwise, keep it simple and let your per-lead cap do the work.

What should you do next?

Open your busiest Clay table and check spend by column. Find the paid columns that run on every row, add a single qualification field, and point each paid column's run condition at it. Turn off auto-run while you test on ten mixed rows. Then write your per-lead cap at the top of the table.

The goal is not to spend less on Clay. The goal is to spend on the right rows. A table that spends heavily on a strong-fit account and almost nothing on a bad fit is doing its job, even if the total bill goes up as your pipeline grows.

If you want a second pair of eyes on your enrichment tables, or help designing the qualification logic behind them, let's chat. This is the kind of GTM engineering work I enjoy most.