Section 20 · Sales Rep Work Elimination / Zero-Entry CRM
20.28Lost-reason cleanup
Built in the POC- No.
- 20.28
- DMA's reference
- Decision Book p.42
- Phase
- Phase 1
- Autonomy
- L1 · Recommend
- DMA's decision
- Yes
What DMA asked for · Decision Book p.42
Turn messy lost reasons into one clear code.
Why it matters to DMA: Reliable lost reasons are what the deal autopsy and better scoring rest on.
In our words, from DMA's Product Decision Book v3, page 42.
How we do it
- The same engine as 17.4: each lost deal's reason and notes are mapped to one code (price, timing, existing agency, no budget, competitor, poor fit, other), with the words it came from.
- No words, no code: "not enough evidence" instead of a guess.
- A code the AI is at least 80% sure of is prepared for the AI Lost Reason field in Nutshell. The write is held until DMA signs off the list of codes and the Phase 0 dry run; then it goes through the write gate like every AI write.
The flow
It plays on its own while it's on screen; hover or use the controls to pause or step through.
Messy
"$$ / went elsewhere".
- Nutshell
- AI
- Rule in code
Where the data goes
The same six stages on every page. Nothing reaches Nutshell except through the write gate.
- 1Nutshell
Source
Deals, contacts, tasks, activities, notes and users.
- 2Sync
Copies Nutshell changes into the bridge database
Keeps the mirror current, so the rules see today's state.
- 3Bridge database
A copy of the CRM data, plus what the AI works out
One open flag per record and problem, with its details and the rule version.
- 4AI
Claude models, only through DMA's own gateway
Not needed for most flags: they are rules. The audit adds what only the notes say.
- 5Write gate
The only way back into Nutshell: checked, approved when needed, sent once
Flags don't write to Nutshell; fixes happen there, by people (or through the write gate where a field rule allows it).
- 6Nutshell
The system of record
Reps fix the record; the flag closes on the next run.
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 |
|---|---|---|
| ai.extracted_facts | Facts the AI found, each with the exact quote it came from and a confidence. | 15 |
| ctrl.outbox | The write gate: each proposed Nutshell change, its approval and what it replaced. | 28 |
How the tables connect (2)
| Column | Points to | Kept by |
|---|---|---|
| ai.extracted_facts.prompt_id | agent.prompts | The application (by id) |
| ctrl.outbox.approval_id | ctrl.approvals | The database (foreign key) |
Worked example
Synthetic demo data: every name, business and number is made up.
Three messy reasons and the codes (synthetic data).
Lost reasons, cleaned
| In Nutshell | Code | Evidence |
|---|---|---|
| $$ / went elsewhere | Price | "chose a cheaper freelancer" (note, May 2025) |
| timing | Timing | "revisit after tax season" (note, Feb 2025) |
| ? | Not enough evidence | No note explains the loss |
In the running POC
A company in the Nutshell simulator after an approved AI write.
- 1The AI fields, written only through the write gate.
- 2The write in the company's timeline, marked as done by DMA AI.
CRM simulator (stands in for Nutshell) · one company record. 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 |
|---|---|---|
| Nutshell simulator | CRM simulator (stands in for Nutshell) | Open a company: the AI fields and the AI's entries in its timeline. |
Status
Built in the POC. This capability runs in the POC today, on synthetic data, end to end.