What is lead scoring? (and a simple model to start with)

Lead scoring assigns each lead a number so a queue can be ordered, using two independent inputs: fit, meaning how closely the account and the person match the customers you already win, and engagement, meaning what they have actually done. It is a ranking instrument, not a verdict. A simple, defensible starting model is six to ten weighted rules, half of them fit and half engagement, with a threshold set by how many leads your team can genuinely work in a week. This is how to build one, where it breaks, and how to tell whether it is doing anything.

What a lead score is actually for

A score changes the order in which a finite number of hours gets spent. That is the entire job.

This matters because the wrong framing produces a model nobody can argue with. If a score is a judgement about whether a lead is good, every disagreement becomes a fight about the score. If it is an ordering over a queue, the only question is whether the top of the queue is better than a random sample of the middle, which is a question you can answer with data you already hold.

The consequence is a rule you can hold onto: a scoring model that does not change who gets called first today is doing nothing, however sophisticated it is. Two teams with identical models and different queue capacities should have different thresholds, and a model that produces the same working order as sorting by created date is not earning its maintenance cost.

The second consequence is about precision. A score is an ordering, so the gap between 71 and 74 carries almost no information, while the gap between 71 and 20 carries a lot. Teams that route on exact values — a rule that fires at 70 and not at 69 — build cliffs into a measurement that does not support them. Use bands.

Fit and engagement answer different questions, so keep them apart

The most common design error is collapsing both axes into one number and then reading the number as a single fact.

Fit is stable and known before contact: industry, headcount band, country, seniority of the person, whether they use a technology that implies your problem. It answers "should we be selling to this account at all?" Engagement is volatile and only exists after contact: replies, meetings, clicks that were not made by a scanner. It answers "is this the right moment?"

Sum them for ordering if you like. But keep both subtotals visible, because the four combinations demand four different actions.

• High fit, high engagement. Work now. This is the only quadrant where speed is the dominant variable.
• High fit, low engagement. Keep sequencing, change the angle. The account is right and the message or the timing is not. This quadrant is where most re-engagement value lives, and where winning back the not-now pile actually pays.
• Low fit, high engagement. The dangerous one. Somebody is clicking, a rep gets excited, and a quarter disappears into an account that was never going to buy. Cap the engagement contribution so it cannot outrun a fit penalty.
• Low fit, low engagement. Do not work it. Consider whether it should be in the database at all.

A single blended number cannot distinguish the second quadrant from the third, and those two need opposite responses. That is the argument for keeping the subtotals.

The starter model, written as rules a machine can evaluate

Adjectives do not score. A rule scores only if every term in it maps to a field you actually hold, with a comparison an engine can perform. In Autocloz the scoring engine accepts exactly seven rule types, and the list is a useful constraint because it forces the model into evaluable shape: a regular-expression match on the person's title, an exact match on the company's industry, an exact match on a size bucket, an exact match on an ISO two-letter country, membership of a tag set, activity inside a rolling window of days, and a threshold on the email confidence score. Each rule contributes a signed delta between −100 and +100, every enabled rule is evaluated independently, and the total is clamped to 0–100.

A defensible starting set looks like this. Treat the numbers as a shape to argue with, not as findings.

• Title matches your buyer pattern: +15
• Industry is one of your three best-performing verticals: +15
• Headcount band is one of your two best-performing bands: +10
• Country is a market you actually serve and support: +10
• Title matches a known non-buyer pattern, such as student or intern: −25
• Tagged from a source that has historically converted, such as a webinar or a referral: +10
• Activity inside the last 14 days: +15
• Email confidence above your verification threshold: +5

Three notes on getting these to behave.

Regular expressions on titles are sharper and more dangerous than they look. A pattern of VP|Director|Head of is case-insensitive and unanchored, so it matches "Head of Facilities" as happily as "Head of Revenue", and a bare fragment like hr matches inside unrelated words. Anchor on word boundaries and test the pattern against a hundred real titles from your own database before enabling the rule. If the pattern is malformed the engine falls back to a plain substring test rather than failing, which is safe but silently changes what you asked for.

