Automating inbound lead validation and routing
A fictional automation case. The process—stages, ownership and closure—is in the Process Architecture case; this one is only about executing the routing reliably.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01The outcome
Clear leads routed automatically; unclear ones stopped at a named review with the reason; every lead has an owner or a visible reason why not.
Routing rules are clear for most leads—but ambiguous geography, existing customers and missing owners make the automation guess.
Which routing decisions are deterministic, and where must the automation stop and ask?
Give every routing check a deterministic outcome and an explicit “when unsure” path, instead of defaulting to a catch-all queue.
Web forms from many countries create leads that must reach the right subsidiary and owner within minutes. Most can be routed by country and product line. Some cannot: the country field disagrees with the email domain, the company is already a customer, or no owner is mapped for a new region.
A form submission creates a lead.
- The lead has an owner, or is in review with a reason
- Existing customers reach their account owner
- Notification sent once
- Rerouting is recorded, not repeated
02The reality · current state
What the automation does today.
- Ambiguous leads are routed to a default queue nobody watches
- Existing customers are routed as new business
- A rerouted lead triggers the welcome sequence again
- Failed assignments are silent
- Re-running routing after a rule change reassigns worked leads
03Target steps
Each step with its mode, its actor and its guard.
- 01Validation
Required fields, consent and plausibility.
- 02Deduplication
Match against leads, contacts and customer accounts.
- 03Geography resolution
Country from form, domain and phone; agreement required.
- 04Subsidiary resolution
Country + product line → selling company.
- 05Owner assignment
Territory rule → owner; capacity respected.
- 06Notification
Owner notified once; SLA clock starts.
04Key dimension · Deterministic routing & designed uncertainty
Every check has an answer—including “not sure”
The deterministic outcome runs automatically. The uncertain one stops at a person, with the reason.
| Check | Deterministic outcome | When unsure |
|---|---|---|
| Validation | Automated Complete and plausible → continue | Human Implausible data → held, not deleted |
| Duplicate customer | Automated Known account → account owner | Human Probable match → match review |
| Geography | Automated Form, domain and phone agree → country | Human Disagree → regional review |
| Subsidiary | Automated Country + product line → company | Human No mapping → configuration owner |
| Owner | Automated Territory rule → owner | Human No owner or at capacity → team lead |
A default catch-all queue is not a routing rule. It is an unowned exception.
05Execution safety
If it can run twice, it is designed to run twice.
The submitter must not wait for routing, but routing must finish within minutes and be re-runnable.
- Routing key
- Lead ID + rule version
- Assign-once guard
- Worked leads are never reassigned by a rerun
- Reroute
- An explicit action with a reason; no welcome sequence again
- Unsure path
- Every check can stop in review with its reason
06Exceptions & recovery
Not every failure is a retry.
- Ambiguous geography ValidationSignals disagreeRegional review with the signals shownRegional sales operations
- Probable existing customer DuplicateMatch score in the review bandMatch review; no new-business routingSales operations
- No owner mapped ConfigurationTerritory lookup emptyTeam lead queue; configuration ticketConfiguration owner
- Assignment service slow Transient · retryTimeout on assignmentRetry with the same keyAutomation
07The trade-offs
Credible options, judged against these premises.
Round-robin to a default queue
One region, one product
Cost: Hides every uncertain leadManual triage for all leads
Very low volume
Cost: Slow response; rules everyone knows done by handDeterministic checks with declared review paths
Many regions and lines
Cost: Needs owners for each review path08The second layer
Questions that change the design.
Rule vs judgement
- What is deterministic, and what is judgement?
- What happens when geography is ambiguous?
- What happens with a duplicate customer?
Change
- How is rerouting handled?
- What happens after a rule change?
- Can the process safely re-run?
Visibility
- How is failed assignment surfaced?
- Who owns each review path?
- When does the response clock start?
09Decisions & outputs
What the work produces.
- 01Routing decision table
- 02Review paths with owners
- 03Assign-once guard
- 04Reroute action
- 05Failed-assignment view