In short
- Build cost is asymmetric: an hour spent mapping is cheap, a month spent automating the wrong step is not.
- Map the process as it actually runs, not as the SOP says it runs.
- MitHub's method has four passes: the money line → swimlanes → numbers → tag and find the constraint.
- The map is finished when it produces a build brief: one outcome, one constraint step, three numbers, one human gate.
Why the map is the cheapest part of the build
When building was expensive, teams mapped carefully because a wrong build cost months. AI made building cheap, and the discipline quietly disappeared. Now anyone can wire a workflow in an afternoon, so people skip straight to the tool and discover the process during the build, one surprise at a time.
The result is predictable. The automation works on the demo record and fails on the real ones, because nobody knew that 30% of records arrive without a phone number, that two teams both "own" the same field, or that the step everyone complained about was never the step holding the business back.
A map is cheap because it is made of attention, not code. It is also the only artifact that survives a change of tools.
Map the real process, not the official one
The first rule: the SOP is a hypothesis, not evidence. Written procedures describe the intended path. Real work contains the workarounds people invented to survive it.
Three ways to get the real version:
- Watch, don't ask. Sit with the person doing the work for one full cycle and write down every window they open, every copy-paste, every message they send to check something.
- Ask about the last exception, not the normal case. "When did this last go wrong, and what did you do?" reveals the branches nobody documents.
- Run the five-record test. Take five real records that finished last month and trace each one through your draft map. If any of them took a path the map does not show, the map is wrong. This is the single fastest way to catch a fantasy diagram.
Pass 1: the money line
Start at the end. Find the moment money changes hands and walk backwards: payment → decision → conversations → first contact → source. This is the method taught in Follow the money, and it exists to stop you from mapping activity that is busy but not connected to revenue.
Anything that does not sit on that line can still be mapped later. It just does not get automated first.
Write the line as a single row of boxes before you add any detail. If you cannot draw it in one row, you do not yet understand the process well enough to automate it.
Pass 2: swimlanes — who and what touches the work
Now redraw the same line with lanes. Give one lane to each person or role, and one lane to each system: the CRM, the form, the spreadsheet, the phone system, the inbox.
The lane convention is older than any tool you will use. The Object Management Group's introduction to BPMN, written by Stephen A. White, describes swimlanes as a way to organize activities into separate visual categories showing different functional capabilities or responsibilities, and defines two constructs: a Pool, which represents a participant and acts as a container, and a Lane, a sub-partition inside a pool used to categorize activities. BPMN itself is maintained by the OMG and is the de-facto standard notation for business process diagrams, designed to be readable by the people who run the process and precise enough to translate into software.
You do not need formal BPMN. You need what lanes force you to see: handoffs.
Count them. Every arrow that crosses a lane is a place where work stops, waits for attention, and loses context. In most revenue processes, the number of handoffs predicts the delay better than the number of steps does. Giving systems their own lanes also exposes the second failure mode: the same piece of data living in three places with no agreed source of truth.
Pass 3: put numbers on every step
A map without numbers is a picture. A map with numbers is a diagnosis. For each step, fill in five cells:
| Column | What it means | Why it matters |
|---|---|---|
| Volume | How many times per week does this step run? | Separates the rare and painful from the constant and expensive. |
| Touch time | Minutes of actual human work, once started. | This is what automation removes. |
| Wait time | Elapsed time between the previous step finishing and this one starting. | This is usually where the real loss is. |
| Failure rate | How often does it produce a wrong or incomplete result and need rework? | Automating a step with a high failure rate scales the errors. |
| Owner + system of record | Who is accountable, and which system holds the truth for the fields touched? | Prevents two automations fighting over one field. |
The touch time versus wait time split is the oldest lesson in process work. The Lean Enterprise Institute defines value-stream mapping as diagramming every step in the material and information flows needed to bring a product from order to delivery, and its whole purpose is to make you see the sources of waste across the flow rather than optimizing one process in isolation, usually by drawing a current-state map before a future-state one.
In knowledge work, the pattern repeats almost every time: touch time is minutes, wait time is hours or days. If you only automate touch time, you shorten a small part of a long delay and the total stays roughly the same.
Pass 4: tag each step, then find the constraint
With numbers in place, tag every step using MitHub's R-J-A convention — Rule, Judgment, Approval — explained in What is AI automation?. Rules become plain logic. Judgment becomes an AI step with a structured, checkable output. Approval stays with a person, with the context prepared for them.
Then ask the only question that decides the build order: which step has the least capacity compared to the demand placed on it? That is the constraint. The Theory of Constraints Institute frames improvement as five focusing steps — identify the constraint, exploit it, subordinate everything else to it, elevate it, then go back to the start because the constraint will have moved. Strengthening any other link is, in their chain analogy, wasted effort.
Practically: the constraint is usually the step with the largest wait time × volume, not the step with the loudest complaints. Systems thinking for AI automation goes deeper into why.
The MitHub one-page process map
Everything above fits on one page. This is the template.
| Field | Your answer |
|---|---|
| Outcome this process produces, as a number per week | |
| The money line, in one row of steps | |
| Lanes (people + systems) | |
| Handoff count | |
| Step with the highest wait time × volume | |
| R / J / A tag per step | |
| Source of truth for each field touched | |
| Where a human must decide, and why | |
| The three numbers you will watch after the build |
A worked example (hypothetical)
Imagine a company that signs about 20 new clients a month and has a messy post-sale onboarding. The map, after two mornings of watching:
- Contract signed in the e-signature tool. Volume 20/mo, touch 0, wait 0.
- Salesperson messages operations "new client". Sometimes. Failure rate: 1 in 5 never gets sent.
- Operations creates the client folder and account by hand. Touch 25 min, wait up to 3 days.
- Operations emails the client a questionnaire. Touch 10 min, wait 0.
- Client replies with partial answers. Wait 6 days average, failure rate high.
- Operations chases the missing fields. Touch 15 min, repeated 2–3 times.
- Kickoff call scheduled. Wait 4 days.
Seven steps, five lane crossings, roughly 50 minutes of touch time and around two weeks of wait time. The instinct is to automate step 3, because it is the most obviously manual. The numbers say otherwise: the constraint is step 5, the incomplete client reply, which drives the rework in step 6 and the delay in step 7.
So the build brief writes itself: a structured intake form with required fields instead of a free-text email, an automated reminder loop, and a trigger from the e-signature event so step 2 stops depending on somebody remembering. Step 3 gets automated too, but it was never the thing holding the business back.
Note what mapping bought here: the cheapest fix, found before anyone chose a tool.
Five ways a map lies to you
- It shows only the happy path. Exceptions are where automation breaks. Draw at least the top two.
- It uses averages. "Two days on average" can hide a tail of two weeks. Ask for the worst case as well.
- It maps roles, not systems. If systems have no lanes, data problems stay invisible.
- It was drawn from memory in a meeting. Maps made without watching the work are consistently wrong about wait time.
- It is never updated. A process map is a living document. Re-walk it after every build, because your own automation moves the constraint.
Before you build: the build brief
The map is not finished when it looks complete. It is finished when it can produce these six lines:
- Outcome: what this process should produce, per week, as a number.
- Constraint: the one step we are attacking, and the evidence.
- Scope: the steps we are touching, and the ones we are deliberately leaving alone.
- Data contract: the fields involved and the system of truth for each.
- Human gate: where a person approves, and what they see when they do.
- Proof: the three numbers we will compare before and after, and when we will check.
If you cannot write those six lines, you are not ready to build. That is a useful outcome, not a failure — it is exactly the diagnostic work described in Diagnose.
Where to go next
Mapping is the skill that separates someone who operates tools from someone who designs systems — the Director-to-Designer move in MitHub's capability ladder. Once your map is honest, the next question is whether you are automating the old process or redesigning it: that is the subject of AI-first workflows. And if you want to practice this on real revenue processes, start with the Revenue Reverse Engineering faculty.