The map is the deliverable

There is a moment in almost every engagement where the room goes quiet. It is not when I show a tool, and it is definitely not when I show a slide. It is when the process the company runs on — the one that lives in six heads and two spreadsheets — finally exists on one page, and everyone can see it at the same time.

That page is the bottleneck map, and I have come to believe it is the actual deliverable. Everything else — the roadmap, the requirements, the vendor pick, the pilot — is downstream of the room agreeing on what happens between “order comes in” and “invoice is paid.” The map is not the preamble to the work; it decides whether the rest of the work is aimed at anything real.

Why the official version is fiction

Every company has an official version of its process. It lives in an onboarding document nobody has opened since the onboarding. The real version has an export to Excel someone is quietly proud of, an approval that waits for a specific person’s Tuesday, and one step only Dana knows how to do. Software bought against the official version automates the fiction. That is why the tool “didn’t work” — it worked fine; it was pointed at a process that did not exist.

The official version is not dishonest — it describes the process as designed. Nobody logs the drift that starts the week after go-live, and the drift is what you are buying software to fix.

What actually goes on the page

The notation matters less than people hope, but four things have to be on the page.

Steps named from the thing moving through them. Not departments, not lanes off the org chart — follow one object: the order, the referral, the claim, the candidate. Boxes named after teams hide the handoffs, and the handoffs are where the map earns its keep.

Touch time and wait time, kept apart. Touch time is how long a step takes while somebody is doing it; wait time is how long work sits before the next step. A slow process can contain long waits around short tasks, but the balance needs measuring. Look at the handoffs as well as the tasks before deciding where to intervene.

Who touches it and where the truth lives. A name or a role at every step, and the system, spreadsheet or inbox holding the record there — and write the inbox down when it is genuinely the inbox.

What breaks, and roughly how often. Not a risk register, one sentence: “about one in ten arrive with the wrong code and go back.” Rework loops are invisible in every process document I have been handed, and they are frequently the whole problem.

A worked example you will recognize

Here is an invented composite anybody in operations will recognize. A small distributor is certain its order process is broken, and the complaint is specific: orders take nine days. The team wants to replace the order system. The map takes forty minutes. An order arrives by email; somebody re-types it; it waits for a credit check one person runs in batches when they get to it; the warehouse gets a printed sheet, confirms by email, and somebody re-types the confirmation; invoicing runs on Fridays.

Add the two time columns and the nine days come apart. Touch time is under two hours. Wait time is everything else, and the largest pieces are the batched credit check and the Friday invoicing run — neither a step anybody complained about, neither needing software. The system the team wanted to buy would have removed the re-typing: ninety minutes of the nine days. Without the map you buy a faster version of the part that hurts; with it you change an invoicing schedule and get most of the nine days back.

The argument is the point

When the map goes on the wall, people argue with it. Good. The argument is the process being seen for the first time. Sales says the handoff takes a day; operations says three. Both are right, for different weeks — and now you know the variance, which is worth more than either number.

A step that takes one day or three depending on the week needs a plan for that variation. A promise based on the mean does not tell you the chance of missing it: that depends on the full distribution. Record a range and the conditions behind it, then choose a service target the team can test. The map can prevent a poorly aimed build; it does not guarantee a quarter of savings.

The second-order effect nobody warns you about: an honest map makes visible what individual people preferred invisible. The approval that waits on somebody’s Tuesday is now on a wall with their name beside it. Handled badly, that turns a process exercise into a performance review, and the next map you get will be the official version. The defense is a rule you state before drawing anything: the map describes the work, not the people.

What goes wrong on the first attempt

Too much detail. Sixty boxes is a document, not an instrument. If it does not fit on one page somebody can stand in front of, it gets read once.

Drawing it alone. A map assembled at a desk from interview notes is a deliverable; a map drawn in a room where people can interrupt is a diagnosis. If nobody corrects it, you have documented what people believe they do.

Drawing it as it should be. Nobody decides to do this; describing the mess feels like confessing to it. Draw the week you actually had, including the two exceptions that ate Thursday.

Mapping everything. One flow, end to end, chosen because it carries money or patience. A map of the whole business is a poster. It gets harder when work crosses systems and teams — a patient journey across three systems is the hardest version I teach.

Where AI fits, honestly

I get hired to do AI work, and the map is still where I start — because the map is what tells you whether AI belongs at all. A swivel-chair step wants an integration, not a model. An approval that approves everything wants a rule. A wait that is really a batch schedule wants a different schedule.

For a possible AI step, examine workload, consequences and evidence together. Frequent work can justify the cost of building and operating a model, but a rare, high-value task can matter too. A wrong answer may need a check that costs more than the task itself. Useful examples and a way to evaluate the result are essential. The map helps decide whether AI belongs in the feature at all.

Drawing first also protects the AI work that does belong. A model dropped into a process nobody understands gets blamed for the process: six weeks later the pilot is “inconclusive,” and the real finding — that the step in front of it was the constraint — never surfaces.

The honest objection, and the honest answer

The strongest objection is that none of this is new. Process mapping is decades old and has at least four competing notations. Fair — I am not claiming a method, I am claiming a priority. The heavy versions collapsed under their own ceremony; what survives is the cheap one: pencil, one page, forty minutes, no diagramming tool until it stops changing.

The better objection is we already know where our bottleneck is. You might. Write the guess in the corner of the page before you start, then check it against the finished map. If it was right, you spent forty minutes and gained a room that agrees. If it was wrong — usually in the wait-time column — you avoided buying the wrong thing.

How you know the map worked

Somebody corrected it. At least one box changed because a person who does the work said it was wrong. An uncorrected map is a map of the official version.

Everyone names the same first move. Not the same wish list — the same single step they would change first, for the same reason. That agreement outlives the page.

At least one wait has a number on it. Rough is fine. “Two to three days, worse at month end” turns a complaint into something you can measure a fix against, and it is where a metric that survives an argument starts.

It predicts something. Within a week or two a delay shows up exactly where the map said the slack was. That is when people stop treating the page as a consulting artifact and start deciding with it.

If you want the method, the bottleneck map lesson walks through drawing one, template included, free; the next turns a finished map into a running automation. The whole sequence is Find the automation worth building. If you want it done with me in the room, that is what the practice is for.

Try this

Pick one flow and sketch it from memory. Beside each step separate work time from waiting, and label estimates as estimates. Ask someone who does the work to correct it. Then check a few actual cases, including exceptions, before choosing the first change.