What is lead routing?

What is lead routing?

Lead routing is the set of rules a CRM or workflow tool applies the moment a new lead arrives, to decide which person or team becomes the owner. It runs on trigger: a form submission, a call booked, a contact created, a deal reaching a stage, and it produces one output, an assigned owner, without anyone touching the record.

It is a narrower job than it sounds. Routing does not decide whether a lead is worth working, that is lead scoring. It does not decide what happens next in the sales process, that is the pipeline. Routing answers exactly one question: whose desk does this land on, and how long does that take?

The second half of that question is the part most setups get wrong. A rule that correctly assigns a lead six hours after it arrives has still failed, because the first five minutes decide most of the outcome. Routing and speed to lead are the same problem measured from two ends: routing is the mechanism, speed to lead is the clock it is supposed to be racing.

The four routing models

Every setup we could document builds on one of four models, or a combination. None of the four vendors checked for this piece document all four natively. Here is what each one does, and who documents building it.

1. 1.
   Round robin

   New leads rotate through a fixed list of people in sequence, so the load stays even over time regardless of who is having a good week. HubSpot documents this as a distribution option inside its "Rotate record to owner" workflow action: "Round Robin: assign records in a rotating, sequential order." Pipedrive builds it into its Team assignee type: selecting a team "uses a round-robin to distribute newly created data between its members." GoHighLevel builds it as a workflow action named "Assign to User", set to round-robin, paired with a separate "Split Traffic" field you can set to Equally or Unevenly.

   Three vendors, three different implementations of the same idea: a native distribution field, an assignee type tied to a team object, and a standalone action you wire into a workflow yourself. If you are checking whether your CRM does round robin, the answer is rarely a single toggle, it is whichever of these three shapes that vendor chose.

2. 2.
   Territory-based

   Leads are assigned by a property of the lead, most often geography, but also company size or industry. HubSpot's own description of this inside Sales Hub: routing rules "based on geography, company size, industry, and rep capacity", so that "every record lands with the right owner" without a rep checking a spreadsheet of who owns which region.

   Territory rules are usually built as conditional branches in a workflow (if state equals X, assign to Y) rather than a single native "territory" object, which is why they get harder to maintain as the list of conditions grows. A territory list with forty rows is a maintenance job, not a one-time setup.

3. 3.
   Account-based

   When a lead belongs to a company or contact that already has an owner in the CRM, the new lead goes to that same owner instead of into the general rotation. Pipedrive documents two dedicated assignee types for exactly this: "Organization owner: if the lead or deal already has an existing organization linked to it, you can assign the lead or deal to the existing organization owner", and the same for "Person owner."

   This is the model that stops a second contact at an existing account from being assigned to a stranger while the rep who already has the relationship finds out a week later, from the customer, that someone new called them.

4. 4.
   Capacity-weighted

   Leads go to whoever has room, not whoever is next in line. HubSpot's own name for this is "Load Balanced: automatically evaluate and assign the record to the user with the least amount of open, assigned tickets." Salesforce documents the most granular version inside Omni-Channel, with two distinct models: "Least Active" routes to "the service rep whose work is consuming the smallest amount of capacity", and "Most Available" routes to whoever "has the greatest amount of available capacity." Salesforce's own worked example: a rep with 5 units of total capacity and 3 active items is treated differently from a rep with 10 units of capacity and 5 active items, even though the second rep has more open work in absolute terms, because their proportional load is lower.

   Capacity-weighted is the model that actually accounts for the fact that not everyone's open pipeline is the same size, which plain round robin ignores completely.

The catch-all rule every setup needs

Every routing setup eventually meets a lead that matches none of its rules: a territory nobody defined, a round robin pool with every member marked away, a rule that references a user who left the company. What happens to that lead is a decision, and it is either made on purpose or made by accident.

Pipedrive names the accident version directly. Its automatic assignment tool has a tab literally called "Not assigned", where a lead sits when no rule could place it. HubSpot's documentation describes the same outcome in different words: "If there is no eligible user to rotate to, or if no team is selected for team-based assignment, no owner will be assigned." Neither vendor treats this as an error state. It is a normal, expected output of the system, which is exactly why it needs a rule of its own rather than being left as a silent default.

