How Do You Score Leads Against Your Ideal Customer?

You score fit, not enthusiasm.

Most lead scoring measures how excited someone looks — pages viewed, emails opened, pricing page visited twice. That is a measurement of interest, and interest is cheap. The competitor doing research, the student writing a dissertation and the buyer with budget all open your emails.

Scoring against an ideal customer asks a different question: does this person resemble the people who already buy from you and stay? That is answerable from evidence outside your own analytics, and it is the one that tells a salesperson who to call first.

Why do most lead scores tell you nothing?

Because they score behaviour on your own property and call it qualification. Every point in a typical model — opened the email, clicked the link, viewed the pricing page — measures engagement with your marketing, not whether the person can buy, is allowed to buy, or would be a customer worth having.

Three failure modes show up in every homegrown model:

• Enthusiasm outranks fit. The most active lead in the database is frequently a consultant, a competitor, or someone who will never have authority to sign. They score highly because activity is all the model can see.
• The weights are invented. Somebody decided a pricing page view is worth 15 points and a webinar registration 10. Nobody tested that ratio against closed revenue, and nobody revisits it.
• The output is a bare number. A lead arrives labelled 72. Sales has no idea what the 72 is made of, so they stop trusting it and go back to calling in arrival order.

There is a fourth, quieter problem: a behaviour-only model cannot score a brand-new lead at all, because the behaviour has not happened yet. The moment you most need a decision — a form just came in, who calls it — is the moment the model has least to say.

What does an “ideal customer” look like when it is written down?

It looks like a list of attributes you could check against a company’s website in two minutes. Vague statements about ambitious teams who value quality cannot be scored against, because no evidence would confirm or contradict them. A usable definition is specific, observable, and says what disqualifies. Write down five things:

1. What the company does. Industry or category in plain words — “ecommerce brands selling physical products direct to consumers”, not “commerce”. Three distinct segments means three personas, not one.
2. Size and shape. Headcount band, revenue band, or a proxy you can observe from outside, like the number of locations or whether they run paid ads at all.
3. Geography and language. Where you can sell, support and invoice.
4. The person. Role or function, and the seniority range that signs. “Marketing lead, agency owner, or founder who runs their own ads.”
5. Disqualifiers. What ends the conversation whatever else is true — competitors, students, industries you cannot serve for compliance reasons, regions you do not ship to, company sizes your pricing does not fit.

Disqualifiers are the part teams skip, and they carry more weight than the positive criteria. A model without them keeps promoting a perfect-looking lead who happens to work for your biggest competitor.

Then check the definition against reality before you score anything with it. Take your last twenty closed-won customers and your last twenty closed-lost or churned ones, and see whether it separates them. If it does not, the model built on it will not either, and you have automated a bad judgement at speed.

What data do you actually need to score a lead?

Less than you think, and it starts with the email address. A work email gives you a domain, a domain gives you a company, and a company gives you industry, size, location and what they sell. That single field supports most of a fit judgement before anyone has looked at behaviour.

In rough order of leverage:

• The email domain. The strongest single input for business leads, and the thing that splits your traffic into two populations: company domains, which are researchable, and free-mail addresses, which are not.
• Anything else the form captured. Company name, role, website, phone country code, the free-text “what are you trying to solve” answer. Self-reported and imperfect, but direct evidence of context.
• Public company evidence. What the site sells, rough size signals, whether they run ads, which market they serve. This is the research step that turns a domain into a profile.
• Source and campaign. Not a fit signal on its own, but the thing that lets you compare fit by source later.
• Behaviour. Pages, dwell time, return visits. A tiebreaker between two leads with the same verdict. Never the headline.

Free-mail addresses are not automatically bad leads — a sole trader running their own ads from a Gmail address may be exactly who you sell to. They need a different evidence path: the phone number’s country, the self-reported company name, the landing page they arrived on.

How do you turn an ideal customer into a score a machine can compute?

Split it into two steps: research, then judgement. First gather evidence about the lead from outside your own database. Then compare that evidence to your written persona and produce a verdict. Collapsing the two steps into one prompt or one weighted formula is what produces confident nonsense.

The output of the second step needs three parts, not one:

The fourth verdict — not enough data — is the one teams leave out and the one that keeps the model honest. A scorer with only three options forces a thin lead into “unlikely” and quietly buries someone who was never researched properly. Keeping insufficient evidence as its own outcome also tells you what to fix: collect a company field, or route those leads to a human.

Reasons are what make the system survive its first mistake. When a verdict is wrong and the reasons are visible — “classified as an agency because the site lists client work” — you can see which inference failed and adjust the persona. When it is a bare number, the only available response is to stop believing it.

