How to Build a Lead Scoring Model in Clay: A Step-by-Step Formula Framework

Most Clay lead scoring models fail before a single row gets scored. Not because the formula is wrong. Because the team building it picked fifteen attributes on day one, weighted them by gut feel, and never opened the model again after it shipped.

We've built lead scoring models in Clay for enough clients to know the pattern by now. But the formula syntax isn't the hard part. Clay's formula column will happily sum, branch, and nest whatever logic you give it. The hard part is discipline: a small enough attribute set that you can actually tell what's working, plus the habit of coming back to check.

Clay is worth building this in specifically. Eighty-four percent of GTM Engineers report using it, and among agencies that climbs to 96%, per OneGTM's 2026 State of GTM Engineering survey (self-selected, 228 respondents across 30+ countries, meaningful but not statistically representative by the authors' own description). So it isn't a niche workaround anymore. It's most people's default.

So here's a step-by-step framework for building a lead scoring model in Clay that still works six months from now, real formula syntax included. It separates fit from intent, shows the formula column code, and covers the part almost nobody writes about: what to do once the model stops matching reality.

Lead scoring vs. account scoring: pick the right unit before you build anything

Clay users conflate these constantly, and it breaks models before they start.

Lead scoring evaluates a person. Did this specific contact fill out a form, open three emails in a week, view your pricing page twice? It's mostly behavioral, it decays fast, and it belongs at the contact-record level.

Account scoring evaluates a company. Headcount, funding stage, tech stack, industry. It's mostly firmographic, it barely moves month to month, and it belongs at the company-record level.

But here's why that matters in Clay specifically: your table structure has to match the unit you're scoring. Score a person on a company-level table and you double-count every contact from the same account. Score a company on a person-level table and one enthusiastic intern's browsing spikes the whole account's score.

So most GTM teams need both, joined. A lead score tells you who to call first inside an account. An account score tells you whether the account is worth calling at all. Blending the two into a single number hides which one you're actually looking at: a good account, or just an active one. We've made that argument on its own, in more depth, in a separate piece on scoring buying intent without a black-box model. This piece is the implementation.

Step 1: choose 5-7 attributes, not 15

Start smaller than feels responsible.

Every scoring model we've built that actually got used started with five to seven attributes. Every one that got abandoned within a quarter started with twelve or more. But that's not a coincidence. It's a mechanism: with fifteen attributes feeding one score, when a segment converts well and still scores low, there's no way to isolate which of the fifteen is wrong. You're debugging a black box you built yourself.

Pick a small, deliberately limited set, split across three categories.

Firmographic, the fit signals that rarely change:

• Company size band, usually headcount
• Industry or vertical match to your ICP
• Funding stage or revenue band, when it correlates with deal size

Behavioral, the intent signals that decay fast:

• Pricing or demo page visits in the last week
• Email engagement within a lookback window you set
• A specific high-intent action, like a trial request or a technical asset download

Disqualifying, either category:

• A personal email domain (gmail, yahoo) on a form fill, when you sell B2B
• A named competitor's domain
• A geography or company size band you don't serve

Seven attributes total, maybe eight if a negative signal is doing real work. And you will want to add more almost immediately. Don't, not yet. Ship this, watch it against real deals for a month, and add an eighth attribute only once you can point to a specific decision the current seven get wrong. Attribute count is the one lever to stay most conservative with, since every attribute you add multiplies the number of interactions you'd have to check the next time the score misses.

Step 2: enrich the underlying fields before you score anything

A formula is only as good as the field sitting behind it. If {{Employee Count}} is blank on 40% of your rows, no formula logic fixes that. Enrichment has to run and land cleanly before the scoring formula ever touches the row.

Which enrichments feed which score

Headcount and funding stage come from a firmographic enrichment step, usually a waterfall: try one data provider, fall through to a second when the first comes back empty, then a third. Clay is built around exactly this pattern. If you're still deciding which platform to build the waterfall in, we've compared the real tradeoffs between Apollo, ZoomInfo, and Clay elsewhere.

Tech stack detection usually comes from a site scrape or a dedicated lookup enrichment, and it feeds both fit (do they run tools that indicate budget and sophistication) and occasionally intent, since a recent tool change is itself a signal.

Job postings are firmographic-adjacent: open sales or RevOps roles often precede a buying motion, so they get pulled into a hiring-signal enrichment step of their own.

But personal-vs-work email matters at the individual form-fill level. A dedicated email-type enrichment step flags gmail.com, yahoo.com, and similar domains before the row ever reaches your formula column, since that's the fastest disqualifying signal available.

So get the enrichment waterfall right first. A companion piece on the full data stack this feeds into is still coming; for now, the formula in Step 3 assumes these fields are already populated.

Step 3: write the formula column, with real syntax

This is where every competitor piece on this topic stops at a paragraph of illustrative point values. Here's the actual formula.

Clay's formula column runs standard JavaScript under the hood, plus a familiar spreadsheet function set (IF, SUM, VLOOKUP, and others) through FormulaJS. And you reference other columns by typing / and picking one, which inserts it as {{Column Name}}.

Number-based scoring: sum weighted points

The simplest pattern sums a set of weighted points.

Number(
  (Number({{Employee Count}}) > 200 ? 20 : 0) +
  ({{Funding Stage}} == "Series B" || {{Funding Stage}} == "Series C" ? 15 : 0) +
  ({{Tech Stack}}.includes("Salesforce") ? 10 : 0) +
  (Number({{Job Postings (GTM)}}) > 0 ? 10 : 0) -
  ({{Email Type}} == "Personal" ? 15 : 0)
)

But every point value above is illustrative, a stand-in for whatever your own weights turn out to be. Wrapping numeric fields in Number() before comparing them matters more than the weights do: an enrichment field that comes back blank or as text will silently break a > comparison otherwise, and that's the single most common way these formulas fail in production.

