Since 2009 I’ve mapped processes for government departments and universities, and the exercise is essentially the same for a twelve-person business. The scale changes. The method doesn’t.
It’s also the step people most want to skip, because it feels like paperwork standing between you and the useful part. It isn’t. It’s the thing that decides whether the useful part works.
Here’s how to do it in an afternoon.
Why it’s worth the time
Three things come out of a process map, and only one of them is the map.
You find out what actually happens. What people describe in a meeting is the tidy version. What’s written down after asking “and what happens when that fails” is the real one, and the gap between them is usually large.
You find work that should be deleted. Almost every process contains steps that exist because of something that stopped being true years ago. Deleting those is free and immediate, and you can only see them once the process is on paper.
You get something to check against afterwards. Without a before, there’s no way to tell whether the after is better.
The template
Six sections. Keep it to a page if you can.
Should you automate this?
1. Trigger
What starts this process? Be specific. “A customer enquiry” is vague. “An email arrives at the office address, or someone fills in the website form, or the phone rings during business hours” is three triggers, and they may need handling differently.
2. Steps, in order
Every step, with two things attached: who does it, and where it happens. The system matters as much as the person, because every change of system is a handoff, and handoffs are where time and accuracy leak.
Number them. You’ll be referring back.
3. Decisions
Wherever the process branches, write down what decides the branch.
This is the hardest section and the most valuable. Expect answers like “you just know” or “it depends”, and push past them. What does it depend on? Give me an example where it went one way, and one where it went the other. What was different?
Decision rules that live only in someone’s head cannot be automated, and getting them written down is often useful even if you never automate anything.
4. Exceptions
What goes wrong, how often, and what happens then.
The customer doesn’t reply. The file’s the wrong format. The payment is short. The job runs over. Someone’s on leave.
If the happy path is the only thing recorded, you’ll automate the easy half and leave a person doing everything hard. This section is what prevents that.
5. Volume and time
How often does this run, and how long does each step take?
You don’t need precision. Order of magnitude is enough: daily or weekly or monthly, minutes or hours. What you’re establishing is whether the process is worth spending money on at all, and that question is impossible to answer from feeling alone. A task that irritates you every time may run twice a month. One you’ve stopped noticing may run fifty times.
6. What “better” would mean
One or two measures. Time from enquiry to quote. Invoices needing correction. Hours spent on the whole thing per week.
Write them down before anything changes, or you’ll have no way of knowing later whether it worked, and you’ll end up judging the result on whether it feels nicer.
How to actually run it
Set aside two hours and follow the work rather than the org chart.
Start at the trigger and walk forward. Don’t jump to the interesting parts.
Ask “and then what?” until it’s finished. People stop narrating too early because the next bit is obvious to them.
For every step, ask what could go wrong here. This is what fills in section four, and it’s where most of the real content comes from.
Ask who else touches this. Processes almost always involve more people than the first description suggests.
Write it as they say it, not as it should be. The temptation to record the correct version is strong. Resist it. You’re documenting reality, and the workarounds people have invented are usually telling you where the process is broken.
If more than one person does the work, map it with both. The disagreement is the useful part. When two people describe the same process differently, either it varies by person, which is worth knowing, or one of them is doing it wrong, which is worth knowing sooner.
What to do with what you find
Before you automate anything, do three passes over the map.
Delete. Which steps exist for no current reason? Approvals nobody ever refuses, reports nobody reads, records kept for a system that’s gone. Remove them. It costs nothing and takes effect immediately.
Simplify. Which handoffs could disappear? Every time information moves between systems or people, that’s a candidate.
Then automate what’s left. By this point the automation candidates are obvious, and so is the order to do them in.
That sequence matters. Automating before deleting makes the pointless work permanent, and it’s much harder to remove once it’s wired in.
The uncomfortable outcome
Sometimes a process map shows that the process shouldn’t be automated at all. It runs four times a year, or the rules genuinely change every month, or it needs judgement at every step.
That’s a good result. You spent an afternoon instead of a budget, and you now know something about your business you didn’t know that morning.
Most of the automation projects I’ve seen fail would have been caught at this stage. Not by anything clever, just by writing down what happens and noticing that nobody could agree on what happens.
If you want a second pair of eyes on a process before committing to anything, send me the map or just describe the process and I’ll tell you what I’d want to know before building.
Frequently asked questions
How do I map a business process?
Write down the trigger that starts it, every step in order, who does each one, what system it happens in, and what decides the branches. Then add the exceptions, which is the part people skip and the part that matters. Most small-business processes fit on one page.
What is the difference between as-is and to-be process mapping?
As-is records how the process actually runs today, including the workarounds. To-be describes how you want it to run once it's changed. You need the as-is first, because a to-be built on an imagined current state usually misses the exceptions that make the process hard.
Do I need special software to map a process?
No. Paper, a whiteboard or a plain document is fine, and often better because nobody gets distracted by formatting. Diagramming tools help when a process spans several people, but the value is in the thinking, not the notation.
How long should process mapping take?
For a single small-business process, usually an afternoon, sometimes two conversations. It runs long when the rules have never been written down or when people disagree about how the process works, and both of those are worth discovering before you pay to automate anything.
What if my process is different every time?
Then it's probably several processes wearing one name, and separating them is the first useful step. Genuinely unique work that needs judgement each time is a poor automation candidate, but most work described as always different turns out to be three or four variants with clear triggers.
Wondering what this would look like in your business? A short chat is usually enough to tell.
Let’s chat