How to Map a Real Workflow, Including Its Exceptions

A process diagram usually shows the route everyone hopes a case will take. Staff also handle missing information, rejected approvals, urgent requests, and work that happens in email or a spreadsheet. If you plan an AI or automation project from the tidy route alone, the tool will meet those cases after launch. Follow real work first and draw the branches people already use.

Set a clear case boundary

Choose one kind of case and define when it begins and ends. For an accounts-payable team, begin when a supplier invoice arrives and finish when the team pays, rejects, or returns it for correction. “Process invoices” is too broad if it hides what happens before a payment decision. Name the process owner and the result the supplier and finance team expect.

Write down the normal route as a starting hypothesis: receive the invoice, match it to a purchase order and receipt, approve it, and schedule payment. Then ask which cases do not take that route. A missing purchase order, a price mismatch, an urgent payment, and a change to a supplier's bank details need different people and controls. The map should show those differences rather than bury them in a box marked “resolve issue”.

Observe cases instead of relying on a workshop

Ask staff to walk you through recent completed cases while showing the systems and messages they used. Watch new cases as they arrive when the team agrees to it. Give people a chance to explain why they took a step; an observer can see an email but not the rule or missing fact behind it. Include the person who receives the handoff, not only the person who sends it.

Sample deliberately. Take ordinary invoices, cases that needed rework, an urgent case, and a case the team could not finish. Do not let the easiest examples define the whole process. The US Agency for Healthcare Research and Quality's workflow observation example found that even a short period of direct observation exposed information about work and tool adoption that a formal description missed. The setting was healthcare, but the observation method applies to an operations team as well.

Tell staff the purpose is to improve the process, not to rate individual speed. Record case facts and role names only to the degree the mapping needs them. If you need to keep examples for testing, remove personal or supplier details and get the process owner's approval.

Record each step and handoff

Use one row per step in a case record. Include the case ID, the event, who or what acted, the time it started and ended, the source used, the decision made, and the next owner. Note when work stops in a queue; active work and waiting time are different problems. Record a call or spreadsheet lookup even when the main application has no field for it.

For example, an invoice arrives on Monday morning. The payable clerk finds that its unit price differs from the purchase order, so they email the buyer. The buyer checks the agreed price with the supplier and replies the next day. A manager approves the correction, and the clerk updates the invoice before payment. A diagram that jumps from “match” to “approve” misses the supplier contact, the overnight wait, and the second entry of the same fact.

At every handoff, ask what the receiver gets. Do they receive the original invoice, the mismatch amount, the reason for escalation, and the deadline? Can they tell whether someone has already contacted the supplier? If the answer sits in one person's mailbox, the map should show that fragile dependency. AHRQ's process-mapping guidance treats delays, decisions, and transfers between people as parts of the workflow to inspect.

Draw the exception branches

Give each recurring exception a trigger, a decision owner, an action, and a return point. A price mismatch may go to purchasing for a contract check, then back to payable for matching. A missing purchase order may go to the requester, who either supplies the order or explains why the purchase happened outside the normal route. A supplier bank change should follow a separate verification path before payment. These branches should not collapse into a single “human review” step.

Count how often each branch appears and how much delay, rework, or loss it can cause. Frequency matters, but a rare bank-detail change can deserve more control than a common formatting error. Look for loops: an invoice that returns to the buyer twice may signal that the handoff lacks the information needed to decide. Mark cases with no clear owner or no safe route as gaps in the current process.

For each exception, ask whether staff follow an approved rule or a workaround. A workaround may keep suppliers paid while hiding a broken upstream step. Do not automate it simply because people use it often. Find out why the normal path failed and who can change it.

Use system logs without losing off-system work

If the company has reliable event logs, use them to test how often cases take each path and where they wait. Microsoft's process-mining documentation says an event log needs a case ID, activity name, and timestamp. It also warns that systems may not record every event of interest. A log can show an invoice entering and leaving an approval queue while missing the phone call that resolved the mismatch.

Compare the log with observed cases before drawing conclusions. Match event IDs across the payable system, purchasing system, and supplier correspondence where permitted. Check whether two systems use different IDs for the same invoice and whether a status change reflects real work or a batch update. If the log is incomplete, say which parts of the map come from observation and which parts come from records.

Process mining can show variants and repeated steps at scale. It cannot explain an unlogged judgement by itself. Use it to find cases worth examining, then ask the people involved what happened.

Check the map with the people doing the work

Bring the draft map to the clerk, buyer, approver, and process owner. Replay a few real cases through it. Ask where a case enters, what information the next person receives, who can approve an exception, and how the case closes. Invite corrections in the order they occur, not just comments on how the drawing looks.

Keep the map readable. Show the common route on one page and link to short notes for complex branches. Put counts and waiting times beside the steps that caused them. Mark uncertain paths for another observation rather than inventing a rule. Give the process owner responsibility for updating the map when a policy, system, or team changes.

Choose what to change

The map may point to several different fixes. If staff repeatedly ask for a missing purchase order, improve the purchase request before the invoice arrives. If approvals wait because the receiver lacks context, change the handoff record. If the same fact gets copied between systems, an integration may remove the second entry. If an exception has no authority rule, the business must settle that decision before a tool acts.

Only then decide where AI helps. It may extract invoice fields, flag a mismatch, or draft a summary for the buyer, while people keep control of contract disputes and bank changes. Test the proposed change against the observed cases, including branches that return or stop. Measure completed invoices, waiting time, corrections, and payment errors. A process map earns its place when it helps the team change the actual work and see whether the change improved it.