When the Lead-Routing AI Started Routing Leads to Nobody

A 14-rep sales team had a routing problem. Some reps got drowned. Some reps got nothing. The lead distribution was an "always-on" round-robin that didn't account for capacity, skill match, or current pipeline.

We built a smart router. It scored each lead, scored each rep's current load and fit, and assigned to the best match.

It worked great. Until a rep got laid off and we didn't update the user list.

What happened

The rep left the company on a Thursday. HR processed the departure on Friday. The CRM user account was set to "inactive" on Monday — but it wasn't deleted.

Our routing system had a list of active reps. The list was hardcoded into the workflow when we built it.

For the next three weeks, the router kept assigning the most "best fit" leads to the departed rep. Those leads sat in his queue. Nobody worked them.

We noticed because the VP of sales asked why pipeline was down 18% from forecast. We dug in. We saw 47 leads sitting in an inactive rep's queue.

Root cause

The routing system's rep list was static. The CRM's user roster was dynamic. The two didn't talk.

When I built the system, the firm had stable headcount. The static list was simpler and felt fine. I didn't anticipate (or didn't think about) departures.

This is a classic "the assumption that's true today won't be true forever" failure.

What we did instead

We rewrote the routing to pull the active rep list from the CRM directly at each invocation. No more cached list. Two extra API calls per lead-route. Worth it.

We also added a sanity check: if the assigned rep hasn't logged into the CRM in 7 days, flag the assignment for manual review. Catches both departures and reps on extended leave.

We added a Slack alert: if any rep has more than 8 unworked leads in their queue, ping the sales manager.

What I tell prospects now

Any system that depends on a list of people will eventually be wrong about the list of people. Build the system to pull the list dynamically. Build alarms for stale assignments.

The cost of the dynamic lookup is tiny. The cost of routing 47 leads into the void is large.

The lesson

Cached state is a foot-gun. Anything that should be dynamic and isn't will eventually drift.

Specifically: people lists, account lists, product lists, pricing — these all change. If your system has any of them hardcoded, you have a time bomb. The fuse length depends on how often the underlying data changes.

For our system, the fuse was about 90 days from build to first departure. Yours will be different. Don't measure it. Just build dynamically from day one.

The follow-up cost

Recovering the 47 lost leads cost the sales team about 3 weeks of catch-up work. We reached out apologetically. We re-engaged about 60% of them. Pipeline recovered.

The reputation cost was harder to measure. Sales reps who'd watched leads disappear were skeptical of the system for months. We had to rebuild trust by being conservative with subsequent automation and over-communicating about how the system handled edge cases.

A 6-line fix would have prevented all of it.