A working catch-all names, in order: who gets a lead nothing else matches, and who is told when that happens. Without the second part, the first part is invisible until someone thinks to go and check the unassigned tab, which by definition nobody was watching.

Where leads get stuck

Across the three vendors whose failure documentation could be read directly, the same three failure shapes appear, described in each vendor's own words.

No eligible owner. The rule fires, but there is nobody left to give the lead to. HubSpot: "no owner will be assigned." Pipedrive documents this from two directions depending on the rule type: "User not found, the user defined as assignee doesn't exist or is inactive" and "No user in the team, none of the users in the team defined as assignees were able to receive the deal or lead ownership."

The owner exists but is marked away. The rule finds a person, and that person is set to unavailable, so the lead is held back rather than delivered late to someone who will not see it. HubSpot again, on its "Assign to available users only" setting: "users that are set to Away will not be assigned records, even if they are configured in the assignment rules... If all users in the assignment pool are away, the [object] Owner... property will be set to unassigned."

The rule runs and nothing tells anyone. This is the failure that does not show up in any vendor's documentation as a named error, because from the system's point of view nothing went wrong: an owner was assigned, correctly, and no notification step was attached to the assignment, so the new owner finds out whenever they next happen to look. GoHighLevel's own setup instructions make the fix explicit by making it a separate step: assignment is one workflow action, notification is a second one, and the documentation is careful to note that "the Internal Notification Action" has to come "after the assign user action", because the two are not the same event. Skip the second action and routing still "works": the field just changes with nobody watching it happen.

None of these three is exotic. They are the documented, expected behaviour of the systems that do routing, not bugs. The fix for all three is the same shape: name what happens at the edge case, before the edge case happens on a real lead.

A worked example

A mid-market company runs HubSpot Sales Hub Professional with six reps on a shared team. Their setup, as it is actually built:

1. A form submission creates a contact and fires a workflow.
2. The workflow checks whether the contact's company already has a deal owner. If yes, account-based routing wins: the lead goes to that existing owner, full stop.
3. If not, the workflow checks a custom "Region" property against a branch of six territories. If it matches one, the lead goes to that territory's named rep.
4. If it matches none, most commonly because the lead came from a country outside the six defined regions, the workflow falls through to a "Rotate record to owner" action set to Round Robin across all six reps, with "Assign to available users only" turned on.
5. A separate, second workflow action sends an internal Slack notification to whoever was just assigned, tagging them directly rather than posting to a channel.

That is account-based, then territory, then round robin, in a stated order, with a working notification step attached to the fallback. The gap this team still has not closed: nobody has set up what happens if every one of the six reps is marked Away at once, which HubSpot's own documentation says will resolve to "(No owner)". At six reps that is a rare event. At two reps covering a smaller team, it is not.

Check your own setup

Three checks, each with the condition that means it fails.

Ask what happens when nothing matches. Open your routing rules and find the last one in the list. It fails if there is no last rule, meaning the tool's own default (often "no owner" or "unassigned") is the real catch-all and nobody chose it on purpose.

Ask who finds out when a rule can't place a lead. Check whether an unassigned or "not assigned" view exists in your tool, and who has looked at it in the last seven days. It fails if the honest answer is nobody, because a queue nobody watches is functionally the same as no queue at all.

Ask whether assignment and notification are the same step. In most workflow builders they are two separate actions. It fails if only the assignment action exists, because an owner field can change with no signal to the person it changed for, which is the least visible of the three failure modes precisely because the system reports it as a success.

If your setup passes all three, the next thing worth measuring is not routing itself but how fast the routed owner actually responds, since a lead correctly assigned in half a second and left untouched for six hours has the same outcome as one that was never routed.

Related terms

Lead assignment is used interchangeably with lead routing by most vendors; HubSpot's own workflow action is literally named "Rotate record to owner", not "route." Lead distribution is the same concept, more common in call-centre and insurance software. Speed to lead is the metric routing exists to serve, covered in full here. Territory management is the specific discipline of building and maintaining the geography or account rules that feed model 2 and model 3 above. None of these four terms describes a different mechanism. They describe the same mechanism from different vendors and different industries.

If your routing setup has never been tested end to end, that test is the place to start: submit one real lead through your actual rules and follow it until a person touches it.

If you want a second pair of eyes on your own setup, Salestruct runs a free diagnostic.