A process map is a written picture of how a piece of work actually happens, step by step. It shows where time is lost and where work gets dropped. You can make one with a pen and paper. This guide covers how, with two worked examples and a one-page template, what to look for once you have the map, and how to decide what to cut, fix or automate.
What a process map is, and what it isn’t
A process map lists the steps of one job, who does each step, and what happens between the steps. It is not a policy document or a software project, and it is not the process as it was designed. A useful map shows what runs today, including the workarounds and the “I always check with Sam first” steps nobody wrote down. If the map looks tidier than the work, it is not finished.
Choose the process to map
Do not map the whole business. Choose one process that touches a customer (an enquiry, a quote, a booking, an invoice), recurs often, and already feels slow or error-prone. Write one sentence naming where it starts and where it ends, for example: “From the moment a customer asks for a quote to the moment we hear yes or no.”
Map it with the people who do the work
The owner rarely knows every step. Sit with the people who do the work and ask them to walk you through the last real job, not “how it normally works”. Mapping is a team exercise: each person sees steps the others do not, so include everyone the process touches. Use one sheet of paper, keep blame out of it, and ask three things at each step:
- What triggers this step? An email, a call, a reminder, someone remembering?
- What is needed to do it? A form, a price list, an answer from someone else?
- What happens next, and how long until it does? This is where the waits show up.
Listen for “usually”, “unless” and “sometimes”: each marks a branch to write down. When you finish, read the steps back in order. Someone will object that a step is not quite right. That disagreement is useful, because it shows where the map and the work differ.
Write it down: steps, owners and waits
List each step on its own line, in order. Beside each, record the owner (one person or role) and the wait: how long the work sits before the next step starts. Write “nobody” where nothing triggers the next step. If a step can go two ways, draw a fork. That list is the map. You can turn it into a flowchart later, but the thinking happens in the list.
Want something to fill in? Our one-page process mapping template has columns for steps, owners, waits and leaks. Open the template, then print it or save it as a PDF.
Find the leaks
Go through the map with a pen and mark four kinds of problem:
- Waits. Work sitting still. This is often the largest cost, because it is time the customer spends wondering.
- Hand-offs. Each time work passes between people, something can be lost or misread.
- Rework. Steps repeated because information was missing the first time.
- Drops. Places where nothing triggers the next step, so the work continues only if someone remembers. These are the quiet leaks and usually the most valuable find: a drop often means a customer who asked and never heard back.
Cut first, then automate
Ask of every step: “What would happen if we stopped doing this?” Some steps exist because of a problem that no longer exists. Some are checks nobody looks at, or approvals that always say yes. Automating a disorderly process makes the disorder run faster and hides it from the people who could correct it. Give every step one label:
| Label | What it means | Ask yourself |
|---|---|---|
| Remove | Stop doing this step. | If we stopped, would anyone notice? |
| Simplify | Keep it, but shorter or clearer. | Can we remove a hand-off or a wait? |
| Fix the trigger | Make sure the step actually starts. | What makes this happen if nobody remembers? |
| Automate | Let software do it. | Does it recur, follow a settled rule, and cost little if it goes wrong? |
| Automate with sign-off | Software prepares it; a person approves every item. | Does the result need a human check before it goes out? |
| Keep manual | A person does it, without a system. | Is a mistake serious, or the judgment too fine for a rule? |
Several “Fix the trigger” labels mean work is being dropped, so start there. Our guide to what to automate first sets out three rules for choosing between the automation labels.
A worked example: a quote request
Say a small renovation company handles quote requests like this. A customer emails asking for a price. The owner reads it that evening, writes a quote the next day, and emails it. If the customer does not reply, nobody checks back.
| Step | Who | Wait before the next step | What we notice |
|---|---|---|---|
| Customer emails a request | Customer | Until the owner opens the inbox | Wait: nothing tells the customer it arrived |
| Owner reads the request | Owner | Until the next day | Wait: the quote waits behind the working day |
| Owner writes the quote | Owner | Same day | Rework risk: details missing from the request |
| Partner signs off on the price | Partner | Until they are free | Habit: does the sign-off ever change the quote? |
| Owner emails the quote | Owner | Nobody | Drop: nothing triggers a check-back |
Most of the delay sits between the email arriving and the owner reading it, not in writing the quote. A quote with no reply is never followed up, because nothing prompts anyone to. The partner’s sign-off may exist only out of habit: if it has never changed a quote, cutting it costs nothing. What is worth automating is reading and sorting the request, drafting the quote from the owner’s price notes, and a follow-up prompt after a set number of days, with the owner approving every quote before it goes out. Some of these fixes need no software at all, which is typical: the cheapest improvement is often a decision, not a tool.
A second case: an appointment-based business takes bookings by phone. When the front desk is busy the phone rings out, and the caller leaves no message. On the map, the first step has no trigger when nobody answers, so a missed call is a booking that never starts. The fix could be a return-call routine, a text to missed callers, or a system that answers and books. The map does not choose the answer, but it shows where the question is.
Paper first, diagrams later
Paper, a whiteboard or sticky notes are the best tools for a first pass: fast, easy to edit, and they keep the conversation on the work. Once the map is agreed, keep a clean copy where your team will open it again, such as a spreadsheet, a slide or a free diagramming tool. A simple flowchart is enough for a diagram. A swimlane version (one row per person) helps when hand-offs are the problem, and a network diagram, the kind project managers use, helps when the waits are the problem, because it puts the delay on the arrow between steps. Formal notations and value stream maps suit larger operations and will slow a first map.
Where first maps go wrong
- Mapping the ideal process. You will not find the leaks in how the work should run.
- Mapping alone. The people who do the work know steps you have never seen.
- Starting too large. Map one process, start to end, and add others later.
- Leaving out the waits. Most delay sits between the steps.
- Leaving the map in a drawer. Review it after a change, to check it did what you expected.
When the map needs an outside view
You can map a first process yourself. An outside view earns its cost when the process crosses several people or systems, when nobody agrees how it actually runs, or when you hold the map and cannot tell what is worth automating. If that describes your situation, the free Revenue Leak Report is a low-commitment way to get one.
