Mapping a process is not a neat diagram but a list of who does what and what passes to whom. How to map a real process in two hours, and what to look for while you do.
Key takeaways
- Map what happens, not what is supposed to happen.
- The people performing it are the only ones who know where the workarounds are.
- What you are looking for is not steps but handoffs - that is where things fall.
- A map with no decision at the end is a tidy document nobody will open.
Mapping a process is not a project and needs no software. It needs a sheet of paper, two hours, and the people who actually perform the process - because the written process and the real one are nearly always different, and revealing that is exactly what mapping is for.
What exactly you record
For each step, record five things and no more:
| What you record | Why |
|---|---|
| Who does it | A step with no owner is a step that falls |
| What triggers the step | Exactly what makes it start |
| How long it takes | A rough estimate, not a precise one |
| What passes on, and how | This is where most faults live |
| What happens when something is missing | This answer is usually absent entirely |
The fifth row reveals the most. In most processes mapped for the first time there is no agreed answer to what happens when information is missing - which is precisely where everyone does something different.
How to run the two hours
- Pick one process and define where it starts and ends.
- Sit down with whoever performs it, not only whoever manages it.
- Go step by step and record the five items.
- Ask at every step what happens when it does not work.
- Mark handoffs between people or between systems.
- Finish with a decision - what changes first.
Step 2 is the difference between a real map and an imagined one. A manager describes the process as designed; the person performing it also describes the three workarounds built since.
Why handoffs are the important part
A process does not break inside a step but between steps. The moment somebody finishes their part and needs somebody else to continue is the moment things wait, fall, or get done twice.
So mark every handoff and ask three questions about it: how does the other side know it is their turn, how long until they start, and what happens if they do not. In a typical map, two or three handoffs explain most of the elapsed time - and the expansion of that is in finding the bottleneck in your process.
What to look for while mapping
- A step nobody can explain the purpose of - the first candidate for elimination.
- Information typed twice in different places.
- An approval that is always approved - a sign it is ceremonial rather than a control.
- A side spreadsheet somebody maintains to make the process work.
- A step depending on one person who knows something written down nowhere.
- Waiting - time in which nothing happens.
The last is the biggest in most processes: the time a process is "running" is usually time it spends waiting rather than time anybody spends working.
What it looks like at the end
Not a diagram. A numbered list on one page where each line says: who, what triggers it, what comes out, and where it goes. If it does not fit on one page, you probably mapped two processes rather than one - which is itself a useful finding.
What is worth adding is a mark against three things: where the long wait is, where the double entry is, and where things fall. Those three are the task list, and everything else is context.
It is also worth writing the date and who took part at the bottom of the page. That sounds unnecessary until the first time somebody asks in six months why something was decided, at which point that short line is the difference between an answer and a guess.
What to do with the map
A map with no decision after it is dignified time-wasting. The decision can be one of four: eliminate a step, merge two, simplify one, or automate it - and in exactly that order, because automating an unnecessary step preserves it forever.
After the decision, write the new process in the same format, one sentence per step, and put it somewhere visible. It is also the basis for a proper written procedure, as covered in writing SOPs for a small team. The wider sequence is in how to improve business efficiency.
How do you know the map is accurate?
One simple test: take three real cases from the past week and trace them against the map. If all three went through exactly the steps you recorded, the map is right. If one of them skipped a step or added a phone call that does not appear, the map describes the ideal process rather than the real one.
That happens in roughly half of first mapping attempts, and it is not a disaster. What matters is correcting the map rather than the case: the exception is telling you something real about the process, and it is often precisely the exception that generates most of the manual work.
A second useful test: hand the map to someone who did not help write it and ask whether they understand what to do. When the answer includes "but what if...", you have found a missing step - and it is exactly the step a new employee would get stuck on.
What to do with processes that cross people
Most processes in a small business cross two or three people, so mapping exposes a question nobody asked: who owns the whole process, as distinct from who owns each step. Without an answer, when something falls between two people neither of them is responsible for fixing it.
The solution is not a new hierarchy but one name against the process - whoever is accountable for the outcome happening, even when they perform few of the steps. That distinction is expanded in who owns a process.
Sources
Frequently asked questions
How many processes does a small business have?
Fewer than people assume - usually five to eight that cover most of the work: selling, delivering, collecting, purchasing, service, and onboarding an employee. You do not need to map them all; map the one that hurts and return to the rest later.
Do we need mapping software?
No. Paper, a whiteboard or a spreadsheet does the job better than a dedicated tool, because they do not divert the discussion into formatting. A dedicated tool suits businesses with many processes maintained over time, and that is a later stage.
Who should take part?
Whoever performs the process, and whoever receives its output. The second matters just as much: it often turns out they do not need half of what they receive, which is the fastest way to delete steps.
What if two people describe the process differently?
That is the most important discovery in mapping, not a problem. Two different descriptions of one process mean the process is undefined and its outcome varies by who performs it - which is exactly what has to be settled before going further.
Keep reading
Related service
MVP Development
Turn an idea into a validated product in weeks, not months.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.