To map a workflow before automating it, record the trigger, desired outcome, participants, information, decisions, handoffs, normal path and exceptions. Then design the improved workflow separately from the current one.
A useful map explains how work changes state. A list of task steps rarely gives enough information to build a reliable automation because it leaves out who decides, what data they use and what happens when a case does not fit.
Workflow mapping supplies the feasibility detail needed within the wider decision about where to start with AI and automation.
Map the work at the level needed to make implementation decisions. Capture enough detail to expose ambiguity without documenting every click.
Set the boundary and outcome
Name one start event and one completed state. “Customer onboarding” can span weeks and several teams. “Accepted proposal to scheduled kickoff” is a workable boundary.
Write down:
- the trigger that starts the workflow;
- the output or state that marks completion;
- the customer or business outcome it supports;
- the owner responsible for the result;
- the volume and frequency during a normal period.
The boundary prevents the mapping session from expanding into every connected process. Record related issues in a parking list and return to them only if they block the selected outcome.
Map the current path using real cases
Follow two or three recent cases from trigger to completion. Use records, messages and system history where available. The documented procedure may describe the intended process while real cases reveal workarounds and hidden checks.
For each step, capture the actor, action, system, input and output. Keep verbs specific: “validate billing details” is more useful than “process request.”
Mark waiting time separately from working time. A five-minute action can create a two-day delay when it sits unnoticed in an inbox. That distinction often changes the business case.
Record decisions and their rules
Every branch in the workflow represents a decision. State the question, the information used and the possible outcomes.
For example:
- Is the request complete? Required fields and attachments determine yes or no.
- Does this proposal need director approval? Value and discount thresholds determine the path.
- Can this invoice be posted automatically? Supplier match, amount tolerance and tax fields determine eligibility.
If the team cannot explain a decision rule, mark it as judgement. Some judgement should remain human. Other judgement can become clearer after examples are reviewed.
Do not force every decision into a rule to make automation possible. The map should represent the work accurately, including uncertainty.
Make handoffs explicit
A handoff changes responsibility. Record the sending owner, receiving owner, information transferred, expected response time and evidence that the handoff was accepted.
Weak handoffs create much of the friction attributed to manual work. Emailing a shared inbox is an action, but it may not transfer accountability. A better design creates a named owner, next action and due state.
Ask what happens when the receiving person is absent, the information is incomplete or the deadline passes. Those are part of the handoff design rather than operational afterthoughts.
Inventory the information and systems
For each step and decision, list the required fields, their source and where the output is stored. Note whether each source is structured and dependable.
Useful questions include:
- Which system holds the authoritative customer, project or transaction record?
- Which fields identify the same item across systems?
- What information arrives in email, documents or free text?
- Where do people correct or supplement the data manually?
- Who can access each system?
- How are changes and failures recorded?
This inventory distinguishes a workflow issue from an information or integration issue. It also exposes prerequisites that should affect prioritisation.
Design exceptions before the normal path
List the cases that cannot follow the expected route. Group them by cause rather than recalling every unusual example.
Common groups include missing information, failed validation, duplicate records, conflicting data, unavailable systems, out-of-policy requests and cases requiring judgement.
For each group, define:
- how the exception is detected;
- whether the workflow pauses or continues safely;
- who receives it;
- what context they need;
- what action resolves it;
- how the case returns to the workflow;
- whether the pattern should be reviewed later.
An automation is dependable when exceptions become visible work with ownership. Silent failure and endless retries create operational risk.
If AI performs part of the workflow, use the human review guide to decide which outputs can continue and which need approval.
Separate current state from future state
Finish the current-state map before designing the improvement. Then create a second map for the desired workflow.
For every current step, decide whether to remove, simplify, standardise, assign, integrate, automate or keep it human. Avoid carrying a step forward only because it exists today.
The future-state map should name:
- the system or person responsible for each action;
- the data passed between steps;
- decision rules and thresholds;
- review and exception points;
- monitoring and failure notifications;
- the final record showing completion.
This map becomes a practical implementation brief. It lets a builder estimate effort and lets the process owner verify that the proposed workflow matches the operating need.
Add measures and controls
Attach a baseline and target to the mapped outcome. Use a small number of measures such as elapsed time, manual touches, error rate, overdue cases or weekly capacity.
Also define operational controls. Name who can change rules, who responds to failures, how access is managed and when performance is reviewed. An automation needs ongoing ownership after launch.
These inputs feed the business case. They replace broad estimates with evidence from the workflow itself.
A compact worked example
Consider an approved delivery record moving to invoicing.
The current path starts when a project lead marks work complete. Finance checks a project tool, an email folder and a spreadsheet. Missing purchase order details are chased manually. Eligible records are copied into accounting software, then marked as invoiced in the spreadsheet.
The map exposes two decisions: whether the work is billable and whether required billing information is complete. It exposes a handoff from project lead to finance with no acceptance signal. It also shows an exception path for missing purchase orders.
The improved design can require billing fields at project completion, assign incomplete records back to the project lead, pass eligible records to finance for a final check and record the invoice identifier against the project. The normal path becomes smaller because the map dealt with information and ownership first.
Use the map to make a build decision
Review the future-state map with the people who perform and own the work. Test it against normal cases and known exceptions. Confirm system access and data fields with whoever will build the workflow.
Then decide whether the opportunity should proceed. Compare its value, feasibility, effort and risk with other candidates using Which Business Process Should You Improve First?. A good map can also show that automation is unnecessary. That is a useful implementation result because it prevents investment in the wrong intervention.