Section 20 · Sales Rep Work Elimination / Zero-Entry CRM
20.22Automatic lead routing
Partly built — finishing in Phase 1- No.
- 20.22
- DMA's reference
- Decision Book p.40
- Phase
- Phase 1
- Autonomy
- L3 · Act within rules
- DMA's decision
- Yes
What DMA asked for · Decision Book p.40
Send each new lead to the right rep automatically.
Why it matters to DMA: Speed to lead wins deals; a lead that waits for someone to assign it goes cold.
In our words, from DMA's Product Decision Book v3, page 40.
How we do it
- Built: escalations are routed by a roster: each trigger (pricing request, asked for a person, hot lead…) has a first and second person, working hours and a response deadline; an unanswered case moves on.
- Built: a call booked from the website chat alerts its host and creates a prep task for them.
- Not yet: routing every new lead by territory, service or round-robin. That needs DMA's routing rules (who covers what).
Already in place
- Roster routing for escalations.
- Chat bookings to the host.
What the later phase adds
- Routing every new lead by DMA's own rules.
The flow
It plays on its own while it's on screen; hover or use the controls to pause or step through.
A case
A visitor asks for pricing.
- Person
- Rule in code
- Stored data
Where the data goes
The same six stages on every page. Nothing reaches Nutshell except through the write gate.
- 1Chat and e-mail
Source
Website chat, e-mail replies.
- 2Sync
Copies Nutshell changes into the bridge database
Not involved.
- 3Bridge database
A copy of the CRM data, plus what the AI works out
The case, its trigger, owner and deadline.
- 4AI
Claude models, only through DMA's own gateway
No AI model is involved: rules decide.
- 5Write gate
The only way back into Nutshell: checked, approved when needed, sent once
Alerts go through the send governor.
- 6Nutshell
The system of record
Nutshell is not changed.
The tables behind it
Drawn from the POC's database catalogue: structure only, no data.
PK primary keyFK reference the database enforces (solid line)ID reference kept by id (dashed line)
| Table | What it holds | Columns |
|---|---|---|
| ctrl.escalations | Cases handed to a person at DMA, with the reason and the response deadline. | 33 |
| ctrl.roster | Who handles each trigger, in what order, when, and how fast. | 10 |
How the tables connect (3)
| Column | Points to | Kept by |
|---|---|---|
| ctrl.escalations.conversation_id | conv.conversations | The application (by id) |
| ctrl.escalations.run_id | agent.runs | The application (by id) |
| ctrl.escalations.decision_id | ctrl.decision_log | The application (by id) |
Worked example
Synthetic demo data: every name, business and number is made up.
The POC roster (placeholders until DMA sets it).
Roster
| Person | Order | Hours | Answer within |
|---|---|---|---|
| Josh (President) | 1 | Mon–Fri 9:00–18:00 New York | 120 minutes |
| Sean (VP Sales) | 2 | Mon–Fri 9:00–18:00 New York | 120 minutes |
In the running POC
The escalation roster.
- 1A trigger, its person and response time.
- 2The backup.
Dashboard · Govern → Escalation roster. Captured from the running POC on September 25, 2026; synthetic data.
See it live
Opens the exact screen in the running POC, in a new tab.
| Open | Where | What to try |
|---|---|---|
| Roster | DMA AI dashboard | Who handles each kind of case. |
Status
Partly built — finishing in Phase 1. The parts run in the POC today; the rule that joins them is being finished for Phase 1.