Lead scoring in Clay is built with formula columns that turn enriched fields into a priority, plus AI columns for the judgment a formula cannot express. Clay's documentation is straightforward about the mechanics: create a column of type Formula, use the Formula Generator to express your logic, and sync the result to a CRM field (Clay docs). The mechanics take an hour. The engineering — deciding what the score means and proving it predicts anything — takes longer and is the only part that changes revenue.
This article is about that second part. For the concept in general, independent of tooling, see lead scoring explained. For the table-building discipline around it, see Clay for GTM engineering.
In short
- Clay implements scoring with Formula columns, which run JavaScript expressions and reference other columns with
{{ColumnName}}(Clay docs). - Clay's docs describe three scoring shapes: number-based point totals, grade-based conditional rules, and binary fit criteria.
- Keep fit, intent and timing on separate axes. A single blended number destroys the information you need to choose a play.
- Use AI columns for inputs, formulas for arithmetic. Never the reverse.
- A score is a prediction; a threshold is a business decision about capacity. They are set by different people, with different evidence.
- Calibrate against closed-won or you are ranking by opinion.
The three shapes Clay gives you
Clay's lead scoring documentation defines scoring as prioritising leads "based on various attributes like employee count, job titles, and online behavior," and groups scores into customer/account fit, engagement, and an overall lead grade. Implementation runs through Formula columns in three shapes:
| Shape | What it produces | Best for |
|---|---|---|
| Number-based | A point total accumulated across attributes | Ranking within a segment you already trust |
| Grade-based | A letter or band from conditional rules | Handing reps a category instead of a number |
| Binary fit | Yes / no against hard requirements | Disqualification, before anything expensive runs |
The order matters more than the choice. Binary first. A hard "no" — wrong country, wrong industry, no phone line you're allowed to call — should stop the row before it reaches any paid enrichment. Clay's cost guidance makes the same point from the credit side: narrow the dataset before running enrichments, and set columns to run only when a field is empty or stale (Clay docs). A disqualification rule is a scoring decision that happens to also be the cheapest cost control in the table.
Keep the axes separate
The most common scoring failure is not a bad weight. It is collapsing everything into one number.
Imagine two accounts that both score 68. The first is a perfect ICP match with no reason to talk this quarter. The second is a marginal fit that just posted three relevant job openings. The number says "treat these identically." Reality says one goes to a nurture track and the other goes on a rep's call list today.
So separate the axes:
| Axis | Question | Typical Clay inputs | Changes when |
|---|---|---|---|
| Fit | Should this company ever buy from us? | Industry, headcount band, geography, locations, tech stack | Rarely — quarters |
| Intent | Are they showing behaviour that suggests interest? | Website visits, content engagement, form activity | Days |
| Timing | Is there an external reason to act now? | New hires, leadership change, funding, expansion | Weeks |
This is not a MitHub invention, and that's the point — it converges. HubSpot's lead scoring tool documents engagement scores, fit scores and combined scores, and its combined scores resolve to a letter-number grid where letters represent fit and numbers represent engagement, rather than a single total (HubSpot). Two independent products arriving at "keep the axes visible" is a reasonable signal that collapsing them is a mistake.
Two more reasons to keep them apart, specific to Clay:
- They cost different amounts to compute. Fit is cheap, mostly firmographic. Intent and timing need signals, which need monitoring. If they are one column, you cannot gate spend on the expensive half.
- They decay at different rates. A timing signal from six months ago is trivia; a fit attribute from six months ago is probably still true. One number cannot hold two decay curves. Store the date each axis was computed, and let only the timing axis fall over time.
AI for inputs, formulas for arithmetic
The temptation is to hand the whole score to a model: "read this company and rate it 1–10." Don't. You will get a plausible number you cannot debug, that shifts when the model changes, and that no rep will believe twice.
The division of labour that holds up:
- AI columns produce inputs. Clay's Use AI integration supports GPT, Claude and Gemini models and can return named fields with specified data types rather than prose (Clay docs). Use it for things a formula genuinely cannot express: is this job title a decision-maker for our offer? Does this description match our vertical? Is this a franchise or a single site?
- Formula columns do the arithmetic. Deterministic, inspectable, reproducible. Clay formulas are JavaScript expressions with column references, lodash and spreadsheet-style functions available (Clay docs).
Every AI input should be a small number of discrete values, never a free number. decision_maker: yes | no | unclear can be weighted and audited. seniority_score: 7.4 cannot — you have no idea what changed when it becomes 6.9 next month.
Write the score's receipt
Alongside the score, write a short text column that states why: "Fit A: 14 locations, target state. Timing 3: ops director hired 11 days ago. Reachable: verified direct line."
This is the single highest-return column in a scoring table. It survives the handoff to the CRM, it answers the rep's only real question — why is this on my list? — and when the score is wrong, the receipt tells you which input lied. Without it, debugging means reconstructing the formula by hand for one row at a time.
Calibration: the step that makes it real
An uncalibrated score is a preference with arithmetic on top. Clay's docs cover how to build the formula; they do not tell you whether your formula predicts anything. That is your job, and it takes an afternoon.
The five-step calibration:
- Build the historical sample. Export your last 12 months of closed-won and closed-lost opportunities. Include the losses. A won-only sample teaches you what your reps liked, not what closed.
- Score them with today's model. Run the historical accounts through the current fit logic using the attributes as they are now. Be honest that this is imperfect — some attributes have changed since the deal — and note which ones you couldn't reconstruct.
- Compute win rate by band. Group into three or four bands and calculate the win rate in each. You are looking for monotonicity: does the win rate actually rise as the score rises?
- Measure the lift. Divide the top band's win rate by the overall win rate. A lift near 1.0 means your score is doing nothing. Before you touch weights, check whether any single input carries all of the lift — often one attribute does, and the rest are decoration.
- Set the threshold from capacity, not from a round number. If your team can work 120 accounts a week, the cut line is wherever the 120th-ranked account sits. "Above 80 is an MQL" is a number somebody liked, not a decision.
A hypothetical to show the shape — not MitHub data. Suppose the A band wins 14% of the time, B wins 9% and C wins 8%. A separates well; B and C do not separate from each other at all. The right move is not new weights across the board — it is to merge B and C and go find the attribute that actually distinguishes them.
Then re-run it quarterly. Markets move, the product changes, and a score that was calibrated in March silently stops predicting by September. Put the review on a calendar with a named owner, the way Operate describes: observe, hypothesise, measure, adjust.
Where the score has to go
A score that lives only in a Clay table changes nothing. Clay's lead scoring docs list CRM fields for syncing scores as a prerequisite, and that is the right instinct: the destination is part of the design, not an afterthought.
Three rules for the handoff:
- Write the score, the band, the receipt and the timestamp — four fields, not one. The timestamp is what lets you tell a stale score from a current one.
- Write to fields Clay owns. Never overwrite a field a human edits. Field ownership is the whole subject of connecting Clay to HubSpot, Salesforce and Zoho.
- Connect the score to a routing rule. A score with no routing consequence is decoration; see lead routing for what to do with the bands once they exist.
The failure modes to watch for
- Score inflation. Every quarter someone adds five points for a new attribute and nobody removes any. Rebase the model annually instead of accumulating.
- Proxy drift. Headcount was a proxy for number of branches until you moved upmarket and it stopped being one. Re-examine proxies, not just weights.
- Scoring on data you don't have. A weight on a field that is empty for 70% of rows is a coverage problem wearing a scoring costume. Fix the waterfall first.
- Timing signals with no expiry. If a funding round from last year still adds points, your "hot" list is an archive. See Clay signals and intent data.
- No feedback loop. Nobody compares scored leads against outcomes, so nobody ever learns. This is the one that quietly kills the whole system.
The last one is also the difference between a Doer and a Designer on MitHub's capability ladder. Anyone can write the formula. The person who closes the loop between the score and the closed deal — and can show the calibration table that proves it — is doing the work companies actually pay for.