The engine map · 21 August 2026 · for Ken and Dil
Four engines, drawn as one map. Two of them run. Two of them are on the website, are being sold, and do not exist. This is the page to sit in front of.
Start here
“Echo Desk was something completely different. It showed you how to run the engines — the referral engine for agents, the nurturing engine for clients, and the reputation engine, which we have as number one. It went through every bit of those, and we built those out. I actually have seen them. So the question is, where are they?”
Ken, 20 August
They exist — as sales copy, not as a build. The engines are
written out in three places: resources/james-kb/booked-solid-system.md,
resources/parker-kb/parker-knowledge-base.md, and the four public pages
at bookedsolidinspector.com/engine-1-reputation.html and its siblings.
They carry real specifics — the six agent tracks, the three-touch dormant campaign on
days 1, 4 and 7, the twelve-month one-a-month client sequence.
Ken’s own four questions — “What does that say? When do things go exactly? What content is going to be sent?” — have no answers anywhere in this repo for Engines 2 and 3. The shape was built and sold. The words were not. That is the gap, and it is not an engineering gap.
And what Dil produced this week was the booking flow and the onboarding flow, which are two different documents. Ken accepted them — “two good things” — then said this is the one he actually asked for.
Figure 1
One customer, one agent, left to right. Solid lines fire today. Dashed red lines are sold and do not exist.
| Engine | Who it works | State today | |
|---|---|---|---|
| 1 | Reputation — the job you just did | The customer, booking to review | Runs four messages, all live |
| 2 | Agent — the referral relationship | The buyer’s agent | Sold · nothing exists |
| 3 | Retention — the client after the job | Past clients, incl. every imported list | Sold · nothing exists |
| 4 | Conversion — the call that would have been missed | Anyone who rings | Josh runs failover needs a doc per client |
Figure 2
Trigger: Josh books a job. Six messages on one clock. Five of the six are email; the only text in the whole system goes to the inspector.
“So we personally don’t [text homeowners]. We personally don’t, but on behalf of the client, we will offer a text for a review request. Once. Then it goes to email the second one. So one request on text and one on email.”
That is a change to a published promise. The site carries a section headed “We do not text homeowners” and Terms §17 says “We text subscribers only.” Ken’s answer: “if we need to update anything, we’re gonna need to update something.”
Three things, in this order, before a line is written:
The consent trail itself already exists: Josh asks every caller and it prints on the work order.
Review-request texts that inspectors’ past customers have already received came from their own ISN or Spectora, not from us — and that is precisely Ken’s reason for keeping imported clients out of Engine 1: “that’s already happened in the ISN system or the Spectora system.”
Nothing in this repo can text a homeowner today. The one code
path that could was deleted on 20 August, and
test/no-homeowner-sms.test.mjs now allow-lists every file permitted to
send a text and names who receives it — a new one fails the suite. So “already
solved” is true of the wording for imported clients; it is not yet true of
the text-first review request, which needs the three steps above.
Figure 3
Roughly eight in ten inspections come from agent referrals. This is not a nice-to-have; it is where the business comes from.
api/ghl/inspector-read.js sorts every agent into a
track from their own booking history — no tagging, nobody remembering. The portal
even prints the list, under “Who has gone quiet”, with phone and email.
It reports, and nothing fires.
An automated “we miss you” is the most obviously automated message there is. “Sarah hasn’t sent you a job in three months — here’s her number” is a person noticing. That distinction is the product.
Figure 4
One touch a month, for twelve months. And the fork Ken drew on the call, which is the whole engine.
“Prior clients and new clients. New clients are ones that are scheduled by Josh — they get Engine 1 and work all the way through. Prior clients are uploaded lists.”
Ken, 20 August
An imported client now carries the tag Engine 3 alongside
Prior Client and Imported. It is a route, not a
block — nothing today could send them a review request, because that fires
off a completed job and an imported row has no job. The tag is the hook this engine
reads when it exists.
Ken named Engine 3 for prior clients. He has not said where a prior agent starts. Engine 2 is the obvious parallel, which is exactly why it has not been assumed — a test fails if anyone adds it quietly.
The eleven-month builder warranty reminder. A new-build warranty runs out at twelve months. An email at eleven — “your builder’s warranty ends next month, want us to look before it does?” — is a job the customer is grateful for, and it books a paid re-inspection. We already know who bought new construction, because Josh asks.
Figure 5 · the correction that keeps being made
Both numbers moved this month, in opposite directions, and both are now twelve. Confusing them changes what gets built.
Engine 4
Josh answers, qualifies, quotes, books, and files the work order, the call transcript and later the report onto the same CRM contact.
If our stream ever fails, the call is passed to the client’s own mobile. Proven against a dead host on 8 August — TeXML carried past the failed connect in 4 milliseconds and the second leg connected.
It is per client by design, and it needs the backup number from their onboarding form. Neither Chad nor Ted has submitted one, so there is nothing to switch on. It is a form to fill in, not engineering.
Engine 4 must never promise a backup to a client whose document is not uploaded. Not because the design is unproven — because a document that does not exist cannot answer a call.
What the Whimsical page has to answer
Each engine gets one column. Each column answers all four. A column with a blank in it is the work.
And one question Ken asked separately, which decides whether this is generic or good: a client in Nashville — “would the information going to the agent be something about what’s going on in the Nashville real estate market?” We know AI can localise it. Nobody has decided whether it should.
Ken, plainly: “We don’t want to do the Echo Desk. We created our own from Echo Desk.” And, earlier the same evening: “Like EchoDesk had that nice layout of the procedures for Sean Bacon… so that you and I can sit down and say, okay, this works, this works.”
Build something like it. Do not run it. We copy the layout — modules on one page, drawn so a non-technical person can follow it, and built to be argued with. We copy none of their sequences, timing, words, or any integration with them.
The honest summary
| Owed by | What | Size |
|---|---|---|
| Ken | Twelve agent emails and twelve client emails — one a month, each. This is the whole bottleneck and it cannot be delegated: nobody else writes in his voice, or knows what an inspector should say to an agent in March | The job |
| Ken | Where a prior agent starts. Engine 3 is ruled for clients only | One sentence |
| Ken | Whether agent content is localised to the client’s market | One sentence |
| Ken | The review-request text — his ruling, plus §17 and the carrier registration | A ruling, then two changes outside the code |
| Ken + Dil | An hour on Whimsical with this page | A sitting-down job |
| Engineering | A repeating monthly job · an action fired on agent standing · the eleven-month warranty trigger | Days, not weeks — and the agent one is close to free, because the detection already runs |
The engineering is small and it is nearly all detection we already do. The words are the job, and they are Ken’s.