Here is the direct answer: process mapping is the step that separates a 4-week automation project from a 16-week disaster where you are still patching the broken workflow. You can skip it. You can also skip a parachute on your first skydive. One of those choices ends differently than the other.
I have watched this play out in almost 40% of the automation projects I quote. Someone gets excited about a tool, buys it, and then realizes mid-implementation that they have no idea how their process actually works. That confusion costs time. It costs money. It costs trust in the entire automation effort.
TL;DR
Document your current process — even rough — before you pick an automation tool. Spend an afternoon on a whiteboard with the people who actually do the work. When everyone agrees on what the process is, you are ready to automate. Skip this step and you automate the process you think you have, not the one that actually exists.
What is process mapping?
Process mapping is the act of documenting how a business process actually works — who does what, in what order, using which systems, and where decisions happen. The output is usually a flowchart or swimlane diagram that everyone involved can read and agree on.
It sounds simple. It is not always. The gap between how a process is supposed to work and how it actually works is where most automation projects go wrong. Process mapping closes that gap before you build anything.
Done well, process mapping takes an afternoon for a simple single-department workflow and two to three days for a process that crosses multiple teams. The output is not a beautiful diagram — it is shared clarity. That is the point.
Why companies skip mapping (and why they pay for it)
The reason is simple: process mapping feels slow. Everyone sees a slick demo of an automation tool and thinks, "Let us just implement that." The documentation feels like bureaucracy. It feels like overhead. It feels like the thing you do when you have already wasted six months and need to justify it on paper.
I have delivered this speech approximately 40 times in the past few years: "but have you mapped your process first?" My wife can recite it word for word. She does not find this as useful as I do. It lands about as well as you would expect when someone has already bought the software and booked the implementation date.
But here is what actually happens when you skip it. You implement the tool. Three weeks in, a user says, "But we also do this step before that," and suddenly your automation is missing half the workflow. You patch it. Someone else finds another undocumented workaround. You patch that. Six months later, the tool is still broken because the foundation never existed.
The McKinsey Global Institute has been tracking automation adoption across industries for years. The pattern is consistent: the companies that get strong ROI from automation are the ones that invested in process clarity before tooling. Not after. The companies that spend one afternoon on a whiteboard save four months of rework. You pick which conversation sounds better to your business.
The construction company that taught me this lesson
A construction company hired me to implement new financial software. I showed up ready to demonstrate. Everything was configured. I had the screen ready and a plan for the afternoon.
I walked through the system. Showed all the features. Did the whole demo.
Nothing. No buy-in. No excitement. No next steps. I went home empty-handed, which is not a great feeling after a two-hour drive.
The manager called two days later. "The team does not understand why we are changing. They were not part of the decision. Nobody told them the goal." The finance employees — the ones who would use the system every day — had no idea why I had shown up with new software. So when I demonstrated, they were not ready to receive it. They were suspicious. The tool felt like something being done to them.
I told him straight: take two weeks. Inform everyone about what the company wants and why. Map out the current process with the team. Get them on board. Then call me back.
Two weeks later: new plan, full team alignment, and the implementation ran smooth as butter. Same software. Same consultant. Completely different outcome — because the process and the people were sorted before the tool came back into the room.
Change management is not optional, as Harvard Business Review has documented extensively — and process mapping is the first chapter of it. Everything else is built on top. If the people doing the work do not understand and own the new process, no automation will save you.
Five problems with automating before mapping
Hidden process issues go unaddressed
You automate the process as documented, not as it actually works. Somewhere, someone has a workaround. Someone else uses a spreadsheet to track things the system never mentions. You automate past all of it. Six weeks later, those workarounds are gone and suddenly nothing works.
Limited opportunity for actual improvement
When you map first, you spot redundancies, unclear handoffs, and bottlenecks. You have the chance to fix them before you automate. When you skip mapping, you just make the bad process faster. Automating a broken process is not automation — it is acceleration of the problem.
Reduced stakeholder buy-in
The people using the tool were not involved in designing the new workflow. They see the automation as something imposed on them, not something that improves their work. That resistance kills adoption. I have seen expensive implementations sit unused because nobody asked the team what they actually needed.
Wasted time and expensive rework
You discover problems after go-live instead of before. That is the most expensive time to find them. Change orders, patches, emergency fixes, staff retraining. The "time saved" by skipping mapping is spent three times over on cleanup.
Wrong tool evaluation
Without a clear map of your actual workflow, you cannot evaluate whether a tool fits. You buy based on features and demos and end up jamming your process into the tool instead of finding the tool that fits your process. The invoice automation guide has a worked example of exactly this happening.
The right way: how to map your process
This does not need to be elaborate. (I have done it on an A3 sheet of paper in a client kitchen while someone made coffee. The napkin is fine. The clarity is not optional.) Here is the approach that works in practice:
1
Gather the people who do the work
Not the managers. Not the visionaries. The people who handle the process every single day. They know what it actually is. Managers know what it is supposed to be, which is a different thing.
2
Start with the trigger
What starts the process. An email arrives. An order is placed. A customer calls. Write that down first. Everything else follows.
3
Map every step sequentially
What happens next. Who does it. What systems are involved. Draw it as a flowchart or a swimlane diagram if multiple people are involved. Include every decision point: "If X, do this. If Y, do that." If people disagree on a step, that disagreement is the most valuable thing in the room.
4
Mark the approvals
Where does someone have to sign off. Who has final say. Where do things get stuck waiting for feedback. These are the places automation will either shine or break. Mark them all.
5
Document how it ends
What is the success state. The customer gets their order. The invoice is paid. The case is closed. Write that down. Without a clear end state, you cannot tell if the automation is working.
When everyone in the room can read the diagram and say "yes, that is what we do" — you have something worth building on. That moment is the green light. Not the purchase order. Not the signed contract. That moment.
How to know when your map is good enough
Process mapping can go on forever if you let it. You can spend weeks documenting edge cases and hypothetical scenarios. I have seen teams three months in, still arguing about one approval step, starting to wonder why this feels like bureaucracy. The answer is: it has become bureaucracy. Stop.
Your map is good enough when four things are true. Everyone who handles the process can read it and say "that is what I do" with no surprises. The map shows where decisions happen and who makes them. The major handoffs between people or systems are visible. And you have documented the 80% case, not the hypothetical edge case that happens twice a year.
Here is the practical test: take a real example — an actual invoice, an actual order — and walk it through the diagram. Does it fit cleanly. If yes, you are done. If it gets stuck or skips steps, update the map and try again. Three iterations of this and you will have something solid enough to automate.
When to DIY and when to hire help
Try it yourself first. Seriously. For a single-department process with under 10 steps, one afternoon on a whiteboard with the team will tell you everything you need to know. No consultant required, and I say that as a consultant. If the output is clear and the team agrees on it, you have your foundation.
The signals that it is worth bringing someone in: people disagree on what the process actually is. There are obvious workarounds that nobody wants to name out loud. The map keeps growing and you cannot find the edges. Change resistance is high and you need a neutral facilitator — someone who is not part of the politics and can ask the awkward questions without it becoming a department meeting.
In my experience, if a 30-minute conversation saves you a three-week consulting project, I have had this conversation about 100 times. It usually tells you more than you expected. There is more on the blog if you want to keep reading.
Best practices that actually work
A few things I have learned from 100+ projects that are worth repeating.
Involve the people doing the work from the start. Not after the map is drawn, not as a review step. From day one. They will find things you missed, and they will own the result because they built it. That ownership is what makes adoption stick.
Document what you do now, not what you think you should do. This sounds obvious. It is not. Be honest about the workarounds, the Excel files that should not exist, the approval that technically goes through a different person on Fridays. Those are the things that will break your automation if you pretend they are not there.
Mark decision points clearly — every approval gate, every "if this then that," every place where work can stop and wait. Use swimlane diagrams when the process crosses team boundaries; they make invisible handoffs visible, and invisible handoffs are where most implementations fail. And when the map is done, photograph the whiteboard, send it to everyone, and ask one question: "What did we miss?" Do that until the answer is "nothing."
The pattern I keep seeing in the projects that go well: the map is boring. It looks obvious in hindsight. Everyone nods at it. That is exactly what you want. Boring, obvious, and agreed on is the best possible foundation for automation. Exciting, ambitious, and unclear is how you get a 16-week disaster.
Also on the blog
Frequently asked questions
How long does process mapping actually take?
For a simple workflow — single department, under 10 steps — budget an afternoon. For a mid-sized process crossing multiple teams, 2–3 days of interviews and whiteboarding. For enterprise-scale with complex approvals and systems integration, budget 1–2 weeks. The rule of thumb: the bigger the change you are planning, the more time mapping pays for itself. An afternoon now saves four months later.
What tools should we use to map the process?
Honest answer: a whiteboard and a camera work better than you think. If you want digital, Miro, Lucidchart, or Draw.io do the job well. Stay out of Microsoft Visio — it will make this feel like enterprise bureaucracy instead of clarity work. The tool is not the point. The thinking is.
Do we really need a swimlane diagram?
If your process crosses department lines or involves multiple people, yes. Swimlanes show who owns what step and catch the invisible handoffs that usually break things. If it is a single person doing one workflow, a simple flowchart works. Match the format to the actual complexity, not to the template.
What if our process is too complicated to diagram?
That is actually the most important signal you have. If you cannot diagram it in two hours of honest work, the process is broken. Not the diagram — the process. Either there is a ton of hidden rework, undocumented workarounds, or conflicting business rules. Find those first. Only then automate. Automating chaos fast is still chaos.
How do we know when the mapping is done?
When everyone who does the work — not the managers, the people actually handling the process — can read the map and say 'that is what I do.' You are done when there are no surprises left. If you map for three weeks and people keep pointing out steps you missed, you have a bigger problem than the map.
Should we involve frontline staff in the mapping?
Non-negotiable. The people doing the work every day know what the process actually is, not what the procedures say it should be. If you map without them, you will automate the official process and get a nasty surprise when the real process — the one with all the workarounds — stops working. Involve them early, credit them, listen to them.
Can we do this ourselves or do we need a consultant?
Try it yourself first. A mid-sized process, a small team, half a day on a whiteboard. If you get through it and the map makes sense, you have your answer. If you hit friction — people disagreeing on what the process is, undocumented rework, unclear handoffs — that is when a second pair of eyes is worth the cost. Call me before you call a consultant; that first conversation is free.
What happens if we skip mapping and go straight to automation?
You automate the process as you think it works, not as it actually works. This usually means: surprising failures after go-live, frustrated users because the workflow does not match reality, expensive rework to patch the automation instead of fixing the root cause. I have seen this play out in almost 40% of the projects I quote. Do not be a statistic.
Tijdo Koster
Automation consultant since 2009. 100–200 projects. Still answers his own emails.
If you have made it to the bottom and your main takeaway is that process mapping is essentially just "draw the thing before you break the thing," yes, that is correct. It took me about three failed demos to figure that out. My wife would say I also do this with flat-pack furniture instructions. She is not wrong.
There is more on the blog if you want to keep reading. The products page has the toolkit for when the map is done and you are ready to pick the tools.