Your rep just spent 45 minutes on a demo with a two-person agency that signed up in March and never activated. Meanwhile a VP of operations at a 120-person SaaS company logged in four times this week, invited a teammate, and hit your pricing page twice. Nobody called her. Lead scoring exists to prevent exactly this: rank every lead by how likely they are to buy, so your team works the list from the top.
What lead scoring is and why most models fail
A lead score is one number that answers two questions at once. Does this lead look like your best customers, and are they acting like someone about to buy? A director at a 50-person SaaS company who created a workspace and viewed pricing outranks someone with the perfect job title who downloaded a whitepaper six months ago and vanished.
Without a score, sales defaults to recency. Whoever signed up last gets the call, along with whoever the CEO forwarded. That holds up at 20 leads a month. At 200 it starts to leak, and at 2,000 your best leads go cold in the queue while reps demo to agencies outside your market.
Here is the part the definition leaves out: most lead scoring projects die within a quarter, and almost never because the point values were wrong. Hold that thought. The reason matters more than the taxonomy.
Demographic, behavioral, and predictive lead scoring
Every model draws on the same three approaches. The differences come down to what gets measured and who sets the weights.
Demographic scoring (firmographic, when you score accounts) assigns points for who the lead is: job title, company size, industry, funding stage. If 80% of your customers are B2B SaaS companies with 20 to 200 employees, a lead matching that profile starts higher. Fit is the whole story here. Intent never enters the equation.
Behavioral scoring is the intent half. Signups, feature activation, pricing page visits, demo requests, email replies: these earn points for what the lead does, and a lead who invited two teammates is telling you something no firmographic field can.
Predictive scoring flips the weighting problem around. Instead of you deciding that a pricing page visit is worth 5 points, the model derives weights from the attributes your closed-won deals shared. It needs history to work, typically 1,000 or more closed deals. We don't have much firsthand experience with the enterprise predictive tools, but the pattern we hear from RevOps people is consistent: strong when the history exists, noise when it doesn't.
Scoring approach | Best for | Weakness |
|---|---|---|
Demographic | Filtering out poor-fit leads early | Says nothing about intent |
Behavioral | Catching in-market leads while warm | Blind to company fit |
Predictive | Teams with 1,000+ closed deals | Needs history most teams lack |
Most teams should start with a combined model: fit points plus intent points on a 0 to 100 scale, where anything above 70 goes to sales and 40 to 70 enters nurture.
One opinion while we're here. The MQL threshold debate that eats so many pipeline meetings is rarely about the model. It's a negotiation over whose numbers look good this quarter, and no weighting scheme fixes politics. Anyway.
The data a lead scoring model actually needs
Now the reason lead scoring models die. Write down the inputs a combined model wants: company size, industry, product usage, billing status, support history, email engagement. Then write down where each one lives.
Billing status lives in Stripe. Usage sits with your product database or an analytics tool like PostHog, ticket history with the support desk, and firmographics may not exist anywhere yet. The CRM, the one place the score is supposed to live, holds a job title, an email, and a last-activity date.
So teams build the model with the fields the CRM actually has. The scores come out flat, sales checks them against instinct a few times, finds them wrong, and quietly goes back to recency. The model was fine. The data was incomplete.
The standard fix is a warehouse project: pipe everything into Snowflake, model it in SQL, push scores back with a reverse ETL job. If you employ a data engineer, that is a real path. Most 30-person companies do not, and a scoring project that takes a quarter to stand up loses its sponsor before it ships.
The first scoring model we shipped was a CRM property fed by a Sunday-night CSV export. It was stale by Tuesday and ignored by the end of the month. The logic was never the problem; nobody believed the freshness.
Scoring every lead in one table with AI
There is another way to assemble the inputs, and it runs in the opposite direction: instead of pushing every signal into the CRM and building rules inside it, pull the CRM rows out into a table built for enrichment. Each lead becomes a row whose columns fill themselves: firmographics from a waterfall of data providers, plan and revenue from billing, usage from product analytics, ticket text from the support desk.
Once the evidence sits in one table, AI can do something per-lead formulas cannot: reason across all of it at once. A formula checks one row against thresholds you maintain by hand. The difference with table-level scoring is scope: it reads every row, weighs each lead against your ICP definition, and writes two things per lead, a score and a reason. That is what AI lead scoring should mean in practice. Not a black-box grade, but a ranked list where every row carries its evidence.
Here is a worked example, because this is where every explainer goes vague. Say your ICP is product-led B2B SaaS between 20 and 200 people. A scoring pass over the table weighs signals like:
Signal | Source | Weight |
|---|---|---|
Headcount between 20 and 200 | Data provider | +20 |
Raised funding in the last 18 months | Data provider | +15 |
On a paid plan | Your billing system | +25 |
3+ active users this week | Product analytics | +20 |
Ticket asks about SSO or API limits | Support desk | +10 |
No login in 30 days | Product analytics | -20 |
An 82 arrives with its reason attached: "paid plan, usage climbing, asked about SSO."
Reps will argue with a bare number all day. A stated reason they can check in ten seconds, and when a score is wrong, the reason shows which input to fix. Note the negative row too: without decay, the pipeline fills with leads that peaked in April. The same pass works as account scoring, by the way. Swap lead rows for account rows and score against the same ICP.
The spreadsheet-plus-ChatGPT version of this is where most founders start, and it genuinely works at fifty rows. Past a few hundred it collapses: the chat cannot hold the whole list, the weights live in a prompt you keep re-pasting, and nothing re-runs when a lead upgrades a week later.
Writing lead scores back to your CRM
Lead scoring only pays off when the score reaches the person holding the phone, and that person lives in the CRM. The last step writes both fields back to the record: the score into a number property reps sort by, the justification into a text property they see when the record opens. Route from there: high scores to a rep's queue, product qualified leads into a fast lane, everything else into nurture.
Write-back is also what keeps the score alive. When billing flips a lead to a paid plan, the next scoring pass moves the number, rewrites the reason, and the CRM follows. We cover the CRM-specific setup separately for HubSpot and Salesforce. Both hold external scores happily; neither can compute one from data it cannot see.
This loop is what we built Oneprofile around. Your CRM loads in as rows, enrichment columns fill from data providers and from your own billing, support, and product tools (127 integrations work as both sources and destinations), and AI scores the whole table with a written reason per row. Score and reason sync back to the CRM two-way on the $20 plan, and the free tier renews 200 credits a month, so you can score a real list before paying anything.
If you want to test the premise before touching any tool, do this: pull your last 50 closed-won deals, write down the five signals they shared, and count how many of those signals your CRM can currently see. That gap is your scoring project. Close it, and the ranking mostly takes care of itself.
What is lead scoring?
What is the difference between rules-based and AI lead scoring?
What data do I need for a lead scoring model?
Do I need a data warehouse for lead scoring?
What is the difference between MQLs, SQLs, and PQLs?
