Why letting the spreadsheet win is the pilot.

A senior dispatcher at Meridian Logistics carried the routing model for the east-coast fleet in his head and in a 60-tab Excel file. He had run the desk for eight years. Three previous internal-tools projects had tried to replace him; one made it to production, ran for six weeks, and was quietly switched off. By the time the brief reached us, the operations director's question had narrowed to a single line: can we put the model on a screen without losing the person who built it?

The answer is yes, but only if you let the spreadsheet win.

· 01The wrong frame.

Most internal-tools pilots fail because they start with the wrong frame. The frame is usually "replace the spreadsheet" or, more honestly, "replace the person who has been running the spreadsheet". Both framings cast the existing operator as the problem, and the build team as the solution.

This is wrong in two ways. First, the spreadsheet is almost always a working artefact of a working operating model. It encodes years of decisions, exceptions, and personal relationships with customers. Second, the operator is usually the only person in the company who can explain why the model works on a Tuesday but not a Friday.

It told me what I already knew and what I hadn't noticed. The model and I disagreed maybe one job in six. A. Lin · Senior dispatcher · Meridian · Week 12

Reframed: the pilot is not a replacement. It is a defensible second opinion the operator can present to their boss. The spreadsheet wins if it disagrees with the model and the model is wrong. The whole point of the pilot is to make those disagreements legible.

· 02The six rules.

Six rules followed from this frame, all of which we now apply on every Labs pilot.

One. Production data, day three. If the pilot is not running against the real database by the end of the first week, it is not a pilot — it is a demo. At Meridian we had the routing model scoring real, unassigned jobs by day three. Synthetic data hides the cases that matter; production data finds them on day four.

Two. Leave the rollback path live, in plain sight. The dispatcher's spreadsheet ran in parallel for the entire two-week pilot, on the same screen as the model. The button to fall back to it was the largest brass-coloured element on the screen. We did not hide it. We did not move it to a settings menu. The model had to earn its keep against a competitor the operator could pick at any moment, in one click.

Three. One screen. One operator. Every pilot has a named user. If we cannot name them, we do not ship. This is non-negotiable. The named user shapes the screen, owns the bug list, and signs the end-of-pilot decision. Three previous Meridian projects had built tools for "dispatchers" generally — none for A. Lin specifically. That was the difference.

Four. Refuse to bury the disagreements. Every job the operator scored differently from the model went into an audit log, with the reason, in the operator's own words. At Meridian, fourteen percent of jobs ended up there. That log was not a bug list — it was the model's tuition. By week two, we had a written record of every operating exception that mattered to the business. The spreadsheet had been carrying those exceptions silently for eight years.

Five. The end-of-pilot decision is binary, and signed. Invest, kill, or pass. No "let's extend it for another two weeks." If two weeks is not enough to know, the brief was wrong. We have killed two pilots in this format and passed one — and each kill saved more than it cost.

Six. Yours on day one. Code in the client's repo, infra in the client's cloud account, secrets in the client's vault. We work in their house. The pilot is theirs the moment it is committed. If we walk away on day fourteen, they keep the model, the tests, and the runbook — without negotiation, without a license agreement, without us holding the keys.

· 03What we still get wrong.

Two things, regularly.

First, we under-scope the audit log. Operators do not want a free-text box; they want a fixed set of reasons that map to the operating exceptions they already understand. Building that taxonomy is a two-day workshop we have learned not to skip. We skipped it at Meridian and re-did it in week eleven.

Second, we sometimes confuse "production data on day three" with "production decisions on day three." The model can score against live data immediately; the operator should not be obliged to act on its score for at least a week. We now write that distinction into the brief in two sentences, on the first page.

· 04A footnote on Excel.

Excel is not the enemy. Excel is the place where every working operating model in a mid-market business has been stored for the last twenty years. If you cannot articulate, in one sentence, what your tool does better than a 60-tab spreadsheet run by an experienced operator, you are not ready to build it.

A. Lin's spreadsheet retired itself in week ten, when he stopped opening it. The model had won, but only because we had spent two weeks letting it lose to a spreadsheet that knew its job.

N · 0 9  ·  E n d