Tag rules are only as consistent as your tag vocabulary. A tag set is an exact-membership test, so a tag applied with different capitalisation or spelling in two places splits into two facts. Fixing the vocabulary is a prerequisite, not a follow-up; the mechanics of that are in how to segment a CRM and its lists.

Write the negative rules first. Most teams add positive points until everything scores highly and the ordering flattens. Penalties do more ordering work than bonuses because they push a specific, identifiable group down, and disqualifying attributes are easier to agree on than desirable ones. If you have not written an ideal customer profile in field terms yet, the ICP generator is a faster starting point than a blank page.

Where the threshold goes, worked with real arithmetic

This is the part that is usually skipped, and skipping it is why thresholds get set at round numbers.

Work an illustrative example. You hold 4,000 leads. Historically 3% of the leads your team works become opportunities, so roughly 120 of these 4,000 would eventually qualify if you worked every one. Your two reps can genuinely work 60 new leads a week between them, so in a four-week cycle your capacity is 240 leads — 6% of the database.

Now suppose the model is genuinely predictive: within the top 240 by score, the opportunity rate is three times the base rate, so 9% rather than 3%. That slice contains about 22 opportunities. Working 240 leads at random would have produced about 7. The model is worth roughly 15 extra opportunities per cycle, and that number — not the score distribution — is what justifies the effort.

Two things fall out of the arithmetic, and both are more useful than the number itself.

The threshold is capacity divided by database, expressed as a score. Sort by score, count down to 240, and read the score at that row. That is your threshold this month. It will move as the database grows, which is correct: the threshold is a property of your capacity, not a property of the model.

Even a good model is mostly wrong at the row level. In the worked example, 9% of the top slice converts, so 91% of the leads your model called hot did not become opportunities. That is not a broken model. A threefold lift over the base rate is a strong result. But it means "the score said 82" is never an argument about an individual lead, and any process that treats a high score as a promise will produce disappointed reps. This is also why scoring belongs to queue ordering rather than to qualification; the difference between a marketing-qualified and a sales-qualified lead is a bar with named criteria, and a score is an input to that bar rather than a replacement for it.

The timestamp trap that inflates every engagement rule

Here is the failure that will hit you if nobody checks, and it is invisible from the score itself.

An activity rule asks whether the lead's last activity timestamp falls inside a window. The reasonable assumption is that the timestamp records something the lead did. In Autocloz it does not only record that. The field is written when a campaign email hits the SMTP transport, whether the send succeeded or hard-failed; when a manual email is sent from the lead record; when a quick action fires on any channel; when a reply, a bounce or an inbound message arrives; and when a lead is created by a CSV import, where it is stamped with the import time.

Read that list again and the consequence is clear. A 14-day activity rule applied to a list you emailed last Tuesday awards points to every lead in the campaign, including the ones who ignored it. A freshly imported list scores as maximally engaged on the day it lands, because the import wrote the timestamp. The engagement half of your model is measuring your own sending.

Two fixes, in order of preference.

Score on outcome events, not on the activity timestamp. Replies, positive dispositions, meetings booked and genuine human clicks are things the lead did. Where your model can key on those directly, do that instead.

Otherwise, exclude leads with an open sequence from the engagement rule. If a lead is currently enrolled and being sent to, their recency says nothing. Restrict the activity rule to leads with no active enrolment, and it starts measuring what you wanted it to measure.

There is a related detail worth knowing before you tune weights. The base score a lead starts from is not zero for everyone. A lead promoted out of the prospecting database carries the email-confidence score of the address that was found for it, while a lead created by CSV import starts at the column default of zero. Two identical people can therefore begin 60 points apart because of how they entered the database. Until you have overridden the base with your own rules, an untuned score is largely an email-deliverability confidence number wearing a fit label.

Autocloz's free plan covers 5 users and 10 mailboxes with the full CRM, contact records and all five outbound channels — start free and build the model against your own data rather than a demo dataset.

Scores go stale, and staleness is silent

Every rule that depends on a window decays. A lead scoring 70 today with a 14-day activity rule is scoring 55 in three weeks, and the stored number will not know that unless something recalculates it.

