The brief was simple: leads are going to the wrong reps. Fix it.
It took two weeks of auditing to figure out that the routing rules were not actually the problem. This is the pattern behind most lead routing system problems: the logic looks reasonable, the data underneath it does not.
Why the client’s lead routing system problems weren’t in the rules
A 50-person GTM team at a growth-stage tech company had built their lead routing in HubSpot over three years. Rules multiplied as the business grew. New territories, new product lines, new rep onboarding. Each change was documented, tested, patched in.
When I started the audit, the routing logic looked reasonable on paper. 47 actions in the master workflow. Persona signals, territory logic, round-robin pools (where leads are distributed evenly across a rep pool). On the surface, it made sense.
But 30% of high-intent inbound leads were either going to the wrong rep or sitting unassigned for more than four hours. Leads going to the wrong rep is exactly the symptom that makes a routing audit urgent, because by the time it surfaces, the damage is already weeks deep.
What was actually happening
Three separate problems, each invisible on its own.
Problem one: Ownership hierarchy drift. When accounts were reassigned in Salesforce, the change did not propagate back to HubSpot consistently. A lead would arrive at a company where the Salesforce account owner was now a different rep, but HubSpot still thought the old rep owned it. The routing logic was technically correct. It was operating on stale data.
Problem two: Capacity checks that did not check capacity. The round-robin pool logic was supposed to route away from reps at limit. But the limit field was updated nightly in a batch job, not in real time. A rep who had just accepted three demo requests in an hour was still showing as available. The intent was right. The implementation window was wrong.
Problem three: Territory waterfall order. When a lead did not match a specific territory rule, it fell through to a generic assignment. That generic assignment was a catch-all bucket set up in 2022 for a product line that no longer existed. Leads were going there and sitting.
None of these were obvious from looking at the routing rules in isolation. They required mapping the full data flow: where each field came from, when it was updated, what triggered each branch.
How we fixed it
The repair was less dramatic than the discovery.
For the ownership drift: we replaced the nightly sync with a real-time Salesforce trigger that wrote account owner changes back to HubSpot within two minutes of the change. One n8n workflow, about four hours of build.
For the capacity window: we moved the limit check to fire on a rolling two-hour basis rather than a nightly batch. Not real-time, but close enough to match how demo requests actually cluster.
For the waterfall: we mapped every territory rule to active rep pools, deleted the dead-end catch-all, and added a hard alert if any lead sat unassigned for more than 15 minutes.
The routing rules themselves barely changed. What changed was the data infrastructure underneath them.
The lesson
Routing problems almost always get diagnosed as logic problems. The instinct is to rewrite the rules.
But the rules usually reflect genuine business requirements. The problem is that the rules are operating on data that does not reflect reality, on a timeline that does not match how the business works.
Before touching routing logic: audit the data. Where does each field come from? When is it updated? Does that timing match the decisions the logic is making?
Most of the time, that is where the actual fix is.
This is the technical story behind the Multi-Tier Intelligent Lead Router engagement. If you are working on routing gaps you cannot explain, start with a 30-minute call.