Grade-based scoring: compound conditions, ordered largest to smallest

Some teams want a letter grade instead of a point total, useful when routing matters more than ranking. Clay's conditional syntax uses IF / ELSE IF / ELSE, and compound conditions use && for AND, || for OR:

IF ({{Employee Count}} > 1000 && {{Funding Stage}} == "Series C") return "A"
ELSE IF ({{Employee Count}} > 200 && {{Funding Stage}} != "Seed") return "B"
ELSE IF ({{Employee Count}} > 50) return "C"
ELSE return "D"

Order matters here, and it's easy to get backwards. Write > comparisons largest to smallest, top to bottom. Put the 1,000-employee condition first, not last. Check > 50 before > 1000 and every enterprise account matches the first branch it hits, never reaching the tier that actually describes it.

Casting the result so it's sortable and filterable

A formula column defaults to whatever type its output looks like, and text output doesn't sort numerically. Click the column header, hover the data type, and set it to Number. Clay's own documentation names this exact use case: the Number type is built for cases like lead scores and revenue measurements. But skip this step and a score of "100" sorts before "20," because the column is comparing characters, not values.

Step 4: set thresholds that route, not just rank

A sorted list is not a system.

If your score just orders leads top to bottom and nobody looks past row 20, the model isn't doing its job. So thresholds turn a ranking into a routing decision: this band goes to a rep today, this one goes to nurture, this one gets suppressed.

There's no universal number here, and any piece that hands you one, "70+ triggers outreach," is citing its own product's default, not a benchmark that applies to your pipeline. The right threshold is the score at which your sales team can actually work the volume you're sending them. Too low, and reps drown in leads that never convert and stop trusting the score. Or too high, and you're sitting on leads that would have closed.

Start by picking a band size your reps can actually clear in a day, then back into the score cutoffs that produce roughly that volume from your current pipeline. But that's the reverse of how most teams work. They pick a round number, 50 or 70, because it feels definitive, then discover it sends three leads a week or three hundred. Size the routing action to your team's real capacity first. So the score cutoff is a consequence of that decision, not the other way around.

Step 5: calibrate against real outcomes, on a cadence

This is the step every competitor piece on this topic skips, and it's the one that decides whether your model is worth trusting six months out.

Pull your closed-won deals against the score each lead or account had when it entered the pipeline. Not the score today, the score at the moment it became an opportunity. Then look for the mismatch: a segment that closes well but scored in your middle or bottom band, or a segment that scores high consistently but almost never converts.

When you find a segment that converts well and scores low, one of two things is true. Either an attribute you're weighting too heavily doesn't actually predict this segment, or you're missing an attribute entirely, something this group has in common that your current five to seven don't capture. Both are worth adjusting the formula for. And neither is worth guessing at.

Do this on a cadence, not once. A monthly pull suits a high-velocity motion; a quarterly pull suits a longer sales cycle. Either way, put the first check on the calendar the same week you ship the model, because "we'll revisit this later" is how a scoring model quietly turns into background noise nobody trusts.

Two adjustments come out of a calibration pass almost every time: reweighting an existing attribute that turned out stronger or weaker than the initial guess, and adding or dropping an attribute entirely once the data shows something the original seven missed. So what you're not doing is rebuilding the model from scratch every quarter. The formula from Step 3 keeps its shape. You're adjusting weights and thresholds against evidence, not re-architecting on a hunch. That discipline, recalibrating against outcomes instead of starting over, is the actual difference between a model still useful in month six and one quietly ignored since month two.

Common failure modes to check before you trust the score

Three ways a Clay scoring model quietly stops being trustworthy, and none of them show up as an error.

Stale data driving stale scores is the second. An intent signal from six weeks ago isn't intent, it's history. If behavioral fields don't refresh on a schedule, the intent half of your score is really measuring last quarter, and nobody thinks to check the enrichment run date before trusting the number.

But the third is quieter: a score nobody routes off of. If sales stopped checking the score column two months ago and no one noticed, the model became a vanity metric the day that happened, not the day someone finally audits it. A score that doesn't drive a routing decision isn't a scoring model. It's a column.

So check all three before you call a scoring model finished. A formula that compiles cleanly and a formula that's actually trustworthy are different claims, and the gap between them is exactly these three failure modes.

When to build this yourself vs. bring in a GTM engineering partner

Most operators can build a version one of this themselves. Nothing in Step 1 through Step 4 requires more than a Clay seat and an afternoon. So if that's where you are, build it.

Where teams actually get stuck isn't the formula. It's Step 5. Calibration means someone checking the model against closed-won data on a cadence, month after month, and that's a discipline problem more than a technical one. It competes with every other fire in a growing GTM org, and it's usually the first thing to slip.

That's roughly where what GTM engineering actually looks like in practice diverges from a one-off Clay build: the ongoing operating discipline, not the initial formula. Some teams solve it by putting recalibration on one person's calendar and holding them to it. Others bring in a partner specifically to own that cadence, since an outside team with no ego in the original weights tends to catch a stale attribute faster than the person who chose it. And neither is the right answer independent of how much time your team can actually give the ongoing maintenance. For the broader build-vs-buy question on GTM systems generally, we've written about that tradeoff separately.

Recap

Five to seven attributes, not fifteen. Split fit from intent before writing a single formula. Enrich the fields before scoring them. Write the formula with real syntax, cast the output as a number, order comparisons largest to smallest. Set thresholds your sales team can actually work, then calibrate against closed-won on a cadence you actually keep.

And once the model is routing leads correctly, the next system worth getting right is what happens after a lead scores high: the email infrastructure it needs to land anywhere. A scoring model that routes leads into a broken send pipeline is a wasted formula.