Before changing a manual workflow, map how it actually works today. Follow one piece of work from its trigger to its outcome, and record the people, information, decisions, systems, handoffs, waits, and exceptions along the way. That gives the team a shared view of the work before anyone proposes automation.
If you are still deciding which job to examine, first identify a promising AI workflow candidate. This guide starts at the next step: documenting that candidate as it operates now.
A manager's description of the official process is a useful starting point, but it may not include the workaround someone uses when a document is missing or an approval stalls. The people doing the work and receiving its output can help fill in those gaps. Then check the map against real cases. The result is not an AI plan. It is a more reliable account of the process the team may want to improve.
Key takeaways
>
- Set a clear start and end point for one workflow. - Map it with the people who do the work and receive its outputs. - Record the actual steps, handoffs, decisions, systems, waits, and exceptions. - Check the map against real cases, including cases that took a different path. - Mark rework, risk, and a simple baseline before proposing changes. - Keep the current-state map separate from any proposed future process.
Set the boundary before drawing
Choose one identifiable job, not a department-wide label such as “finance” or “customer operations.” Define the event that begins the work and what must be true for this part of the process to be complete.
For example, “supplier invoice handling” is broad. A clearer boundary might be: “from an invoice arriving in the shared mailbox to the invoice being approved for payment or returned for clarification.” That boundary leaves the later process of scheduling and making payment outside the map.
Write down four things before the mapping session:
- Trigger: What starts this instance of the work?
- End state: What result marks this part as complete?
- Included: Which steps, people, and systems are in scope?
- Excluded: What happens before the trigger or after the end state?
The Local Partnerships Business Process Mapping toolkit was developed with the UK Ministry of Housing, Communities and Local Government for procurement teams. Its mapping approach starts by selecting a process and gathering the people who perform, manage, or contribute to it. This is a useful method to adapt, not a universal standard for every business.
Bring together the people who see different parts
The person who owns a process may know the intended route. The person who handles the daily work may know the workaround. The person receiving the output may know what is regularly missing. Those are different views of the same workflow.
Invite people who perform the steps, provide inputs, make decisions, receive the output, handle exceptions, or support the systems involved. Ask them to describe a recent case, rather than only how the process is supposed to work. Include at least one case that went smoothly and one that required a detour.
This is not an exercise in judging individual performance. The goal is to see the path end to end, including work that disappears between team boundaries. GOV.UK Service Manual guidance on mapping a user's whole problem recommends working with people involved in delivering a journey and considering both user-facing touchpoints and backend processes. For an internal business workflow, the same distinction helps: map the work the operator does and the experience of the person waiting for the result.
Record what happens, not what should happen
Make the first diagram an as-is map: a record of the current process, not a design for the better version. Use one card or row for each action. Keep the wording concrete.
“Review invoice” is hard to verify. “Compare the invoice total with the purchase order in the finance system” says what action happens, what information is used, and where it happens.
| Capture | Prompt |
|---|---|
| Action | What does the person or system actually do? |
| Owner | Who performs it, makes the decision, or receives the handoff? |
| Input and output | What information arrives, and what changes or leaves? |
| System or channel | Which application, document, mailbox, or conversation is involved? |
| Decision and exception | What choices are made, and what happens off the normal path? |
| Wait or rework | Does the work pause, repeat, or return to an earlier step? |
Show decisions as branches. If an invoice can be approved, returned for more information, or escalated, draw each route. Do not hide exceptions in a note at the bottom; they can contain important work and human judgment.
Illustrative example: supplier invoice intake
This generic illustration is not a client case.
An invoice arrives in a shared mailbox. An administrator checks whether the required details are present, then looks up the supplier and purchase order in separate systems. If the details match, the invoice goes to an approver. If an amount or supplier detail differs, the administrator asks for clarification or routes the case to finance. After approval, the invoice moves to a payment queue.
A useful map gives each action its own step, names who does it, and shows which system is used. It also marks where an invoice waits for a response, whether information is copied between systems, and what happens if the purchase order cannot be found. Check this description against actual permitted examples before treating it as a map of your process.
Validate the map against real cases
A workshop map is a hypothesis. Check it against a few recent cases with the people involved. Include a routine case and examples with missing information, a changed approver, a system error, or another exception that actually occurs.
For each case, ask whether the steps happened in the order shown, whether any handoff or informal check is missing, and whether someone used a workaround outside the formal route. Ask the person receiving the work whether the output contained what they needed. If the evidence disagrees with the first description, update the map.
NIST's AI Risk Management Framework Core describes its Map function as establishing the context for understanding risks related to an AI system. It says that context and perspectives from relevant people can inform an initial decision about whether to design, develop, or deploy AI. NIST's Map function is AI-risk guidance, not a business-process mapping recipe; here it supports the narrower point that context matters before designing an AI system.
The map does not need to be a polished diagram. It needs to be accurate enough for the people doing and receiving the work to recognize it and correct it.
Mark waiting, rework, risk, and a baseline
Once the route is clear, annotate what the cases showed. Mark where work waits, where information is entered more than once, where a case returns for correction, and where a person must use judgment.
Keep observations separate from explanations. “The case waited for an approval” is something participants can verify. “The approval took a long time because the approver is overloaded” is a cause to investigate. Do not turn an assumption into a fact because it sounds plausible.
Choose a small baseline that lets the team compare a later change with the current process. Depending on the task, this might be elapsed time from intake to completion, the number of handoffs, the number of corrections, or the share of cases requiring clarification. Note how it is measured and which cases are included. A baseline is useful only if the team can collect it consistently and interpret it in context.
Mark decisions where an error could matter, such as a payment, eligibility decision, customer communication, or disclosure of sensitive information. These points may need clearer ownership or review even if the team makes no technology change.
Simplify the process before choosing technology
An as-is map may reveal a problem that does not need a model. There may be a duplicate approval, unclear ownership, a form that omits a required field, or two systems that do not share basic information. Fixing one of those may be a better next step.
Keep the original as-is map. Draw a separate to-be map for the proposed process, then compare the two. Show what changes, what remains under human control, and how exceptions will be handled. If AI is being considered, mark the precise task it would support, what information it may use, who checks its output, and what happens when it cannot produce a usable result.
The template below is a starting point, not a notation standard. A shared document, sticky notes, or a whiteboard can work just as well if the people doing the task can correct it.
```text AS-IS WORKFLOW
START: [trigger] END: [completed outcome]
[Step 1] → [Step 2] → ◇ [Decision?] ── yes ──→ [Step 3] → [End] └── no ──→ [Exception owner] → [Next action]
For every step, add: OWNER | INPUT → ACTION → OUTPUT | SYSTEM / CHANNEL WAIT OR REWORK | RISK / CHECK | EVIDENCE FROM A REAL CASE ```
Keep the map useful after the session
Store the map where process owners can find and update it. Note who checked it and when. Revisit it when a system, policy, team responsibility, or workflow changes materially. A map that describes an old process can mislead the next person who relies on it.
Before moving on, confirm that the people doing and receiving the work agree the map is recognizable, exceptions have owners, and the baseline can be measured. If those points are unclear, resolve them before designing an AI-assisted version.
A workflow map is not an AI business case. It is evidence about the work. It can help a team decide whether to simplify, connect systems, change a rule, test AI on one bounded step, or leave the process as it is. If the team decides the workflow may need a technology change, see how a project runs, or bring the map and open questions to a discovery conversation.