A routing setup that survives the next reorg

Most routing is built for the org chart on the day it’s written. Then someone splits a territory, a rep leaves, a segment gets added — and the rules break, leads misroute, and someone spends a fortnight patching. Routing that survives a reorg is built on roles and rules, not on named people and hard-coded assumptions. Here’s how, step by step.

Step 1: Route to roles, not names

Assign leads to a role — “enterprise AE, UK” — that maps to a person, rather than hard-coding the person. When someone leaves or moves, you update one mapping, not fifty rules.

The trap: embedding individual names or IDs throughout your routing logic. It works until the first departure, then it’s a scavenger hunt.

Step 2: Make territory a data-driven lookup

Define territories in one place — a table or property the rules reference — instead of writing the boundaries into each rule. Reorganise territories by editing the lookup, and every rule follows automatically.

The trap: duplicating territory logic across rules. Change the map and you’ll miss one, and that’s where leads start misrouting.

Step 3: Always have a catch-all

There must be a default owner for any lead that matches nothing. Not a queue that dies — a named role responsible for triage. This single rule prevents the silent-drop failure that costs the most.

The trap: assuming your rules are exhaustive. They never stay exhaustive; the catch-all is your seatbelt.

Step 4: Document the logic in plain language

Keep a short written description of how routing is meant to work, in words a non-admin can read. When the reorg comes, whoever adjusts the rules needs to understand the intent, not reverse-engineer it.

The trap: letting the only documentation be the rules themselves. Undocumented routing becomes untouchable, and untouchable routing rots.

Step 5: Review it on a trigger, not a whim

Tie a routing review to the events that break it — any headcount change, territory change, or new intake point. Make it a step in those processes, so routing updates by default instead of after something misroutes.

The trap: reviewing routing only when someone complains. By then leads have already leaked.

The principle

Durable routing is abstracted, centralised, documented, and reviewed on triggers. Build it that way and a reorg is a config change. Build it around today’s names and the next reorg is a crisis.