How to map a process before you fix it

Before you can improve a process, you need to see it. Process mapping is the practice of writing down every step a piece of work goes through, who does it and what tools are involved. It sounds tedious. In practice it is often the single most useful hour a team spends, because it shows problems that everyone half-knew about and nobody had written down.

Why map first

When something goes wrong, the natural reaction is to fix the step where the problem showed up. Often the cause is earlier. An order ships late because the warehouse was waiting on a payment confirmation, which was waiting on someone checking an inbox. Without a map you fix the warehouse.

A map also gets everyone looking at the same picture. People who do different parts of a process often have very different ideas of how the whole thing works.

Before you start

Choose one process

Pick something with a clear trigger and a clear finish. Good examples:

"A new client signs" to "the client's project kick-off meeting is booked"
"A customer places an order" to "the order is delivered"
"A job is finished" to "the invoice is paid"
"A new hire accepts the offer" to "they can do their job on day one"

Avoid mapping "marketing" or "operations". Those are areas, not processes.

Get the right people

Include at least one person who does each part of the work. The owner or manager should be there to listen, not to describe how they think it works. If someone outside the business is involved, such as a bookkeeper or a supplier, ask them about their part separately.

Pick a format

You do not need special software.

Sticky notes on a wall work well in person, because they are easy to move.
A spreadsheet with one row per step works well remotely.
A whiteboard tool (Miro, FigJam, Lucidchart and similar) is useful if you want something to keep and share.

Mapping the process

Write the trigger and the end point. Put them at the start and the end of the wall or sheet. Everything you map sits between these two.

List every step in order. Ask "what happens next?" over and over. Write each step as a short verb phrase: "send welcome email", "create folder", "check stock". Include the small steps people forget to mention, like "copy the details from the email into the spreadsheet".

Add who does each step. Use a role or a name. If the answer is "whoever is free", write that down. It is a finding.

Add the tool or place. Note where each step happens: email, the CRM, a shared drive, paper, a phone call.

Mark the decisions. Where the path splits ("is this a new customer?", "is it in stock?"), show both branches.

Mark waiting. Between steps, note where work sits and waits for someone. Waiting is usually where most of the elapsed time goes.

Walk it once with a real example. Take a recent order or client and trace it through the map. Fix anything that does not match what happened.

A simple spreadsheet layout

If you use a spreadsheet, these columns cover most needs:

Step	Who	Tool or place	Typical wait before next step	Problems seen
Customer submits enquiry form	Customer	Website	Until someone checks the inbox	Enquiries sometimes missed
Reply with availability	Office manager	Email	Same day	Different replies from different people
Send quote	Owner	Word template	Often several days	Quotes wait for the owner

Marking the pain points

Once the map is complete, go back over it and flag:

Handoffs with no clear owner. Any step where the answer to "who?" was vague.
Re-keying. Information typed from one system into another by hand. These are good candidates for automation.
Rework loops. Places where work goes back a step because something was missing or wrong.
Long waits. Especially waits for one specific person.
Steps nobody can explain. Sometimes a step exists because of a problem that was solved years ago.

Then read Finding the bottleneck to decide which one to tackle first.

Common mistakes

Mapping the ideal. If you draw how it should work, you will miss the workarounds that keep things running today, and your fix will break them.
Too much detail too soon. Start at the level of steps a new hire would recognize. You can zoom in on a problem area later.
Mapping alone. One person's view always leaves gaps.
Stopping at the map. The map is a means to an end. Agree on at least one change before the session ends.

Frequently asked questions

How long does mapping take?

For a typical small-business process, an hour or two with the right people in the room is usually enough for a first version. Complex processes with many branches can take longer, and it is fine to split them up.

Should we use a formal notation like BPMN?

Not unless you need it. Formal notations help when a map will be handed to developers or auditors. For deciding what to fix, plain boxes and arrows are clearer for most people.

What do we do with the map afterwards?

Keep it somewhere the team can find it. It becomes the starting point for your SOP. See Writing SOPs your team will actually follow.