Last week we published the Movers Playbook — the steps a moving company runs to own its lead flow instead of renting it from a broker. This week we automated the build behind it.
Here’s the problem we kept finding. A moving company gets a website. Separately, someone hand-writes a context.md file and pushes it so the chat agent has something to say. Same business, told twice, built twice, and usually drifting apart within a month. Then a human hand-publishes ten pages one at a time, hand-sends the monthly invoice, and a lead who fills out the quote form lands in a database row nobody reads.
Four separate manual steps. Four places for the business to fall through the cracks.
One fact set, two artifacts
We fixed the “told twice” problem first. There’s one fact set — MoverBusinessFacts: name, city, license (in California that’s a CAL-PUC/Cal-T number, not a USDOT — the playbook already covered why that distinction matters), pricing, reviews. Two functions read it:
MoverBusinessFacts
│
├─→ fills the site (10 pages)
└─→ fills the agent's context
Same rule both places: state only what the facts give. Never invent a service, a review, or a policy the mover didn’t tell us. The site and the agent say the same true things because they’re generated from the same source, not maintained by two humans trying to keep two documents in sync.
The workflow, end to end
That fixed what the mover gets told. It didn’t fix who does the work. This week we wired the whole thing as one workflow:
facts (form / URL / chat)
│
▼
build the site + fill the agent's context
│
▼
human review ── a person checks both before anything goes live
│
▼
publish everything, one call
│
▼
put the mover on the subscription ← money loop 1
Two pieces made this a workflow instead of a runbook. First, publishing: the site used to go live one page at a time — ten calls for a ten-page pack. Now there’s one receiver, pages:publish-pack, that flips every draft page for the workspace at once. Second, billing: the last step in the run is the mover’s monthly subscription, charged the same way any recurring plan on ONE gets charged. Nobody sends an invoice by hand anymore. It’s a step in the workflow that already ran.
What happens after a visitor shows up
The site is live, the agent can talk. Now a stranger fills out the quote form. Four more workflows carry that person from stranger to paying customer:
| Stage | What runs |
|---|---|
| A lead comes in | The form submit reaches the operator — an actual notification, not a row sitting unread |
| The quote firms up | A real Stripe deposit gets taken before the move gets scheduled — money loop 2 |
| Move day | Reminders before, a check-in after |
| After the move | A review ask, then a referral ask, a few days apart |
Both money loops reuse charge logic that already existed on the platform — the mover’s subscription and the customer’s deposit each call a receiver we’d already built and tested for other products. We added zero new ways to move money. We added the workflow steps that call the ones we had.
Built from what we already had
Nothing here is a new subsystem. pages:publish-pack is a thin loop over the single-page publish we already trusted. The five new workflow templates append to a catalog that already had thirty. The two money loops call the same billing and booking receivers other parts of ONE use today. The whole factory came together as connective tissue over primitives that were already load-bearing elsewhere — which is the point: the fastest way to ship a feature is composing four things you trust, not building a fifth from scratch.
Read the playbook, run the factory
The playbook told you the steps a mover has to get right — the pages, the listings, the reviews, the follow-up. The factory is what runs those steps without a human doing them by hand: one intake, a site and an agent that tell the same true story, published together, billed automatically, and every lead carried through to a booked, paid move.
Give your facts once. Everything downstream is a workflow now, not a to-do list.