How to map process handoffs before adding AI automation

1. Set one case boundary before drawing boxes

Name the item moving through the process: one enquiry, order, supplier invoice, support ticket or approval request. Define the event that starts it and the result that ends it. “Handle customer enquiries” is too broad; “from a new website enquiry to an assigned next action” can be followed and checked.

Use one completed case as the spine of the map. NIST's AI Risk Management Framework Map playbook recommends defining the task, purpose, operating context, users, requirements and non-AI alternatives. That is a useful discipline even for a small internal review: understand the work before assigning a technology to it.

• Case: what single item are we following?
• Trigger: what creates the case?
• End state: what proves it is complete?
• Owner: who is accountable for the final outcome?

2. Walk a real case with both sides of each handoff

Ask the person doing the work to open a recent, suitably redacted case and narrate what happened. At each step, record the activity, role, input, tool and output. Then ask the receiving person what must be present before they can continue. A handoff is not complete when someone presses Send; it is complete when the next owner has usable information and knows what to do.

Do not turn the session into a performance review. The goal is to find how the process behaves, including workarounds that exist because the formal route is slow or incomplete. Avoid copying personal or confidential details into the map; use case references or anonymised examples and agree where the working notes may be stored.

• Who performs this activity?
• What information and permission do they need?
• What output does the next person receive?
• How does the next person know that action is required?

3. Separate active work from queues and waiting

Write two times where evidence exists: when work on an activity started or ended, and when the next activity began. This prevents a five-minute task followed by a two-day approval queue from being described as a two-day task. Also mark the reason for waiting: missing data, workload, an external response, a scheduled batch or an approval rule.

If systems retain event history, a small export can check the workshop map. Microsoft documents case ID, activity name and timestamps as the necessary fields for process-mining event logs; resource or department attributes can add context. A current-state table is not automatically an event history, so confirm what the source system actually records before promising tool-based analysis.

• Active handling time, if known.
• Waiting time before the next activity.
• Queue or dependency causing the wait.
• Evidence source: timestamp, ticket history, email or estimate.

4. Draw the normal path and the important variants

After the first case, review several more. Keep the most common route as the main path, but create branches for situations that change responsibility, risk or effort: missing documents, conflicting totals, an urgent request, a rejected approval or a customer who cannot be identified. Count what you can, but label a small sample as a sample rather than a measured frequency.

IBM defines a process variant as a unique path a case takes through a process and waiting time as the period between activities. This distinction matters because a rare path may consume most of the team's attention or be exactly where an automated rule fails. Do not hide rework inside one generic box called “process case.”

• Which path occurs most often?
• Where does work return to an earlier step?
• Which exception changes the owner or required approval?
• Which route exists only in email, chat or someone's memory?

5. Decide what should change before choosing AI

Review each friction point and ask four questions. Can a clearer input form remove missing information? Can a deterministic rule route the case? Could AI help extract, classify, summarise or draft where inputs vary? Or is human judgement the work itself? The best first improvement may be a required field, shared queue or system integration rather than an AI model.

Where AI is considered, mark its exact output, permitted data, receiving role and escalation condition on the map. The NIST playbook calls for documented human-AI roles and oversight responsibilities. For high-risk AI systems, Article 14 of the EU AI Act specifically addresses effective human oversight, including the ability to monitor, interpret, override or interrupt operation. Not every office workflow is high-risk, and this guide is not a legal classification; use qualified advice when the decision affects rights, safety or regulated obligations.

• Exact task proposed for AI support.
• Output a person or system will receive.
• Named reviewer with time, information and authority to act.
• Fallback when confidence, data or system availability is insufficient.

6. Finish with a review pack, not a decorative diagram

The useful output is a current-state map plus an issue list. For each handoff, retain the owner, required input, system, output, waiting point, common exception and available evidence. Add open questions and contradictions instead of smoothing them away. Ask the people who send and receive the work to confirm the map separately.

Then shortlist one bounded change and define what you would observe before and after it: fewer returns for missing information, shorter queue time, fewer manual transfers or more consistent routing. Do not present an estimate as guaranteed savings. A process review should make the next decision smaller and better evidenced, whether that decision is an AI pilot, ordinary automation, a process redesign or leaving a sound step alone.