Design Routing, Availability, and Fallbacks
Write routing rules for existing owners, eligible teams, unavailable reviewers, unassigned queues and failed downstream actions.
What you will complete
Complete a routing matrix with precedence, owner, destination, response target, fallback, deduplication and monitoring.
Set routing precedence
Start with relationships and restrictions before load distribution. Check do-not-contact status, duplicates, existing customers, open opportunities and account ownership. Then apply offer, geography, specialization and availability rules. Use round robin or load balancing only after the eligible pool is correct.
Write whether an existing owner is preserved or overwritten. The answer may differ for an account relationship and a new lead record. An owner field is not enough; record the assignment time, reason, model version and next action.
Every non-sales outcome also needs an owner. Nurture, referral, enrichment, decline and later review are operating paths, not disposal bins.
Design the fallback chain
| Condition | Primary route | Fallback | Evidence to monitor |
|---|---|---|---|
| Existing owner | Preserve relationship owner | Named backup if unavailable | Owner and reason retained |
| Eligible reviewer available | Apply approved distribution rule | Queue owner | Assignment and notification |
| Everyone away | Visible unassigned queue | Duty manager or backup owner | Alert and response timer |
| Assignment fails | Retry only under written rule | Failure review queue | Error, attempts and final state |
| Duplicate event | Preserve active record and owner | Manual merge review | No duplicate outreach |
“Unassigned” is a system state, not an operating plan. The queue needs a named watcher, alert, response target and escalation. Test the destination record after routing. A workflow run can report success while the notification or task creation fails downstream.
Worked example: Harborline routing
Fictional example: Harborline first checks customer and open-opportunity matches. Existing accounts stay with their owner. New priority-review MQLs route to the Ontario employer-training pool. Standard reviews enter a shared queue. Missing-data records go to revenue operations. Public-course requests receive a resource path owned by marketing.
If all sales reviewers are away, the lead remains visibly unassigned, the revenue leader receives an alert, and a response timer starts. If assignment succeeds but task creation fails, the system creates a failure record and alerts the queue owner. It does not repeat the assignment blindly.
A second form from the same company and request attaches to the existing review record. A different purchase request from the same company can remain a separate lead while preserving account ownership.
Complete section 5 of the workbook
- Order your routing checks from restrictions and existing relationships through qualification outcome and availability.
- For each route, name the destination, owner, response target and fallback.
- Define the all-away, unassigned, failed-notification and failed-write paths.
- State how repeated events and same-account opportunities are distinguished.
- List the fields and logs a reviewer must inspect after routing.
Keep vendor behavior out of business policy
Your CRM may support round robin, random assignment, load balancing or availability controls. Those features do not define your operating policy. Verify current product behavior and entitlements before implementation, especially when a feature is in beta.
The workbook captures the vendor-neutral decision. During technical discovery, map each rule to native configuration, an integration or a human queue. Add complexity only when the team can maintain the data and failure handling it requires.
Check your decision
1. Every eligible sales reviewer is away. What makes the route complete?
2. What should routing inspect before round-robin distribution?
3. Assignment succeeds but notification fails. What should the system do?
Return to Build a Lead Qualification and Sales Handoff System