AI can draft a process map in minutes. The part that makes it true is the people who do the work correcting it. Here is the method, the prompts and a worked example.
Treat the AI draft as claims to check. Gather three accounts of the work, have AI draft the map and label what it assumed, walk it with the people who do the work, mark where it waits, and only then choose where AI helps. Prompts, a worked invoice example and a candidate register are included.
A process map built from an SOP, or from one manager’s account of the work, usually shows the path where everything goes right. The work that eats the time sits somewhere else: the approval that arrives as a chat message, the invoice that lands in a personal inbox and gets forwarded days later, the rework loop everyone knows about and nobody has drawn. The people doing the work carry that knowledge, which is why a map made without them tends to get a polite nod in a meeting and then sit in a folder.
AI makes the drawing part fast. Hand it interview notes and a procedure document and it returns a tidy flowchart with owners and decision points in a couple of minutes. That helps, and it adds a risk, because a tidy diagram looks finished and a finished-looking map gets questioned less than a messy whiteboard does.
The method in this guide treats the AI draft as a set of claims about the work. The people who do the work check those claims, and the corrected map then shows where AI could help and where it shouldn’t be used at all. There are five passes.
A process map is a draft until someone who does the work has corrected it.
The method in this guide, a Future Factors working method rather than a published standard. In our judgment pass 3 does most of the work of making the map accurate.
A map sits between two neighboring jobs. The workflow diagnostic helps you decide which workflow deserves attention, and how to use AI to write SOPs covers the written procedure. The map describes how the work runs today, so both start from something true.
The quality of the map is set by what you feed it. A procedure alone gives you the documented process, and one interview gives you one person’s version. My judgment is that the strongest base is three accounts of the same work: the written procedure if one exists, a conversation with someone who does the work now, and a recorded walkthrough where that person narrates a real case from start to finish with the inbox or screen open.
The walkthrough matters most, because people explain work differently while they’re doing it. An accounts payable clerk asked to describe invoice approval gives the standard version. Asked to show the last invoice they handled, the same clerk opens the inbox and the exceptions start appearing, like the invoice that needed a second approver.
Who you capture depends on the process. For invoice approval it’s a clerk and a budget holder. For onboarding a new hire it’s an HR coordinator and a hiring manager, and for customer onboarding a customer success manager and whoever handles the technical setup. Pick the person who handled the most recent case, not just the person who owns the process on the org chart.
Before anything goes into an AI tool:
The prompt below asks for one row per step, with a role, trigger, system, output and source. Trigger, waiting and source are the fields people tend to leave blank. It also asks the model to say what it assumed, which protects you in the next pass.
Paste your three accounts under the prompt. The ASSUMED and UNOWNED labels become the agenda for the walk-through.
Put the three accounts into your approved tool with the prompt and read what comes back as claims. A useful first draft separates what people said from what the model joined together, and points at single-source steps, steps with no owner and places where it had to guess.
The research here is encouraging and narrow. In a 2024 arXiv preprint, Kourani and colleagues gave 16 language models written process descriptions of 79 to 230 words and asked for process models back, and they saw large differences between models.[3] The descriptions were short and clean, and the test covered the order of steps only, not who does them or which systems they touch. My reading is that this supports using AI to structure a clear account, and says little about whether it will notice what a messy account left out.
Ask for the map as text as well as a table. Mermaid is a diagramming tool that renders diagrams from text definitions, and its flowchart syntax writes a decision as a diamond and lets lines between steps carry labels such as Yes and No.[1][2] A text map has a practical advantage. You can paste it back into the chat with a correction, say a rework loop from approval back to coding, and get a changed version whose edits anyone can read.
Mermaid code for the first half of the invoice example. Paste it into a Mermaid renderer, or ask the AI to redraw it after each correction.
Which format you use depends on what happens next. Use text when the map will change a lot, a whiteboard when a room full of people will change it, and a plain table when the questions are about owners and systems rather than sequence. Text maps get cramped as a process grows, so split a big one by trigger or by role.
Miro’s help center describes generating a diagram on a board from a typed description.[4] That’s the vendor’s account of its own feature, and I haven’t tested it. I couldn’t verify other drawing tools’ features against their documentation, so I’ve left them out.
Take supplier invoices that arrive without a purchase order. The written procedure runs to a handful of steps, and the AI draft built from it is clean: log the invoice, code it, get approval, pay. After a walkthrough with an accounts payable clerk and a short conversation with a budget holder, the same map gains several things the procedure never mentioned. The diagram marks which steps came from which source.
The finished map for a non-PO supplier invoice. Solid borders came from the written procedure. Dashed borders were added by the people who do the work. Labels mark where the work waits and where AI could help.
None of the dashed boxes were in the document, so the model had nothing to draw them from. The map now shows two things the procedure hid: an invoice can sit in a budget holder’s own inbox before the clerk sees it, and the reference and the approval both travel by chat, so nothing records when they were asked for or given.
A finance lead reading the revised map tends to notice that the longest gaps sit between boxes that each look quick. Coding takes minutes and so does approval, once someone opens it. The waiting around them is where an invoice spends most of its life, and it was invisible until someone drew it.
The walk-through is the pass that turns a diagram into a map. Book about 30 minutes with the person who does the work and a shorter slot with whoever approves or receives it. Read the draft out one step at a time. Don’t ask whether it looks right, because people say yes to tidy diagrams. Ask them to trace the last real case through it.
A process owner reading step three aloud will often see the person across the table wince before the sentence ends. Stop there, ask what actually happens, and write the answer down in their words before anyone tidies it.
| Ask | What it catches |
|---|---|
| Trace the last one you handled from the moment it reached you. Where does that differ from this map? | Missing steps and shortcuts |
| What do you do when information is missing or wrong? | Exceptions and rework loops |
| Where do you wait on someone else, and how do you know you can carry on? | Hidden waits and informal handoffs |
| Which steps happen outside the system, in email, chat or a spreadsheet? | Unrecorded approvals and shadow steps |
| Which step would you skip if nobody checked? | Steps that exist for a reason nobody remembers |
| Who else touches this that isn’t on the map? | Missing owners |
Six questions for the person who does the work. Take the corrections away verbatim and feed them to the AI in the next prompt.
Then give the corrections back to the model, with instructions that stop it from tidying conflicts you haven’t resolved.
The change log is what the process owner signs. Reading the new diagram on its own makes it easy to miss what moved.
The person who does the work corrects the map, the process owner signs it, and a manager or sponsor decides what, if anything, gets built from it.
| What AI does | What the human still owns | How it gets checked |
|---|---|---|
| Structures three accounts into a step table and a text map, with a source for each step | Deciding which account reflects how the work really runs | The person who handled the last case traces it through the map |
| Flags single-source steps, unowned steps and assumed joins | Naming the owner of each step, or deciding the step shouldn’t exist | No ASSUMED or UNOWNED label left at sign-off, unless the owner accepts it in writing |
| Applies corrections and keeps a change log | Approving each change and signing off the map | The process owner reads the change log, not only the new diagram |
| Suggests which steps could use AI | Scope, risk, and what data AI may touch | Reviewed with the team lead, and with data protection where personal data is involved |
The human-ownership split for the mapping work. The same split applies later to any step you hand to AI.
People map activity and skip the gaps, even though in many office processes the gaps are where the time goes. If the process runs through a finance system or ticketing tool, its timestamps will show where they sit. Where it doesn’t, ask the person who does the work how long a typical item waits at each handoff and mark the answer as an estimate.
Map the waiting as carefully as the working.
With the waits marked, you can look for AI candidates, and the first question is not about AI at all. Some steps exist only because an earlier step was done badly. The requester’s missing reference in the invoice example is one of those. A model could draft a nicer reminder, but a required field on the request form would remove the wait.
Ask whether a step should exist before asking whether AI should do it.
For the steps that survive, the next prompt asks the model for candidates and for what stays human. Read the output as a shortlist to argue about, not a plan.
Run it only on a signed-off map. Steps still marked ASSUMED or UNOWNED are skipped on purpose.
| Step | What AI could do | What the human still decides | Verdict |
|---|---|---|---|
| Code the invoice | Suggest a cost center and account, with the reason | Final coding, and any new supplier or unusual amount | Pilot, with a sample check each week |
| Ask the requester for a reference | Nothing yet | Whether the control is still needed | Redesign first: put the reference on the request form |
| Approval by chat reply | Draft a reminder to the approver | Whether to approve | Fix the record-keeping first, AI is optional |
| Answer supplier payment queries | Draft a reply from the invoice status | Disputes and exceptions, and sending the reply | Pilot, with a person sending every reply |
A worked example of the shortlist. Two of the four verdicts say fix the process before adding AI.
When a candidate survives the argument, what to hand to AI first covers the criteria for a good first workflow, and the five-question test for operations pilots helps you judge whether it’s a real pilot or a good story.
Start small: one process, the person who does it, one approver, and a week.
To know whether the map was worth the effort, use the same lens we use for any AI change: use, persistence and impact.
Training builds the capability to run a good walk-through, and workflow design gives the finished map a real process to improve. Reinforcement is the owner reviewing the map every quarter, and adoption of any AI step is what you see afterward. A team can begin on its own with the prompts above. A facilitated session helps when several process owners need to map in the same format, because the walk-through is the pass people rush.
This week, pick one process and book 30 minutes with the person who handled the last case.
Yes, as a first draft. The model can join statements nobody connected, and transcripts can mishear terms. Ask it to label every assumption, and have someone who was in the conversation read the draft.
A process map describes how the work runs today. An SOP prescribes how it should run, and a workflow is a process arranged so that people or tools can carry it out step by step. Map first, so the SOP and any AI workflow are built on what really happens.
Detailed enough that each change of owner, system or decision gets its own step, and no more. If the map no longer fits on a page, split it by trigger or by role and map the handoff between the halves.
That depends on your organization’s policy and the tool’s data terms, so check both first. Use the approved tool, replace names with roles, and leave out customer, employee and financial details the map doesn’t need.
Review it on a fixed date, such as once a quarter, and whenever the team, the system or the supplier changes. Put the owner’s name and the last review date on the map itself, because a map without an owner drifts into describing a process that no longer runs.
The tool descriptions in this guide come from vendors’ own documentation, checked on October 5, 2026: Mermaid’s introduction and flowchart syntax pages, and Miro’s help page on AI with diagrams. I didn’t test either tool for this article, and I left out other diagramming tools because I couldn’t verify their features against current documentation. The one piece of research cited is a 2024 arXiv preprint by Kourani, Berti, Schuster and van der Aalst. Its authors say it covers the order of steps only, and it used short written descriptions, so it doesn’t speak to messy interviews. The Five-Pass Map, the three rules, the walk-through script and the candidate register are Future Factors working methods, not validated research. The invoice example is an illustration of how this kind of work tends to go, not a client story.