Lead routing breaks the first time someone's out

Lead routing setups almost always get built the same way: someone sits down, maps out who should get which kind of lead, and wires it into the CRM. It works, because it's tested on a normal day — the day it was built, when every person in the rule is actually at their desk. The rule gets trusted after that, and nobody looks at it again until a lead sits unclaimed for three days because the person it was routed to was on leave and nobody else knew it had landed.

Every rule needs a fallback, not just an owner

A routing rule that sends a lead to one specific person is really a routing rule with a single point of failure. The fix isn't complicated — a backup owner, a shared queue it falls into after a set time unclaimed, or a round-robin among two or three people instead of one — but it has to be decided up front, not improvised the day someone's out. If your current rule can't answer "what happens to this lead if the person it's assigned to doesn't open it today," that's the gap to close first.

Decide what "unavailable" actually means in the system

Most CRMs don't know someone is out unless you tell them, and "I'll remember to update it" is exactly the step that gets skipped during an actual absence. Pick one mechanism and make it real: a status toggle someone flips before they leave, an out-of-office calendar sync the routing checks against, or a simple rule that reroutes anything unopened after a few hours regardless of who's technically assigned. The specific mechanism matters less than having one that doesn't depend on a person remembering to update a setting while they're already distracted by being away.

Log every reroute so a lead can't disappear quietly

The failure mode that actually costs you a customer isn't a lead that gets routed to the wrong person — it's a lead that gets routed, sits, and nobody ever finds out it sat. A visible log of where every lead went and when it was first touched turns a silent failure into one someone can catch the same day. This doesn't need a dashboard; a simple record anyone can scan is enough. The point is that "it went somewhere" and "someone saw it" are different claims, and only the second one matters.

Revisit the rule when the team changes, not just when it breaks

Routing rules rot quietly as a team changes shape — someone new joins, someone's territory shifts, someone who used to cover overflow stops being available for it. None of that triggers an obvious signal that the rule needs updating, so it keeps running on an org chart that's already out of date. Put a standing reminder on the calendar to check the routing logic against who's actually on the team now, the same way you'd review any other process that depends on current staffing.

None of this is about building something more elaborate. It's about building the version that still works on the day it's actually needed — when someone's out, when the team's shifted, when nobody's watching closely — instead of the version that only ever got tested on a good day.