How to Actually Map a Workflow Before You Automate It
Before automating a workflow, map the real work - including exceptions, undocumented decisions, handoffs, and shadow processes that never appear in the official version.
Bart LuderaCEO
One thing I’ve learned from working on AI and automation projects is that mapping a workflow sounds much easier than it actually is.
On paper, it feels simple.
You sit down with someone from the company, ask them how a process works, draw a few boxes in Miro, add some arrows, and you’re done.
In reality, that usually gives you a very clean version of a process that does not really exist.
The actual process is normally much messier.
There are spreadsheets nobody mentioned. Someone checks an old email before making a decision. Another person keeps a private list of exceptions. A manager needs to approve something only in certain cases. An ERP contains one piece of information, while another system is treated as the real source of truth.
And then there is always:
"Usually we do it this way, except when..."
That "except when" is where a lot of automation projects start getting difficult.
So if you want to automate a workflow, especially with AI, the first job is not to design the AI system.
The first job is to understand what people are actually doing today.
Don't ask people to describe the process. Watch them do it.
Probably the biggest mistake is starting with:
"Can you explain how this process works?"
You will usually get something like:
"The customer sends us a request, sales prepares the quote, the manager approves it and we send it back."
Technically correct.
Practically useless.
Instead, ask:
"Can you open a real request from yesterday and show me exactly what you did?"
Then watch.
Where do they click?
What do they copy?
What do they search for?
Which systems do they open?
What information do they look at before making a decision?
Who do they message when something doesn't look right?
What do they know from experience that isn't written anywhere?
This is where the actual workflow starts appearing.
Record the same workflow several times
A really useful trick is to treat workflow discovery almost like creating an SOP.
Record someone performing the same process a few times.
Ideally, have them share their screen and talk through what they are doing.
Something like:
"I'm checking the customer in the ERP now."
"I normally look at their previous orders here."
"This product isn't available, so I'll check what we sold them last time."
"Because the discount is above 10%, I need approval from my manager."
One recording gives you an example.
Three or five recordings start giving you a process.
The differences between those recordings are often more interesting than the similarities.
Imagine you are mapping how a distributor prepares quotations.
The first case might be:
Email
-> identify products
-> check availability
-> calculate price
-> send quotation
The second customer says:
"Same as last time, but 20 more units."
Now the workflow becomes:
Email
-> identify customer
-> find previous order
-> understand what "same as last time" means
-> check current availability
-> update pricing
-> send quotation
The third order contains an unavailable product.
Now you have:
Check availability
-> product unavailable
-> find substitute
-> compare specifications
-> check price
-> possibly get approval
-> propose alternative
Suddenly you realize that there isn't really one workflow.
There is a core workflow surrounded by branches and exceptions.
That matters a lot when you start designing automation.
Don't only record normal cases
There is one important problem with the "record it three times" method.
You might record the happy path three times.
If 80% of cases are simple, chances are that is exactly what will happen.
So after watching a few normal executions, deliberately ask for difficult cases.
For example:
"Show me the worst request you received last month."
Or:
"When does this process become annoying?"
Or:
"What situations make you stop and ask somebody else what to do?"
Or:
"Which cases can't be handled by a junior employee?"
These questions are incredibly useful because they expose the real complexity of the process.
Normal cases tell you how the workflow works.
Edge cases tell you whether your automation will survive production.
Map decisions, not only actions
A lot of process maps focus almost entirely on actions.
Open email.
Check CRM.
Create quotation.
Send email.
That is not enough for AI automation.
The interesting part is usually the decisions between those actions.
For every step, I like to understand something close to this:
| Element | What you need to understand |
|---|---|
| Trigger | What starts this step? |
| Input | What information arrives? |
| Action | What exactly does the person do? |
| System | Where do they do it? |
| Data | Where does the information come from? |
| Decision | What decision are they making? |
| Rule | How do they make that decision? |
| Exception | When does the normal path change? |
| Output | What is produced? |
| Owner | Who performs the step? |
| Time | How much active work does it take? |
| Wait | How long does it sit before someone acts? |
| Volume | How often does it happen? |
| Error | What usually goes wrong? |
For AI projects, I would add a few more.
Source of truth
Which system or document should the automation trust?
Companies often have five systems containing similar information, but employees know that only one of them is actually reliable.
That matters.
Confidence
Does the employee know exactly what to do, or are they making a judgment call?
There is a big difference between:
"If margin is below 20%, request approval."
and:
"I look at the customer, order size and relationship and decide whether the discount feels reasonable."
Both are decisions.
Only one is a simple business rule.
Escalation
When does this person stop handling the case themselves?
Who does it go to?
Why?
This often becomes your human-in-the-loop logic later.
Risk
What happens if this decision is wrong?
A bad draft email is probably low risk.
Approving a €500,000 credit limit is not.
That distinction should heavily influence how much autonomy you give the system.
Find the invisible work
Some of the most valuable steps will never appear in a formal SOP.
Things like:
- searching old email threads
- comparing multiple PDFs
- checking whether something "looks right"
- copying information between systems
- asking a colleague on Teams
- looking for an old quotation
- checking a spreadsheet someone built five years ago
- rewriting data into the format another system expects
This is often where the best automation opportunities are hiding.
Formal processes tend to document what is supposed to happen.
Shadow workflows show you what people actually need to do to make the formal process work.
Look carefully at handoffs
A lot of waste doesn't happen inside individual tasks.
It happens between people.
Sales sends something to operations.
Operations asks finance.
Finance sends it back.
Sales realizes a field is missing.
It goes back to operations.
Then someone waits six hours because the person who needs to approve it is in meetings.
The actual work might take 25 minutes.
The process takes two days.
This is why I always separate:
Working time
from:
Waiting time
They are two completely different problems.
Automation might save 10 minutes of manual work.
But eliminating one approval queue might save 12 hours of lead time.
The second improvement can easily be much more valuable.
Don't automate every step with AI
Once you have the workflow mapped, the next useful exercise is classifying each step.
I normally think about four buckets.
Human
Some things should simply remain human.
Negotiations, sensitive decisions, relationship management, unusual strategic situations.
Deterministic software
If a rule can be expressed clearly, you probably don't need an LLM.
For example:
IF discount > 10%
THEN require manager approval
That is normal software.
Keep it boring.
AI
AI makes sense where you have things like:
- unstructured text
- documents
- classification
- extraction
- matching
- summarization
- semantic search
- generating drafts
- fuzzy decisions based on context
AI + human approval
This is probably the most useful category in many real companies.
The system does 80-95% of the work.
A person reviews the result before anything consequential happens.
That usually gives you much better economics without introducing unnecessary risk.
Quantify the workflow
A process map without numbers is useful.
A process map with numbers becomes a business case.
For each step, try to understand:
- how frequently it happens
- how long it takes
- how many people touch it
- how often errors happen
- how expensive those errors are
- how long the step waits
- whether it impacts revenue
- whether it blocks another team
A simple formula can already tell you a lot:
monthly volume × average handling time
If 1,000 requests arrive every month and each takes 15 minutes to process, you are looking at roughly 250 hours of work.
But don't stop at labor savings.
Sometimes the bigger value is elsewhere.
If sales quotations currently take six hours and customers often buy from whoever responds first, reducing that to ten minutes can have much more impact than saving the administrative time itself.
The process might be valuable to automate because of:
speed, capacity, revenue, quality, consistency, risk reduction or customer experience.
Not only because you can remove manual work.
Don't confuse the current process with the future process
This is another important trap.
After mapping the existing workflow, people immediately start asking:
"How can we automate each of these steps?"
Sometimes that is the wrong question.
The existing process was designed around humans and the limitations of existing software.
You don't necessarily want to reproduce it.
Imagine today's workflow looks like:
Email
-> Excel
-> ERP
-> Excel
-> manager
-> ERP
-> email
You could automate that exact chain.
Or you could ask whether the workflow should become:
Incoming request
-> AI intake
-> ERP/API lookup
-> business rules
-> AI-generated proposal
-> human approval if needed
-> response
The second option is not really automation anymore.
It is process redesign.
And that is usually where the larger gains come from.
Separate AS-IS from TO-BE
I find it useful to explicitly build two workflows.
AS-IS
What happens today.
Do not optimize it yet.
Do not make it prettier than reality.
Document the mess.
TO-BE
What should happen after automation.
Only design this after you understand the first one.
Otherwise you run the risk of building a beautiful solution to a process you never properly understood.
A useful final output
You do not need a 100-page consulting deck.
For many workflows, something as simple as this can be enough:
| Step | Today | Problem | Opportunity | Impact | Complexity |
|---|---|---|---|---|---|
| Read request | Manual | Slow | AI extraction | High | Low |
| Identify products | Manual search | Errors | Semantic matching | High | Medium |
| Check stock | ERP lookup | Copy-paste | API integration | Medium | Low |
| Find substitute | Expert knowledge | Bottleneck | AI recommendation | High | Medium |
| Calculate pricing | Spreadsheet | Slow | Rules engine | High | Medium |
| Write response | Manual | Repetitive | AI draft | Medium | Low |
| Approval | Manager | Waiting | Risk-based routing | High | Medium |
At that point you can start making actual decisions.
Which parts should we automate first?
Where do we need AI?
Where is normal software enough?
Where should a human stay in the loop?
Where is the ROI?
What should we ignore because it is technically possible but commercially irrelevant?
The biggest lesson
Good workflow mapping is not really about diagrams.
The diagram is the easy part.
The hard part is uncovering all the little things people do without thinking about them.
The undocumented rules.
The exceptions.
The judgment calls.
The spreadsheets.
The messages to coworkers.
The moments where someone says:
"Technically the system says X, but we always do Y."
That is the real process.
And if you want to build automation that survives outside a demo, that is the process you need to understand.