We build the system, then the demand that fills it.

Most process automation fails in the same place. Not the sending — the deciding. Anyone can generate a thousand emails. The hard part is knowing, for each one, who is supposed to receive it, and being able to prove that answer is right before a single message leaves the building.

The problem

The client, Follett, chases open purchase orders every week. Someone runs a report, works through it, and asks the stores with outstanding orders what happened to them.

The version we inherited did work. It also took 31 minutes to complete a run, because it wrote back to the source system once per purchase-order line, and there are a great many lines.

The deeper problem was direction. The report went up the management chain rather than out to the stores, so the person who could actually resolve an open order was not the person receiving it.

The constraint

Two rules were fixed before any code was written, and neither was ours to relax.

No per-PO-line writes anywhere. The 31 minutes were not a performance nuisance to be tuned later; they were a design verdict on the previous architecture. The rebuild was not allowed to write per line at any point, which ruled out the obvious implementation and forced the run to be shaped around bulk reads and a single queue row per run.

Every email goes to one test address until the client flips the switch. The real recipient is computed for every message, shown inside the body of that message, and then deliberately not used. The system runs at full scale against real data and delivers nothing to a real store until a person makes that decision explicitly.

That second rule is the one worth stealing. It means the question “does the routing work” gets answered by looking at a thousand real messages, not by trusting a diagram.

What was built

A routing layer, then a run engine on top of it.

The routing layer resolves, for every store, which named person owns it — and refuses to guess. The directory it was built against holds 1,074 stores, of which 826 carried a routable marker when the phase-1 data gate was measured, alongside a 162-person responsibility chain.

Only 50 of those 162 people had a verified contact status at that same gate. The gate required at least 50 and logged the actual figure, which was exactly 50 — so it passed on its floor, with no margin. That number is in this case study because it is where the work started, not where it finished: by handover the chain stood at 153 known of 162, with one probable and eight people confirmed to have left.

Every gate in the build worked the same way: a pinned expected value, the actual value measured against live data, and a halt if the two disagreed. One of them did disagree — a file-size assertion that could never have been satisfied, because the platform rewrites the file on upload. The build stopped rather than proceeding past a failing check, the assertion was rewritten to test the thing it had actually been trying to prove, and the revised criterion was approved by the plan’s author before the run continued.

What it produced

A weekly sweep of 909 stores, in which every store has a resolved destination.

The headline is the one number that moved furthest. 248 stores could not be routed to an owner when the data gate was measured. At handover that number is zero, and 881 stores reach a named person, up from 826.

That did not happen by loosening the rule. It happened by working the exceptions one at a time, and the breakdown is the part worth reading.

55 of the 248 had a market leader or a regional manager recorded even though the store-level owner was blank. Those were routed to the manager who already owned them, which is the whole of the 826 → 881 movement.

193 had nobody at any of the three levels — not a missing address, a missing owner. Those were classified by what the store actually sells: 28 sell course materials and now receive their own report at the store’s own mailbox instead of via a manager who does not exist, and 165 do not sell course materials at all and are excluded from the sweep entirely rather than being mailed something irrelevant every week. That exclusion is why the sweep covers 909 stores and not 1,074.

Classification was not done by keyword alone. The obvious cases went by category, and the 101 stores that were not obvious were researched individually against store and university websites, with the finding and its source recorded per store. It changed real answers: two of them turned out to sell course materials despite having no owner assigned at all, and one was excluded on the client’s own rule that online book sales generate no purchase-order follow-up — an online-only textbook brand that no longer trades.

Routing them is not the same as fixing them, and the difference was written down rather than smoothed over. 21 of those ownerless stores are still trading and still have nobody at any level — not a separate group, a named subset of the 193 above — and they went back to the Store Directory owner as a list, each with its retail market leader and regional manager as a starting point. They are routed today and they are still a data problem, and the data problem belongs with the people who own the data.

Those 21 stores also surfaced a hole nobody had asked about: because the app resolves a runner’s scope by matching against the store’s own manager fields, a store with all three fields blank matches nobody and cannot be selected from the interface at all. Picking it by hand is not a fix either — if no one owns a store, no one thinks to select it. So the ownerless stores ride along automatically on every full run instead.

None of this was accepted on the strength of a spreadsheet. The routing columns were written to the live directory and then read back to check them — all 1,074 rows populated with no errors, no blank routing decisions, no store queued to send without a destination, and no address outside the client’s own domain.

Where it stands

Delivered and handed over, still in test mode. Every one of those 909 stores has a computed destination, and not one of them has been emailed, because the switch that turns real delivery on belongs to the client and has not been flipped.

If your process looks like this

You have one of these if a weekly report gets run by a person, read by a person, and turned into messages by a person — and if the answer to “who should get this one” lives in somebody’s head rather than in a column.

The work is rarely the sending. It is establishing that the routing is correct, in writing, before anything sends. That means a directory that can be checked, a rule for every case the directory cannot answer, a named list of the cases no rule can answer, and a switch that keeps the whole thing pointed at a test inbox until you personally decide otherwise.