A lead score is addition. Somebody decided a demo request is worth fifteen points and a pricing page visit is worth five, the CRM keeps a running total, and records above a line get called first. There is no mathematics in it beyond what the total is capped at, and none of the arguing teams do about point values changes that.
Which is why the interesting question is never how the points are weighted. It is what the score is allowed to look at.
Every lead scoring model is a function over available evidence, and the available evidence is decided long before anyone opens the scoring tool. It is decided by which systems your CRM is connected to. A score built on marketing engagement will faithfully rank people by their marketing engagement, and it will do that with total confidence whether or not marketing engagement is what predicts a purchase in your business. The number comes out clean either way. That is the failure mode: not a wrong answer, but a precise answer to a question nobody meant to ask.
This guide covers what lead scoring is, how HubSpot's scoring tool actually works and what it costs to turn on, the specific and documented boundary of what it can see, and the point at which closing that gap stops being configuration and becomes something you have to build.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
What Lead Scoring Actually Is
The definition is not contested. Lead scoring assigns numeric points to a record based on evidence that the record will become revenue, so that sorting can happen at a scale where reading is impossible. Two hundred inbound contacts a month is a reading problem. Twenty thousand is a sorting problem, and a score is the sort key.
The useful part of the definition is the split underneath it, because HubSpot names the two halves precisely and they behave nothing alike.
Fit: who the record is
HubSpot defines fit scores as qualifying records based on their demographic information through property values, such as their age, job title, company size, or annual revenue. Fit is stable. It answers whether this is the kind of buyer you sell to, and the answer does not change because somebody opened an email on Tuesday.
Engagement: what the record has done
HubSpot defines engagement scores as qualifying records based on their actions and interactions, such as visiting your website, subscribing to your newsletter, clicking a CTA, or opening a marketing email. Engagement is volatile by design. It answers whether they are paying attention right now, and it is worthless as a measure of whether they should be.
Combined: both, kept apart
A combined score maintains three properties rather than one: a total score value for the engagement and fit points together, plus separate fit and engagement score values. This is the configuration worth using, and the reason is in the next paragraph.
Keep the halves separate and the model can distinguish between two records that a single total cannot tell apart: the perfect-fit enterprise account that has never visited your site, and the enthusiastic student who has read everything. Those records demand opposite responses. Added together they can produce the same number, and at that moment the score has thrown away the only fact a rep needed.
This is the first and cheapest thing most scoring models get wrong, and it costs nothing to fix. It is also, unfortunately, not the expensive thing.
HubSpot Lead Scoring: What It Needs and What It Gives You
The lead scoring tool is available on Marketing Hub Professional and Enterprise and on Sales Hub Professional and Enterprise, and Edit permissions for Lead Scoring are required to create a score. So far, so ordinary.
The split inside that availability is what catches teams out, and it is worth knowing before a planning meeting rather than during one.
| Score type | Requires | Scores what |
|---|---|---|
| Contact score | Marketing Hub Professional or Enterprise | The person |
| Company score | Marketing Hub or Sales Hub, Professional or Enterprise | The account |
| Deal score | Sales Hub Professional or Enterprise | The open opportunity |
Read that as a sentence rather than a table. Scoring the person and scoring the deal are on different subscriptions. A revenue team that wants one consistent qualification model across the contact, the account and the opportunity is buying two hubs at Professional or above, which makes this a licensing decision wearing a configuration costume. It is a fair charge, and it belongs in the plan early, because discovering it after the model is designed means redesigning the model around whichever hub you actually own.
The mechanics themselves are generous. Scores are built from groups, either property groups for fit rules or event groups for engagement rules, and you add or subtract points when criteria are met. Event rules can be filtered by frequency or by a time window using the operators In the last, Before, After, or In between. Rules can reach associated records, including by association label, so a contact score can take account of the company it belongs to. The default maximum for a score is 100 points, and the limit can be widened through a fixed set of ranges up to -10,000 to 10,000.
Score decay is the intended answer to that, and it is well designed. It automatically reduces an individual event's score based on how long ago the scored event occurred, at intervals of 1, 3, 6, or 12 months. Note the wording carefully though, because it matters later: decay is described as acting on events. Hold that thought until the build section.
The Twelve Events, and Why the List Is the Finding
HubSpot ships an AI insights feature that recommends scoring rules by analyzing which events in your account actually precede conversion. It is a genuinely good feature. It shows each event with its conversion rate and a confidence level, described as how reliable the signal is, based on an event's conversion rate and sample size, and it bases its rules on the last 90 days of activity, showing events up to 14 days prior to goal stage conversion. That is a sound methodology, stated openly, with the window published.
It also publishes the exact list of event types it analyzes. Here it is in full.
Every event type HubSpot's AI insights evaluates
Form submission and Page visited
Opened email, Clicked link in email, Bounced email and Email Delivered
Updated email subscription status and Workflow enrolled
CTA click and Media Played
Marketing Event Attended and Marketing Event Registered
Go down that list and ask what kind of company it describes. Twelve event types, and every one of them is a marketing interaction. Four are about email. Two are about webinars. One is about whether a video was played.
There is no product event on that list. No trial activity, no feature usage, no seat added. There is no payment event: no invoice paid, no card declined, no plan upgraded. There is no support interaction: no ticket opened, no ticket escalated, no conversation with a human. There is nothing about a sales conversation beyond whether an email was delivered.
HubSpot's AI will tell you, accurately and with a confidence level attached, which of your marketing events best predicts conversion. All twelve things it can consider are marketing events. The answer is trustworthy. The question was set before anyone asked it.
This is not a criticism of the feature, which does exactly what it says. It is an illustration of the structural point, and HubSpot happens to have documented the boundary unusually clearly here. Most tools leave you to discover the edge of the evidence by noticing, eventually, that the score is confidently wrong about a particular kind of customer.
What a Lead Score Cannot See
The manual scoring builder reaches further than the AI insights surface, since you choose the event types yourself. But it is reaching into the same pool: activities HubSpot itself recorded. And the boundary of that pool has one documented edge so precise it is worth quoting directly.
Generalize that one note and you have the rule that governs the whole category. An event is scoreable if HubSpot generated it. Page views need HubSpot's tracking code on the page. Email engagement needs the email to have been sent as a HubSpot marketing email. Form submissions need HubSpot forms. Every one of those is reasonable, and collectively they describe a company whose entire buyer interaction surface is HubSpot.
Very few companies are that company. The stack that a scoring model needs to see across usually looks more like this.
None of this makes HubSpot's scoring bad. It makes it a scoring engine over HubSpot's own data, which is precisely what it is documented to be. The problem only appears when a team treats the output as a measure of purchase intent rather than a measure of marketing engagement, and then spends two quarters adjusting point values to fix a gap that point values cannot reach.
Fit Scoring Is Only as Good as the Properties Behind It
The engagement half has a visible boundary. The fit half has a quieter one, and in practice it does more damage.
Fit scoring reads property values. That is a genuinely open door, because a property is a property regardless of what filled it, and this is the mechanism that makes external data scoreable at all. But it inherits every weakness of the fields underneath it, and those fields are mostly filled by forms, by enrichment, and by humans.
A fit model that awards points for Number of employees above 200 is not measuring company size. It is measuring the subset of records where Number of employees is populated and correct. If enrichment fills it for 60 percent of records and your form never asks, then 40 percent of your database scores as small companies, and the model will keep telling you, with a straight face, that enterprise leads are rare in your funnel. Our guide to HubSpot data enrichment covers what the native enrichment actually fills and, more usefully, which records it reliably skips. Those skipped records are the ones your fit score is most confidently wrong about.
There is a second and subtler issue. A property holds one current value. It has no memory. That is fine for Industry and disastrous for anything shaped like a rate, a trend or a count within a window, which is what almost every strong behavioral signal is shaped like. "Logged in eleven times in the last seven days, up from two" is not a value a property can hold. It is a computation over a history, and the only way it becomes scoreable is if something outside HubSpot performs that computation and writes the answer into a field.
Hold on to that sentence, because it is the whole build.
Predictive Lead Scoring and AI Lead Scoring Are Not the Same Thing
Three differently named things in HubSpot are routinely conflated in the same meeting. Separating them takes one table.
| Feature | Requires | What it produces |
|---|---|---|
| Lead scoring tool | Marketing Hub or Sales Hub Professional and above | Scores you define, from rules you can read and change |
| AI lead scoring | Marketing Hub Enterprise | Recommended criteria and points, generated from your own contact data |
| Predictive lead scoring | Marketing Hub or Sales Hub Enterprise | A Likelihood to close property and a Contact priority tier |
The AI option trains on your account's contacts to recommend criteria and points, and HubSpot notes that contact evaluation can take up to one hour. It needs a minimum sample of 50 contacts containing 25 converted and 25 non-converted, which is a low bar and a sensible one, though it is worth registering that a model trained on 25 wins is a suggestion rather than a finding.
Predictive lead scoring is the older and more opaque of the two. It produces Likelihood to close, described as a score that represents the percentage probability of a contact closing as a customer within the next 90 days, and a priority tier where each tier contains 25% of your contacts. Note what that last detail means in practice: the tiers are relative, so a quarter of your contacts are always Very High, including in a quarter where nothing is going to close.
HubSpot is refreshingly direct about the cost of the approach.
The practical recommendation is dull and holds up. Use the explicit scoring tool as your primary model, because you can read it, argue with it and fix it. Use the AI recommendations as a second opinion on which of your events actually correlate, which is real information. Treat Likelihood to close as a tiebreaker within an already-qualified list rather than as qualification.
How Outside Signal Actually Reaches a Score
Here is the part that decides whether a scoring project works, and it is architectural rather than strategic.
HubSpot's scoring criteria come in two kinds: property values and events. Those two doors behave very differently for anything originating outside HubSpot.
The event door is mostly closed
The event types available to scoring are HubSpot's own activities, and HubSpot's lead scoring documentation does not describe custom behavioral events as a scoring criterion. HubSpot does have a full custom events API, and it is a capable one: it requires Professional or above, accepts up to 1250 requests per second, allows up to 50 properties per event occurrence, permits 500 unique event definitions per account, and associates each occurrence to a record by custom matching ID property, record ID, email, or contact usertoken. Those events are excellent for analytics and reporting. Plan the scoring model around properties rather than assuming events you send will be scoreable.
The property door is wide open
Any property can be a fit criterion, and HubSpot neither knows nor cares whether a human, a form, an enrichment provider or your integration wrote the value. This is the reliable route, and it is available on every tier that has scoring at all. It just requires that the signal arrive already reduced to a value.
That asymmetry sets the shape of the work precisely. The integration's job is not to stream raw activity at HubSpot and hope the score finds it. The job is to do the thinking outside HubSpot and land a conclusion inside it.
- 1
1. Decide the question the score needs answered
Not "send us product data". Something a rep would recognize, such as whether this account has used the feature that predicts an upgrade, in the last 14 days, at least three times. A vague requirement here produces a field nobody trusts, which is the most common way these projects fail quietly.
- 2
2. Compute it where the history lives
Counts, rates, recency and trends are aggregations over event history, and the system that owns the events is the only place that can compute them cheaply. Doing this on the HubSpot side means reconstructing a history HubSpot was never given.
- 3
3. Write one property, not twenty
Land the answer in a small number of well-named custom properties: a tier, a count, a recency in days, a boolean. Every additional field is one more thing to keep correct, and fit scoring compares values, so a clean
usage_tierof High, Medium or None beats fifteen raw counters that each need their own rule. - 4
4. Revise it on a schedule, including downward
This is the step that gets skipped. Score decay acts on events, so a property written by an integration holds its points until something changes it. A signal that was true in March is still adding points in September unless your integration goes back and says otherwise.
- 5
5. Make the write auditable
Keep the field the integration owns separate from anything a human edits, and record when it was last computed. When a director asks why an account scores what it does, the answer needs to be traceable to a value and a timestamp rather than to a shrug.
Step four is worth dwelling on, because it is the difference between a score and a ratchet. An integration that only ever writes a signal when it fires, and never revisits it, produces a model where every account's score rises monotonically forever. It will look like it is working for about two quarters.
For the mechanics of getting values in and keeping them right, the API integration guide covers the failure layer in detail, and data mapping covers what happens when the two systems disagree about what a field means. Before any of it, identity has to be settled, because writing a usage score to the wrong contact is worse than writing nothing.
What HubSpot Sells You Instead, and When It Is Enough
It is only fair to note that HubSpot has an answer to the visibility problem, and for one class of signal it is a good one.
Company Surge, powered by Bombora, is described as an intent signal in HubSpot that detects when a tracked company's research activity spikes on topics related to your business. It arrives as events carrying properties such as topic and research level, it can contribute to a company's combined score, and it is included in the existing per-company tracking cost rather than charged per signal, though it consumes HubSpot credits and is capped at 12 Bombora topics per account.
Worth understanding what it is, though. This is third-party data about anonymous research activity across the web, which is a genuinely different thing from your own first-party evidence. It is useful for finding accounts before they raise a hand. It tells you nothing about whether the account currently in your funnel is using your product, paying their invoices, or filing angry tickets.
The distinction is the one that runs through this entire guide. HubSpot will happily sell you more data about strangers. The data about your own customers, the data that is already yours, is the part that requires a connection.
When Lead Scoring Becomes a Build
Most scoring problems are not build problems, and it would be dishonest to pretend otherwise given what we sell. Here is the honest sorting.
Split fit from engagement, turn on decay, and check the score's performance reports, which show trends based on the monthly average, maximum, and minimum scores from the past 365 days. Most models that people describe as broken are one of these three things, and all three are an afternoon of configuration. Start here every time.
A scoring rule over a field that is filled for half your records is a coin flip with extra steps. Run a HubSpot audit on property fill rates and duplicates before touching point values. This is unglamorous and it is frequently the whole answer.
Product usage, payment events, support load and conversation data are not configuration gaps. They are absent inputs, and no rule change reaches them. If a rep maintains a private list because they know the score is wrong in a predictable direction, that private list is the integration, and a person is running it manually.
The tell is specific and easy to check. Ask whoever works the scored list what they ignore. If the answer is vague, the model needs tuning. If the answer is immediate and specific, "I skip anything from a free-plan account that has not logged in", then the missing input is named, it is quantifiable, and it lives in a system with an API.
Signs the score needs data it does not have
A rep keeps a separate list, and can tell you exactly which kind of record the score gets wrong
Product usage, trial activity, payment state or support volume are agreed to matter and appear on no record
The signal you need is a count, a rate or a recency across a window, which a single property value cannot express without something computing it first
Somebody exports the scored list monthly and joins it against a second export before anyone acts on it
Calls are placed through a dialer that is not HubSpot's, so the highest-intent event you have contributes nothing
A field that the model depends on is updated by hand, on a cadence nobody has written down
What This Costs to Own
The build itself is usually modest. Writing a computed usage tier into a HubSpot property on a schedule is not a large piece of engineering, and anyone quoting six figures for it should be asked what the other ninety percent is for.
The cost that gets underestimated is the same one that gets underestimated on every integration: the connection has to keep being right. Your product ships a new event name. HubSpot properties get renamed during a cleanup. The aggregation window that made sense at 200 accounts stops making sense at 2,000. A score that is quietly computing against a field nobody has written to since June is worse than no score, because people are still sorting by it.
That is why we productized it. StackTie builds the connections between HubSpot and the systems that hold your real buying signals, product, billing and support, written against the APIs directly for a fixed fee, then maintains them on a flat monthly retainer. The build fee and the retainer are published on the pricing page rather than quoted per call.
What does your lead score actually know?
If the highest-intent thing a buyer can do happens in your product, your billing system or a support ticket, your score has probably never seen it. StackTie builds custom HubSpot integrations that put those signals on the record where scoring can reach them, for a fixed fee, maintained on a flat monthly retainer. Live in 14 days or you don't pay. Book a free audit and we'll map which of your buying signals currently reach HubSpot and which do not.
The Bottom Line
Lead scoring has a reputation as a modelling exercise, and it is not one. The arithmetic is trivial, the tooling is mature, and HubSpot's implementation is capable and unusually well documented, down to publishing the exact list of events its AI considers and stating plainly that its predictive model is a black box.
Read that documentation closely and the same shape appears everywhere. Twelve event types, all of them marketing. Call scoring that counts only calls placed through HubSpot. Fit scoring that will compare any property value you like, and no way to compute the aggregation that would make an external signal into a property value in the first place.
None of that is a defect. It is a boundary, and it is exactly where you would expect a CRM's boundary to be. The mistake is not HubSpot's. It belongs to every team that reads a number produced inside that boundary as though it were a measure of intent produced outside it, and then spends a quarter adjusting point weights to close a gap that point weights do not touch.
So before the next scoring workshop, ask a different question than the usual one. Not what a demo request should be worth. Ask which of the things your best customers reliably do before they buy, your score has ever been in a position to observe. If the honest answer is "about half of them", you do not have a scoring problem. You have an integration that nobody has built yet, and the score is doing its arithmetic on whatever evidence happened to be within reach.
