PHASE 01
FOLLOW ONE LEAD.
WRITE DOWN EVERYTHING.
Every operations project starts here, and most of them skip it, which is why most of them fail. You cannot improve a process you have never seen written down.
The map you have is not the map you run
Ask an owner how a lead moves through their business and you will get a clean five-step answer. Lead comes in, someone calls, we qualify, we make an offer, we close.
Now follow an actual lead. What you find is closer to twenty steps, and about eight of them exist nowhere except in somebody's habits. The form notification goes to an inbox that one person watches. She copies the details into the CRM by hand because the integration broke in March and nobody fixed it. She texts the acquisitions person because he does not check the CRM until evening. He calls, takes notes on paper, and enters them later, sometimes. If the seller mentions a title issue he forwards it to you, and it sits until you read it.
The undocumented steps are the whole point of the exercise. They are where the delay lives, where the errors enter, and where the business quietly depends on one person's habits. They are invisible in the clean version precisely because everyone has normalized them.
Follow one lead and one job
Two traces, not a comprehensive documentation project. The scope discipline matters, because a full process library is a six-month endeavor that nobody finishes and a single trace is a week that changes what you do next.
- Pick one recent lead that went the full distance, and one job or project that was delivered. Real ones, with names attached, not representative examples.
- Start before the beginning. Where did it come from. What triggered the first action. Who saw it first, and how did they see it.
- Walk it forward step by step, asking at every point: what happened next, who did it, in what system, and how did they know it was their turn.
- Ask what happened the times it did not go smoothly. The exceptions are not noise. In most small businesses the exception path is where half the actual work lives.
- Keep going past the close. Invoicing, filing, handoff to delivery, whatever comes after. That tail is usually the least defined part of the whole thing.
The rest of the material, including the deal calculators and learning resources, lives on the main site.
Ask the people who do the work
This cannot be done from the owner's chair. You will produce the clean five-step version, because that is the version you designed and the version you believe.
Sit with the person who actually does each step and ask three questions. Walk me through what you actually do, not what the process says. What is the annoying part. What do you do when it does not go the normal way.
The second question is the most productive one in operations work, and the answers arrive immediately because people have been carrying these irritations for years without anyone asking. It is the most tedious thing I do, or I have to check two places because they do not match, or I usually just do it myself because explaining it takes longer.
One condition makes this work. People must be certain the exercise is not about evaluating them. Say it out loud, more than once, and mean it. If your team believes the map is being drawn to find out who is slow, you will get the clean version from them too, and the whole project is built on fiction.
Mark where it waits
When both traces are on paper, go back through and mark every point where work stopped moving. Not where someone was working on it. Where it sat.
This is the highest-value pass, because waiting is almost always the largest component of elapsed time and it is invisible in any normal view of the business. Nobody logs the four days a file sat in an inbox. The work itself took forty minutes.
Waits come in a small number of recognizable shapes.
- Waiting on the owner. An approval, an answer, a decision only you make. Usually the biggest single category.
- Waiting on a handoff nobody was notified about. The work is done, and the next person does not know.
- Waiting on information that exists in the business but not where the person needs it.
- Waiting on an external party — a lender, an inspector, a title company — with nobody assigned to chase it.
- Waiting on a batch. Nothing happens until Thursday because Thursday is when someone does that.
Each of those has a different fix, which is why naming the type matters more than counting the days.
What a finished map looks like
Not a flowchart in specialized software. Nobody opens those again.
A usable map is a plain document, one line per step, with four things on each line: what happens, who does it, what system it happens in, and what triggers it. Under each step, a note where the work waited and roughly how long. At the bottom, a short list of the exception paths.
If it runs to two or three pages for one process, that is right. If it is half a page you have written the clean version again and you should go back to the people who do the work.
The output you want from this phase is not a document. It is one sentence: here is the single place where the most work is waiting, and here is why. That sentence is what the next phase acts on.
Frequently asked
Questions people actually ask
How long should mapping take?
A week or two for one lead and one job, done properly with the people who do the work. If it is taking a month you have expanded the scope beyond two traces, and you will lose the team's patience before you get to any improvement.
Should I map every process in the business?
No. Two traces first, then act on what they reveal. A comprehensive process library built before anything improves is the most common way this work stalls out, because it produces no visible benefit for months.
What software should I use to map?
A document. Plain text, a shared doc, a whiteboard photographed afterward. Diagramming tools produce artifacts that look impressive and get opened once. The map is for use, not for presentation.
My team says the process is fine. Now what?
Follow an actual lead anyway. The gap between what people believe happens and what happens is not dishonesty. It is that everyone sees their own segment and nobody has ever watched the whole thing move end to end.
What if the process is different every time?
Then map the most common version and list the variations underneath. Genuinely bespoke work is a real category and a reason not to automate. Work that feels bespoke but has three recognizable shapes is the usual finding.
Who should run the mapping sessions?
Someone who can ask the same question five times without getting impatient, and who has no stake in the answer making anyone look good. That is sometimes the owner and often someone else.
Make your next move
A year from now, what will you be glad you started today?
You don't need another promise that everything will be easy. You need something useful to learn — and a next step you're willing to take.