SDR queue scoring usually means one thing in practice: sort by lead score, highest first, work top to bottom. That single number quietly conflates two different questions into one, who this lead actually is and what they are doing right now, and a queue built on the blended answer treats leads that need completely different handling as if they were interchangeable.
SDR Queue Scoring Fails the Moment It Becomes One Number
A lead score is not naturally a single number, even inside the platforms built to calculate it. Per HubSpot’s own documentation, scoring is built around two genuinely different criteria types. Engagement scores evaluate “actions and interactions, such as visiting your website, subscribing to your newsletter, clicking a CTA, or opening a marketing email,” while fit scores “qualify records based on their demographic information through property values, such as their age, job title, company size, or annual revenue.” One measures behaviour happening in something close to real time. The other measures characteristics that barely change week to week.
HubSpot’s own combined-score feature, built specifically to answer whether a lead is worth working, does not actually collapse those two signals into one opaque figure. Per its own documentation on building lead scores, a combined score creates three separate, visible properties: “Total score value,” described as “the total value for the engagement and fit points combined,” alongside a distinct “Fit score value” and a distinct “Engagement score value.” Even the feature purpose-built to blend fit and engagement into one queue-sorting number keeps the underlying two components on the record, rather than throwing them away once the total is calculated.
Fit and Engagement Are Different Signals, and Only One of Them Decays
The reason HubSpot keeps the two components separate rather than only exposing the total is structural, not cosmetic. Engagement, being a record of specific timestamped actions, is built to decay: HubSpot’s own decay mechanism lets an admin “toggle the Decay scores switch on” and “select the percentage to reduce the score by, and the period of time that must pass to reduce the score,” with a worked example of “50% score decay every three months.” A page visit from six months ago should count for less than one from this morning, and the platform’s own scoring tool is built to reflect that directly in the number.
Fit does not work the same way, and HubSpot’s own documentation on how the scoring tool works scopes decay accordingly: “for engagement or combined score event groups, you can turn on score decay,” a scope that is specifically about event-based criteria, not the property-value criteria fit scores are built from. The same documentation makes the underlying reasoning explicit elsewhere, in the context of segment-membership criteria: “score decay is not supported for segment membership criteria. This is because segment membership is based on a binary condition (is or is not a member), while decay is based on a timestamp.” A contact’s job title or a company’s revenue band is not a timestamped event that grows stale the way a page visit does, it is closer to a binary fact that is either currently true or currently false. Applying a decay curve built for engagement onto a signal that does not actually decay the same way produces a number that looks precise but is measuring something that was never time-sensitive in the first place. The distinction matters most at exactly the moment a flat sort obscures it: two leads with identical Total scores can be in completely different situations underneath, one still climbing on genuinely fresh activity, the other holding steady mostly because its fit component never moves, with engagement that has already quietly decayed toward zero.
What Queue Logic Should Actually Do With the Two Components
A queue sorted purely by the Total score number treats a high-fit lead whose engagement has quietly decayed and a lower-fit lead who is currently very active as interchangeable, whenever their combined totals happen to land close together. They are not interchangeable, and they should not be worked the same way. The first needs a re-engagement touch, something that earns attention again, not a straight pitch assuming recent interest that has actually gone cold. The second needs speed, since active engagement from a less-ideal-fit account is often a narrower window than a dormant high-fit account represents.
Building queue priority around the Fit and Engagement components separately, rather than the single Total number a flat sort produces, means a rep’s queue can actually reflect that distinction: a high-fit, recently-decayed lead surfaces as a re-engagement task rather than getting buried under leads with a higher combined total purely because their engagement number happens to be currently inflated. A lower-fit, freshly-engaged lead surfaces as a speed-sensitive task rather than getting deprioritised because its fit component drags the combined total down. Neither of those distinctions is visible from the Total number alone, and both are already sitting there as separate, named properties on the record.
In practice this can be as simple as building queue segments or views around the Fit and Engagement properties directly rather than around the Total score property alone: one segment for high fit with engagement that has meaningfully decayed, flagged for re-engagement outreach; another for engagement currently near its peak regardless of fit tier, flagged for speed; and a general working queue for records that do not fall clearly into either pattern, still usefully sorted by Total for the middle of the distribution where the distinction matters less. None of this requires new data. It requires treating the two properties HubSpot already calculates separately as separately useful, rather than discarding them the moment the Total number exists.
Where Teams Get This Wrong
The most common mistake is sorting the queue by the combined Total score and stopping there, treating it as the finished answer rather than as one number built from two components that were deliberately kept separate for a reason.
The second common mistake is applying decay logic uniformly across every scoring criterion, without noticing that HubSpot’s own decay mechanism explicitly does not support binary, non-timestamped criteria like segment membership. Fit characteristics that do not genuinely decay should not be forced through a decay curve built for behavioural data that does. It is also worth knowing that lead scoring itself is tier-gated: per HubSpot’s own documentation, it is “available with any of the following subscriptions, except where noted: Marketing Hub Professional, Enterprise” and “Sales Hub Professional, Enterprise,” so a team on a lower tier cannot build this multi-component structure inside HubSpot itself at all, regardless of how the queue is meant to work.
The third common mistake is treating a high combined score as always meaning “work this lead first,” when a lead scoring high mostly on stale engagement that has not fully decayed yet needs a different kind of outreach than a lead scoring high on genuinely current activity, even if their totals currently match. The decay curve smooths that transition rather than making it instant, so a lead can sit at a misleadingly high Total for a while after its actual engagement has already gone quiet.
The fourth common mistake is building separate scores for different teams or regions, which HubSpot’s own documentation explicitly supports, but never actually differentiating queue logic between them, defaulting every queue back to the same generic Total-score sort regardless of which score was built for that specific team’s actual priorities.
The fifth common mistake is assuming the fit and engagement components matter equally for every kind of queue. A speed-to-lead queue built around fresh inbound activity should weight the decaying engagement number more heavily, since the whole point of that queue is catching people while their interest is still live. A target-account prospecting queue should weight the static fit number more heavily instead, since the goal there is working the right accounts regardless of whether any single contact has recently clicked anything. Using the same weighting between the two components for both kinds of queue quietly optimises neither one properly, since the two queues are answering genuinely different operational questions rather than the same question at two different speeds.
Related Reading
For the wider automation this scoring logic feeds into, see Automating HubSpot Lead Scoring with n8n. For the SDR process this queue sits inside, see Scalable SDR RevOps Framework with HubSpot and n8n. For what happens once a lead is actually assigned, see HubSpot Lead Routing Automation.
Go deeper: HubSpot Consultancy · RevOps Consultancy
Frequently Asked Questions
Why shouldn’t an SDR queue be sorted by a single combined lead score?
Because that single number blends two structurally different signals, static fit characteristics and timestamped, decaying engagement, into one figure. A high-fit lead with decayed engagement and a lower-fit lead with fresh engagement can land on similar totals despite needing entirely different outreach, a distinction the blended number alone does not show.
Does lead score decay apply to fit criteria like job title or company size?
No. HubSpot’s own documentation scopes score decay to engagement and combined-score event groups specifically, not to the property-value criteria fit scores are built from. The same documentation explains the underlying logic elsewhere: decay is not supported for binary, non-timestamped criteria, since decay itself is based on a timestamp, which is why it applies to behavioural events rather than to static demographic fit data.
Does HubSpot’s combined lead score hide the separate fit and engagement values?
No. A combined score creates three separate properties on the record: Total score value, Fit score value, and Engagement score value. HubSpot keeps all three visible rather than only exposing the blended total, which is what makes it possible to build queue logic around the underlying components rather than the combined figure alone.
Can different teams use different lead scores in HubSpot?
Yes. HubSpot’s own documentation confirms multiple scores can be created per object to meet the goals of different teams or regions. The gap most teams miss is building genuinely different queue logic around each score rather than defaulting every team’s queue back to the same flat Total-score sort.