How to Map a Business Process Before You Automate It
A common automation project starts like this:
“Can we automate this?”
Then someone immediately starts building.
Triggers.
Integrations.
Notifications.
Forms.
Rules.
But nobody has properly documented what the process is supposed to do.
That is how businesses end up automating unnecessary steps, old workarounds and processes nobody actually likes.
Before automating a workflow, map it.
Start With One Clear Beginning and End
Do not try to map the whole business at once.
Choose one process.
For example:
Starts: Customer approves quote
Ends: Job is ready to schedule
That gives the process boundaries.
Everything between those two points is what you need to understand.
Write Down What Actually Happens
Do not map the ideal process first.
Map reality.
For example:
Quote approved
↓
Sales emails admin
↓
Admin checks deposit
↓
Admin creates customer in job system
↓
Admin creates job
↓
Purchasing reviews quote
↓
Materials list created
↓
Operations notified
It may look inefficient.
That is useful.
You are trying to expose the current workflow, not make it look impressive.
Identify Who Touches Each Step
For every action, ask:
Who does this?
It might be:
- salesperson,
- administrator,
- operations manager,
- technician,
- purchasing,
- finance,
- or the customer.
Handoffs between people are often where delays appear.
If one process moves through five departments, every transition deserves attention.
Identify Which System Holds the Information
Next ask:
Where does the information live?
For example:
Customer details → CRM
Approved quote → quoting platform
Job → job management system
Payment → accounting
Site photos → email
This quickly exposes duplicate data entry and disconnected systems.
If the same customer information appears in four places, you have probably found an automation opportunity.
Capture the Decisions
Processes are rarely just straight lines.
There are usually decisions.
For example:
Deposit paid?
If yes:
Continue
If no:
Request payment
Or:
Materials required?
If yes:
Create purchasing task
If no:
Move to scheduling
These decisions matter because automation needs clear rules.
If the answer is always:
“It depends.”
you need to understand what it depends on.
Find the Waiting
One of the most useful questions is:
Where does this process stop?
Maybe work waits for:
- customer approval,
- internal approval,
- a deposit,
- materials,
- paperwork,
- another department,
- or someone to notice a task.
Those waiting points are often more important than the steps themselves.
A five-minute task that waits four days is still a four-day delay.
Remove Unnecessary Steps Before Automating Them
Suppose the current process is:
Export spreadsheet
↓
Reformat spreadsheet
↓
Upload spreadsheet
↓
Create records
You could automate all four steps.
But perhaps the better solution is:
Send the records directly between the two systems.
Automation should simplify the process.
Not preserve every historical workaround.
Separate Rules From Exceptions
Most workflows have a normal path and a few unusual cases.
For example:
90% of approved quotes → create job automatically
10% require management review
Do not design the whole workflow around the 10%.
Automate the normal path.
Then surface the exceptions for a person.
That often creates a simpler and more reliable system.
Define the Future Process
Once the current workflow is understood, design what should happen instead.
For example:
Quote Approved
↓
Check Deposit
↓
Create Job Automatically
↓
Transfer Customer + Scope
↓
Generate Materials Requirements
↓
Notify Operations
Now you have something worth automating.
Start With a Whiteboard, Not Software
You do not need sophisticated tools to map a process.
A whiteboard, document or simple diagram is enough.
For each step, capture:
Action
Owner
System
Information Required
Decision
Next Action
If the workflow cannot be explained clearly on paper, building automation around it will usually make things harder.
At 5M Consulting, we help businesses map how work actually moves through their operations before deciding what should be automated, integrated or redesigned.
Automation works best when the process underneath it already makes sense.
Do not automate the mess.
Map it first.