Map the Work Before You Automate It

PathPatron Use-Case Canvas series — 4 of 7

Most automation proposals begin with an imagined future. The PathPatron Work Map begins with the work that is actually happening: the emails, hand-offs, local spreadsheets, approvals, exceptions and invisible decisions that a tidy process diagram tends to omit.

That is not bureaucracy. It is how a team avoids automating confusion at speed.

Follow one real case across the organisation

Take one recent supplier onboarding request. Procurement receives a request by email. A document is saved in a shared drive, some details are copied into a spreadsheet, Legal asks for a missing clause, Finance cannot create the vendor record without verified bank data, and the business requester asks why nothing is moving.

Map the case step by step as it happened—not as the policy says it should happen. Include:

• each person or team involved;
• every system, inbox, spreadsheet and shared folder;
• hand-offs and approvals;
• missing information, re-entry and waiting;
• undocumented review or judgement;
• the point where an exception changes the normal route.

The map is complete only when the team can explain how a real case gets from request to result, including its loops.

Continue the supplier-onboarding case: let the map form, not appear

The evidence from Articles 1–3 does not disappear when the Work Map starts. It becomes the first layer of the map.

Take the same supplier request. At 09:07, Procurement receives an email asking for a supplier to be activated before a project milestone. The requester attaches two documents. Procurement opens the shared spreadsheet, creates a line and asks the supplier for bank data. That is the first card—not “supplier onboarding,” but one real request, one person, one time and one consequence.

At 11:20, Legal finds the required clause is absent. The card does not simply move forward: it returns to Procurement with a missing-evidence marker. At 14:10, the supplier sends bank details to a different inbox. Finance sees them only the next day, fails a validation check and the business owner asks for a delivery date that nobody can safely promise.

Now the map has begun to say something useful. It is not a neat policy flow. It is a living sequence of evidence cards, owners, systems, waiting time and a rework loop. Add each card only when it can be tied to a real observation. Place the card in the lane of the person or team doing the work; connect it to the next hand-off; add a loop whenever the case returns because information, authority or a decision was missing.

The Canvas continues: stakeholder evidence becomes a current-state route. The loop is not a mistake in the drawing; it is the operational reality the team must decide whether to change.

Mark the breakpoints

In the Work Map, a breakpoint is where value, context, authority or time gets lost. Typical signals are:

• the same data is entered in two systems;
• a case waits because the next owner is unclear;
• a reviewer lacks the source evidence needed to decide;
• an approval is performed through an informal message;
• an exception creates a private workaround;
• a team cannot tell whether a case is complete.

Supplier onboarding usually exposes all six. HR onboarding may reveal a different pattern—HRIS, IT access, security and payroll each need a different trigger. An invoice discrepancy may expose conflicting data between accounts payable, a budget owner and the supplier. The point is not to create a perfect universal diagram; it is to see the operational seams.

Make the cost of not solving visible

Do not jump from a map to a solution. First capture the cost of the current state:

• client or internal requester waiting time;
• employee time spent chasing, copying and rechecking;
• current tool and licence costs;
• error, compliance or supplier-risk exposure;
• opportunity cost when a project is delayed or a client chooses another provider.

Use evidence where available: case timestamps, backlog size, rework counts or sample cases. Where numbers are uncertain, state the assumption and assign an owner to validate it. A transparent estimate is more useful than false precision.

The PathPatron Work Map

The map moves in one direction:

Person’s pain → involved people → current process → breakpoints → cost of not solving → future-state options → cost of solving → decision.

Requirements run alongside the entire map. Capture constraints when they appear: system/API dependencies, data classification, deadlines, regulatory obligations, decision rights and exception routes. Do not treat requirements as a document written after the process is forgotten.

A practical 45-minute working session

This is not a generic “map the process” meeting. It is a short working session around one real case, with evidence in view and an owner who will validate what the room cannot prove.

Before the session: prepare the case, not the answer

Choose one recent completed or stalled case. Ask the case owner to bring the request, timestamps, relevant emails or tickets, systems touched and any exception or escalation. Invite the people who actually carried the hand-offs—normally three to six people, not a large steering group. Send a one-line brief: we are mapping what happened in this case, not designing the future solution today.

