RevOps Strategy
September 15, 2026 · 5 min read · by Ananda Narasimhan
Most HubSpot portals have a lead score. Fewer have one anyone trusts. The usual failure mode isn't a missing model — it's a score built once during onboarding, never revisited, and quietly ignored by reps who've learned it doesn't correlate with anything real. Routing has the same problem: a workflow built for a five-person sales team that nobody has touched since, still round-robining leads to a rep who left the company eight months ago.
Fixing both takes less HubSpot cleverness than people assume. It takes a scoring model built on evidence instead of guesses, and routing logic that doesn't depend on someone remembering to update an owner list every time headcount changes.
The single biggest fix we make in a scoring rebuild is splitting one blended score into two: fit and intent. Fit is firmographic — company size, industry, tech stack, whether they match the ICP at all. It doesn't change much once set. Intent is behavioral — pricing page visits, demo requests, email engagement, product usage if you're PLG. It changes constantly and decays if you don't touch it.
Blend the two into a single number and you get false positives: high-intent visitors from companies that will never buy, and perfect-fit accounts sitting quiet because nobody's scored their silence as a signal to nurture rather than route. Score them as two properties, route on the combination, and the logic becomes something you can actually explain to a rep who asks why a lead landed on their desk.
Routing workflows that hardcode rep names or ownership by contact ID break the moment territory changes or someone leaves. The fix is routing on properties instead: a territory field, a segment field, a round-robin queue tied to a team rather than an individual. HubSpot's native lead routing tool handles round-robin and weighted assignment natively as of the current release — use it before reaching for a custom workflow, and reserve workflow-based routing for the exceptions the native tool can't express.
Whichever mechanism you use, the assignment logic should read from properties that get maintained somewhere else — territory mapping, team membership, active/inactive status — not from a list baked into the workflow itself. That's the same principle behind keeping your underlying data trustworthy in the first place; see our CRM hygiene audit for the checks that catch stale ownership before it causes a misroute.
A setup that holds up needs four things in place: a fit score property computed from company-level data (ideally synced from enrichment rather than manually maintained), an intent score property that decays over time instead of accumulating forever, a lifecycle stage that actually gates routing rather than just describing status after the fact, and an active routing roster stored as a property or list, not as names typed into a workflow branch. Get these four right and the workflow logic on top of them stays simple — usually simple enough to read in one pass without a flowchart.
Before calling a routing rebuild done, run test leads through every branch — every fit tier, every intent tier, every territory — and confirm they land where the logic says they should. This is the step teams skip because it's tedious, and it's the step that catches the branch nobody remembered to build, the property that's blank for 20% of records, or the queue with zero active members. This is core revenue operations work, not a one-time project; scoring thresholds and routing rules both need a quarterly review against actual conversion data, or they drift back into the state you just fixed.
None of this requires new tooling. HubSpot's native scoring and routing objects can carry this entire setup — the gap is almost never the platform. It's a scoring model nobody has revisited since launch, and routing logic that depends on a list someone forgot to update.