Key takeaways
- Route on declared service location and eligibility before using inferred geography.
- Store event instants in UTC and the relevant IANA time-zone identifier for local operating rules.
- Define acceptance, expiry, fallback, holiday, and daylight-saving behavior before launch.
- Measure response and qualification by market without rewarding fast rejection or silent rerouting.
01
Eligibility comes before speed
The fastest assignment is still wrong if the team cannot sell, contract, or deliver in the requested market. Capture the buyer’s service location, language, product need, company type, and any hard eligibility conditions. Use inferred IP or ad location as context, not as a substitute for the buyer’s answer.
Write the route as a priority order: disqualifying rules, named-account ownership, territory, language or specialty, current capacity, and fallback queue. Each branch needs an owner and a reason code that remains visible in the CRM.
Swipe to compare every column
| Routing element | Required rule | Failure signal |
|---|---|---|
| Market | Declared service location and coverage | Frequent cross-territory reassignment |
| Clock | Business hours in a named time zone | Contacts sent during local night |
| Capacity | Open queue or weighted availability | Leads aging with an absent owner |
| Fallback | Expiry and next eligible queue | Silent orphan records |
02
Store an instant and a time-zone rule separately
RFC 3339 defines an interoperable timestamp format with a stated relationship to UTC. Use that for event instants such as form submission, assignment, acceptance, and first contact. Also store the IANA time-zone identifier that governs local business hours, because a numeric offset alone does not carry future daylight-saving rules.
Do not hard-code “US Eastern equals UTC minus five” or similar shortcuts. Political and daylight-saving changes can make them wrong. Use maintained time-zone libraries and test transitions, midnight boundaries, and regions without seasonal clock changes.
03
Design the handoff for weekends, holidays, and silence
Decide whether an after-hours lead waits for the local team, moves to a follow-the-sun team, or receives an automated acknowledgement without pretending a person has responded. Define market calendars, owner absence, queue saturation, acceptance timeout, and maximum reassignment count.
Automation should state what happened: assigned, offered, accepted, expired, rerouted, or held. A single overwritten owner field hides the route and makes response-time analysis unreliable.
04
Measure the journey in the buyer’s clock and the system’s clock
Keep raw UTC durations for reproducibility and report local business-time measures for operational fairness. A lead arriving Friday evening should not be compared blindly with one arriving Tuesday morning. Publish the calculation rule next to the service-level chart.
Review time to acceptance, business-time first response, qualification rate, opportunity rate, reroute count, and rejection reason by market and queue. Fast response is useful only when it reaches the right person with a service the business can actually provide.
Primary sources and further reading
Use the source material to validate details against your own context and current platform configuration.
- RFC Editor: RFC 3339—Date and Time on the Internet
- IANA: Time Zone Database
- Unicode CLDR: Date and time data
This field note follows the XenGrowth editorial policy: primary sources where available, visible limitations, material review dates, and no invented first-hand experience.
Stay with the problem