Should you score with rules or with a model?

Both, in that order. Rules are deterministic, free to run and easy to explain, so they should handle everything factual: the disqualifiers, the geography check, the domain blocklist, the “is this a free-mail address” split. A model should handle the judgement rules are bad at — reading a company’s website and deciding whether this is the kind of business you serve.

Rules break on fuzziness. There is no regular expression for “mid-sized ecommerce brand that sells physical products”, and every attempt becomes a keyword list that misses the company describing itself in different words.

Models break on precision. Asked to score a lead with no persona to compare against, a language model produces a plausible number built on general notions of a good lead, which is not your good lead. It needs the written definition, and evidence gathered in the same run rather than recalled from training data.

The division that works: rules for facts, model for fit, human for the edge cases. Disqualify with rules before spending anything on research. Research and judge the survivors. Send anything that comes back as insufficient data to a person, and use what they decide to sharpen the persona.

How do you score a lead who never finished your form?

The same way, provided you captured the email. Fit scoring depends on the identifiers, not on the submit event — a domain is a domain whether or not the visitor reached the last field. The problem is that most stacks have no record of that person at all, because the only form event they track is the submission that never happened.

This is where scoring and capture meet. The people who typed an email and then stopped are not less qualified than the ones who pushed through — they were interrupted, or the phone field asked for more than they were ready to give. If you can capture a partial form lead in JavaScript, each becomes a partial lead: a record carrying an email, sometimes a phone number, and the source that produced it.

Score those the same way, and the ranking changes shape. A strong-fit partial lead is a better use of a salesperson’s morning than a weak-fit completed one — and that is the part of what form abandonment is costing you a completion-rate report cannot show, because it counts only the forms that finished.

What should happen to the score once you have it?

Three things, in descending order of value: sales sequencing, suppression, and feedback to the channels that produced the leads.

Sequencing. The score decides call order and response time, not whether a lead is worth existing. Strong-fit leads get contacted the same day, while the intent is warm; possible-fit leads go into a normal sequence; unlikely-fit leads get a self-serve path rather than a salesperson.

Suppression. Disqualified leads stop consuming attention: they stay in the database, stay contactable, and leave the queue.

Feedback to the ad platforms. This is the part most teams never wire up, and it is where scoring pays for itself twice. Ad platforms optimise toward the events you send them, so an account reporting every form fill as a conversion is training its algorithm to find more form fills — including the bad ones. Meta’s Conversions API accepts server-sent lead events with hashed customer information, and its custom-data fields let you attach a value to each one, so the platform can learn which leads were worth something. Sending qualified leads through the Conversions API, rather than every raw submission, changes what the algorithm goes looking for.

Scores also change reporting. Cost per lead is a vanity number when half the leads are unqualified; cost per good-fit lead ranks channels differently, and it is usually the honest input to which channel you should scale.

How does PartialLeads score leads against your ideal customer?

You describe your ideal customer once, in plain language, as the account’s persona. Every captured lead then runs through two enrichment steps: the first researches the lead’s email domain and the person behind it using live web search, and the second scores what it found against your persona. The lead comes back with a match verdict — strong match, possible match, unlikely match, or insufficient data — plus a confidence score and the reasons behind the call.

In the dashboard that lands as a Customer Match card on the lead, showing the verdict with a confidence ring and the reasoning underneath. Leads that come back as a strong match are lifted into a priority inbox above the main lead table, so the first screen a salesperson opens is ordered by fit rather than by arrival time.

Enrichment results are cached per email address and persona version, so re-opening a lead does not re-run the research or spend credits twice — and rewriting your persona does produce a fresh judgement, because the verdict belongs to that version of the definition. Accounts start with 25 enrichment credits, with monthly allotments after that.

The scoring input is the email address, which is why it composes with pre-submit capture: a visitor who typed their email and left still produces a lead record, and that record can be scored like any other. The verdict sits beside the journey, the source badge and the captured fields on the same lead, so “who is this” and “where did they come from” are answered in one place.

Four honest limits. Research depends on a public footprint, so a personal email with no company behind it returns insufficient data more often — a real verdict, not a hidden failure, and a signal to collect a company field on the form. Fit is not intent: the model says this person resembles your customers, not that they will buy this quarter. Your persona is the ceiling, so the fastest improvement available is usually rewriting it rather than changing anything else. And enrichment costs credits, so disqualifying obvious junk with rules before the research step is worth doing.

Sources

1. Meta for Developers — Conversions API: https://developers.facebook.com/docs/marketing-api/conversions-api/
2. Meta for Developers — Conversions API, custom data parameters: https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/custom-data