An approved AI tool can prepare a first-pass question pack, never the map itself. Give it anonymised notes and ask it to produce a table of: observed step; actor; system; input; output; evidence; uncertainty; likely hand-off; and question to validate. It must label every line Evidence, Hypothesis or Information gap. The stakeholders then correct, remove or confirm it in the session. Do not upload contracts, personal data or sensitive supplier information to a tool that is not approved for it.

In person: one wall, one case, one visible route

Print or display the Work Map background below. Begin with the request in the first zone. Let the person who did the work tell the story in chronological order while a facilitator adds a card for each step. Use one colour for verified evidence, one for a hypothesis and one for an open question. Do not resolve disagreements in the moment; pin them to Evidence to validate with a named owner.

At minute 25, stop the narrative and mark: waits, loops, re-entry, informal approvals, missing context and moments where a human made judgement. At minute 35, ask the group to estimate the cost of the two or three material breakpoints. At minute 42, agree what will be checked after the session, by whom and by when.

Online in Mural or Miro: use the same discipline

Create one board per case, not one giant board for the programme. Place the background image below as a locked base layer. Give each participant a cursor colour and ask them to add their own cards only to the lane they know. The facilitator follows the same order: real case → people → steps and hand-offs → loops → cost → evidence to validate. Use a short silent-write period before discussion so the loudest person does not define the map.

Use this as a locked background in Mural or Miro, then add your organisation’s own cards on top. The template is deliberately a surface for evidence, not a finished process diagram.

The 45-minute agenda

Time	Facilitation move	Tangible output
0–5 min	Name the real case, triggering event and why it matters now.	One bounded case statement.
5–12 min	Put the people and roles around the case; check against Articles 1–3.	Named role lanes and missing voices.
12–25 min	Replay the case step by step, across systems and hand-offs.	A current-state route, not an ideal-state flow.
25–35 min	Mark waits, loops, lost context, informal workarounds and judgement calls.	A breakpoint list with visible uncertainty.
35–42 min	Capture the cost of not solving: time, rework, risk, delay or missed value.	Evidence-backed estimates and assumptions.
42–45 min	Assign validation owners and choose the next decision.	Evidence log, named owner and next review date.

The output is not a workshop artefact. It is a current-state record, a breakpoint/evidence list and a shared basis for choosing what should change.

Make it a leadership practice, not a lucky one-off

The test is not whether one facilitator can run a beautiful workshop. The test is whether the organisation can make better change decisions six months later.

Set a proportional intake rule: every material AI, automation or workflow proposal needs a one-page Work Map before tool selection or pilot funding. Keep one maintained template, a shared evidence log and a small portfolio view of active maps. Make the business owner—not the innovation team—responsible for validating the current state and keeping the map current when a system, policy, control or stakeholder changes.

Review the portfolio monthly. Ask: which maps are based on evidence, which have unresolved assumptions, which breakpoints recur across cases, and which requests should be stopped because there is no safe or owned path forward? This makes mapping part of operating governance, not a workshop ritual someone remembers only when a project is already in trouble.

Use AI to lower the administrative burden: structure notes, flag contradictions and prepare a validation list. Keep human accountability where it belongs: deciding what actually happened, what is acceptable and what may change.

Mapping is not modelling

Mapping answers: what happens now? Modelling answers: what could happen instead, under real constraints? Do not turn the current-state map into a wish list. The next article, From Current State to Future State Without Magical Thinking, compares credible options and their cost of solving.

PathPatron’s test is simple: if you cannot explain where a case waits, who decides and what information crosses the boundary, you are not ready to delegate it to an automation or an agent.

Continue the PathPatron Use-Case Canvas

• 1/7: People, Stakeholders and Targets: Whose Problem Are You Solving?
• 2/7: Map Power, Interest and Pain Before You Pitch AI: The Stakeholder-Pain Map
• 3/7: From Pain Point to a Real Use Case
• 4/7: Map the Work Before You Automate It — you are here.
• 5/7: The Cost of Not Solving: Making Process Pain Visible
• 6/7: From Current State to a Credible Future State: Cost, Control & Change
• 7/7: Requirements Engineering for AI-Enabled Work