In Autocloz, evaluation is on demand. There is a dry-run endpoint that returns the score a lead would receive plus a per-rule breakdown showing which rules matched, and a recalculate endpoint that evaluates and persists, wired to the recalculate control on the lead record. What there is not is a background sweep that walks the database re-scoring everything overnight. The model docstring describes one; the code does not contain one. Plan accordingly rather than assuming.

The practical loop that works around this:

1. Recalculate a lead when you are about to act on it. The dry run and the persist are both per-lead and cheap, and the breakdown tells the rep why the number is what it is.
2. Re-score a segment before each working cycle rather than continuously. Weekly is enough for most teams, because activity windows are measured in days and fit attributes barely move.
3. Re-score after any rule change, on everything. A rule edited today does not retroactively change stored scores. Until leads are re-evaluated, your queue is ordered by the old model, and the two will disagree in ways that look like bugs.
4. Record the date of the last full re-score somewhere a human reads. A score with no date is a claim with no timestamp.

The five ways a scoring model fails, and how each is diagnosed

Everything scores highly, so the ordering is flat. *Diagnosis:* look at the distribution, not the mean. If the interquartile range is under 15 points, the model is not separating anything. *Fix:* add penalties, and remove positive rules that fire on more than 60% of the database — a rule that matches almost everything carries no information.

The score disagrees with the reps, consistently and in one direction. *Diagnosis:* take twenty leads the reps rated highly and twenty the model rated highly, and look at what differs. *Fix:* usually a missing negative rule, or a fit attribute you hold but are not scoring on. Consistent disagreement is a finding, not noise.

A rule fires on almost nothing. *Diagnosis:* the per-rule breakdown returned by the evaluation endpoint marks each rule as matched or not, so score fifty leads and count. *Fix:* either the field is empty on most rows, which is a data problem, or the pattern is too strict, which is a rule problem. Check the field coverage first; a rule on a field that is 90% null is a rule that mostly does nothing.

Scores change without anyone changing a rule. *Diagnosis:* compare a stored score against a fresh dry run. A gap means a window has moved underneath the stored value. *Fix:* re-score on a schedule you own, and stop reading stored scores as current.

Points accumulate and never decay. *Diagnosis:* find your oldest high-scoring leads and check when they last did anything real. *Fix:* every engagement rule needs a window; a rule that says "has ever replied" ranks a lead from two years ago alongside one from Tuesday.

What lead scoring in Autocloz does not do

It does not run on a schedule. Evaluation happens when a request asks for it, and there is no background job re-scoring your database overnight. If your model relies on recency, recomputation is your responsibility.

It does not support Boolean combinators. Each rule is an independent condition contributing a delta; there is no way to express "senior title and target industry, but only if no open deal". The schema is deliberately narrow, which keeps it inspectable and means complex logic has to be approximated by stacking simple rules.

It does not score companies, only leads. Account-level scoring — where the unit is the buying organisation rather than the individual — is a different model, and the account-based marketing approach treats that as its central problem rather than as a variant of this one.

It does not fill your fields. A rule on industry does nothing when industry is null, and no scoring engine can score an attribute you do not hold. Field coverage is the ceiling on model quality, and it is worth measuring before anyone tunes a weight.

And one specific caution about a neighbouring number: the deal record carries an engagement score column described as a nightly heat calculation, but nothing in the codebase writes to it. It is read by the API and typed in the frontend, and it holds its default of zero. Do not build a process on it. The lead score is the number that is actually computed, and the deal and pipeline records are where it is read alongside the rest of a lead's history.

Two closing honesty notes. Scoring is subject to Goodhart's law, in Marilyn Strathern's 1997 formulation: "When a measure becomes a target, it ceases to be a good measure." The moment reps learn which actions raise a score, some of them will produce those actions. Keep the model's inputs to things the lead does rather than things the rep does, and re-validate against closed-won outcomes rather than against the score's own distribution. And no scoring model creates pipeline. It reorders a queue you already have; if the queue is bad, better ordering of it changes very little, which is why list quality outranks model quality every time. Ranking is also only half the delivery problem — the other half is getting each lead to the right rep quickly, and a good score routed to a busy inbox is a score nobody acts on. If you are weighing this against a scoring model bundled into a larger suite, the comparison with HubSpot covers where those two approaches genuinely differ.