Automation makes a messy process run faster—not better.
A weekly report may look simple until someone traces it: figures copied from a spreadsheet, an approval chased by email, a missing file resent twice, then a last-minute correction. Automating that chain before understanding it can turn small workarounds into fast, repeatable mistakes.
The safest first move is a current-state map: a plain view of what happens now, who does each step, which tools and files are involved, where decisions occur, and where work stalls or returns for fixes. It does not need polished diagram software; sticky notes, a table, or a simple flowchart can reveal plenty. This practical starting point supports improving business processes because it separates the essential work from habits that merely grew around it. Map the real process, including detours—not the ideal version described in a procedure document. That honest picture gives automation a reliable place to begin.
Draw a boundary around one piece of work
-
Start where friction shows up often
Pick a workflow that repeats regularly, causes visible delays, or creates avoidable mistakes. A small recurring annoyance is often a better first target than a sprawling “important” process.
-
Name the trigger
Write the exact event that starts the work: a customer submits a form, an invoice arrives, or a manager approves a request. “When someone needs help” is too vague to map.
-
Describe the finished outcome
Define what must be true at the end, such as a confirmation sent, a record updated, or an order ready to ship. This gives the map a clear finish line.
-
Identify who receives the result
The recipient may be a customer, a colleague, a finance system, or another team. Naming them helps reveal whether the outcome is actually usable.
-
List what stays outside
Exclude upstream planning, rare exceptions, and follow-up work unless they are essential to the chosen result. A tight first map can always expand later.
A useful boundary might be: from a new website enquiry arriving to a qualified reply being logged and sent.
It does not need to include campaign planning, sales calls, or long-term customer follow-up. Those can become separate maps once the first workflow is understood.
Follow one real item from start to finish
-
Bring together the people at each handoff
Include the person who starts the work, the people who change or check it, the recipient, and anyone who approves it. Each sees a different part of the process; missing one view often hides the actual delay.
-
Use a recent example, not the written procedure
Pick one completed request, order, ticket, or form and replay what happened. Ask, “What did this person do next?” rather than “What should happen next?”
-
Collect the traces left by the work
Open the email thread, spreadsheet rows, chat messages, forms, screenshots, and system history. These records reveal copying, chasing, re-entering data, and side conversations that a neat flowchart misses.
-
Write actions as observable verbs
Capture steps such as “download attachment,” “check address against invoice,” “ask manager in chat,” and “wait for correction.” Avoid vague boxes like “process request”; they conceal the work an automated flow must handle.
-
Mark waits, loops, and judgment calls
Note who waits, how long, what sends work backward, and where someone decides whether an exception is acceptable. A rough map with these marks is far more useful than an ideal-looking diagram.
Map what happened on ordinary days and on at least one awkward case. Both belong to the current process.
When a step sounds simple, request the artifact that proves it happened: the message sent, field updated, file renamed, or approval recorded.
A small amount of evidence keeps the map grounded and makes hidden manual work visible before automation carries it forward.
Sketch the flow with simple symbols
A process map does not need formal diagram rules to be useful. Start with a shared whiteboard, paper, or spreadsheet and use the same small set of marks throughout:
- Oval: where the process starts or ends
- Rectangle: an action, such as “check invoice details”
- Diamond: a decision with clear paths, such as “purchase order matches?”
- Arrow: the direction of work
- Label above an arrow: a wait, handoff, or system change
For example, an invoice-approval flow might read: Invoice arrives → Accounts clerk logs it → Clerk checks supplier and amount → Purchase order matches? → Yes: manager approves → Payment is scheduled → Supplier is notified. The “No” path can lead to ask purchaser for clarification → correct or dispute invoice → repeat the check.
Add the person or team responsible beneath each rectangle. Put a small clock beside steps that regularly wait, such as “manager approval: 2 days.” That modest detail quickly reveals whether automation should route an approval, validate data, or simply send a reminder.
The map only needs to be legible enough for colleagues to challenge it. Boxes may be crooked; the sequence must not be. Teams can decide when a process has outgrown a spreadsheet map after the flow is understood, rather than buying diagram software to solve uncertainty.
Use one page and one real example. If a symbol creates debate, replace it with a clear label. Shared understanding is the goal; polished notation can come later.
Map the paths that do not go smoothly
The straight-line version of a process is rarely the version people actually perform. At every step, ask: What has to be true for this to move forward? What happens when it is not? Who decides? Add a decision diamond for each meaningful choice, then draw every common route that follows.
For an invoice, “approved?” may lead to payment, a request for clarification, or escalation to a manager. A missing purchase-order number may send the item back to the supplier; a duplicate may require cancellation and a note in the accounting system. These are not edge details. They reveal where the process consumes time and judgment.
Mark waits, handoffs, and rework
Label each handoff with the sender, receiver, and system involved. Mark waits separately from active work: “awaiting manager review—up to 2 days” says far more than a vague arrow. When an item returns to an earlier step, draw the loop and note its cause. This makes it easier to spot bottlenecks in the process map rather than merely notice that work feels slow.
Also trace the data. Record where each required field originates, where it is changed, and where it is checked. An automation cannot reliably fill in a value whose source is unknown or interpret an approval rule that exists only in someone’s memory.
Before selecting a tool, write down ambiguous cases such as:
Which amount requires a second approval? What counts as a duplicate record? Who resolves missing or conflicting information?If the answer varies by person or is hidden in email, the process needs a rule before it needs automation.
Walk the map with the people who do the work
-
Bring one recent case to the table
Use the same invoice, request, or order already traced in the map. A real example keeps the conversation grounded and makes missing steps easier to spot.
-
Ask the frontline owner to replay each move
Have each participant describe what they received, what they checked, where they recorded it, and what happened next. Update the map on the spot when the lived sequence differs from the neat version.
-
Mark friction without treating every complaint alike
A second click, awkward screen, or copy-and-paste may be irritating but tolerable. Repeated waiting, unclear ownership, missing information, and frequent rework deserve stronger attention because they slow the whole case or create errors.
-
Test the exceptions
Ask what happens when data is incomplete, approval is delayed, or a customer changes the request. If people rely on judgment, informal messages, or workarounds, capture that before proposing a rule-based tool.
-
Decide what is stable enough to automate
A promising step has a clear trigger, consistent inputs, a repeatable rule, and a known owner for exceptions. If the team cannot agree on the normal path, improve and standardize it first; automation can follow with far less risk.
A 20-minute walk-through often reveals more than a polished diagram reviewed in isolation.
Count the impact, not just the annoyance. A delay is worth prioritizing when it occurs often and causes one or more of the following:
work to queue behind it people to chase updates data to be entered again customers or colleagues to wait errors that require correctionThis simple check prevents effort being spent automating a minor inconvenience while a larger blockage remains.
Turn the map into a buildable brief
-
Define the rule and its owner
Write each decision as a plain-language rule: what condition is checked, what happens next, and who can change it. A named owner prevents a workflow from becoming “everyone’s responsibility.”
IncludeRules that a new team member could apply consistently.AvoidHidden judgment calls presented as fixed rules. -
List clean inputs and finished outputs
Record where each input comes from, its required fields, and what counts as a usable output. This reveals missing data and prevents an automation from simply moving incomplete work faster.
IncludeSpecific sources, fields, recipients, and completion criteria.AvoidVague inputs such as “customer details” or outputs such as “processed.” -
Design the exception route
For every common failure, state where the item stops, who reviews it, and how it re-enters the flow. Exceptions do not need to be eliminated before automation; they need an intentional home.
IncludeA visible queue, alert, or handoff for unusual cases.AvoidAssuming errors will be rare enough to ignore. -
Choose a small measure of success
Set a baseline from the current map, then pick one or two measures such as turnaround time, rework rate, or manual touches. A modest pilot becomes easier to judge when improvement has a number attached.
IncludeMeasures tied to the original friction point.AvoidA long dashboard with no decision behind it.
Start with one stubborn process
- Pick one recurring process that creates visible waiting, rework, or follow-up.
- Replay a recent real case with the people closest to the work.
- Validate the map before choosing the smallest safe automation experiment.
A process map earns its value when it becomes a practical brief: clear inputs, rules, owners, outputs, and routes for the cases that go wrong. That clarity makes a small automation choice far less risky.
This week, map and validate one high-friction process. Then select one narrow improvement that removes a proven delay or manual touch—not the entire workflow at once. A tested first step creates momentum and useful evidence for the next one.
