Guide · See
How to map a process for AI: people, systems and docs
A step-by-step method to map how a workflow really runs, from interviews, system data and documents, with an interview guide and a checklist for every step.
The short answer
To map a process for AI, pick one workflow and record how it really runs, not how its SOP describes it. Combine interviews with everyone who does the work, data from the systems of record and the documents, and check each source against the others. Capture every step, decision, handoff, wait, loop and exception, with its app, volume and time, so each step can be sorted into delete, plain code, agent or human.
Key takeaways
- Map the work as it is really done, not as the SOP describes it. An agent built on the document breaks on everything the document leaves out.
- Combine three sources and check them against each other: people explain why, systems show what happened and how often, and documents show how the work was meant to run. Talk to more than one person in every role.
- Give every step a row: who does it, in which app, what is decided, how often and how long. A finished map can be sorted into delete, plain code, agent or human, and it stays current as the work changes.
What is a process map for AI?
A process map for AI is a step-by-step record of how one workflow really runs. For each step, it shows who does it, in which app, what they decide and why, where the work waits or loops back, how often it happens and how long it takes. It needs enough detail to show which steps to delete, which to run as plain code, which to give to an agent and which to keep with a person.
The common shortcut is to scope the work from the standard operating procedure (SOP). Daniel Kornum of Varick Agents, a firm of forward-deployed engineers, describes where that leads: teams build for the SOP and ship, and what they built collides with the real workflow, which differs from the documented one “in 50 places.” Built for the document, an automation handles about 70% of the volume and breaks on the other 30%, and fixing those breaks can leave the team with more work than before.
So map the work as it is done. Forward-deployed engineers (FDEs) do it by combining three sources: the people who do the work, the systems of record that log it, and the documents that say how it should run. Each source checks the others. On The Startup Ideas Podcast, Varick’s CEO, Vasuman Moza, said that system data without interviews misses half the picture.
An operations leader can run the same method on one workflow at a time:
- Choose one workflowSet where it starts and ends, who owns it and what is in scope.
- Gather three sourcesInterview the people, pull the system data and read the documents.
- Compare themWhere people, systems and the SOP disagree, find out why.
- Capture every stepWho, which app, what is decided, how often and how long.
- Sort it, keep it currentReady for the four buckets, and updated as the work changes.
How do you choose a workflow and set its boundaries?
Start with one workflow that runs often, takes real time and has an owner who wants it fixed. Varick’s FDE course advises prioritizing “lengthy, high-volume workflows” where the improvement is large enough to matter, and Moza says his team picks processes that have owners.
Then write down the boundaries before the first interview:
- The start. The event that opens a case, such as a quote request, a new invoice or a fixed time, like Monday morning for a weekly review.
- The finish. What “done” means, and who receives the result.
- The scope. Which teams, regions, products and kinds of case are in. If regions work differently, map one first.
- The people. The accountable owner, and everyone who touches a case along the way.
- The window. At least one full cycle of the work, exceptions included: four Mondays for a weekly review, one month-end close for a monthly process.
Boundaries keep the job small enough to finish. They also tell you which systems to pull data from and which documents to read.
How do you interview people about how the work really runs?
Interview everyone who touches the work, more than one person in each role, and ask about real recent cases rather than the typical one. Much of the know-how is unwritten. Moza says companies of every size depend on people who carry it in their heads, like someone who has been at the firm for 20 years and simply handles it. That is key-person risk, and the interviews are where you find it.
Start with the leaders of one department. Moza’s advice for finance: talk to the heads of accounts payable, accounts receivable, reconciliations, billing, banking and FP&A, then work your way down to the people who do each task.
Talk to more than one person because each one knows a different version of the work. Kornum notes that reps on the same sales team can qualify a lead in different ways, and Moza warns that one person “might tell you the wrong story.”
People also choose what to tell you. The psychologist and human factors specialist Steven Shorrock calls this work-as-disclosed: what people say about their work, which is partial and shaped by what they expect to happen next. Where people fear blame for workarounds, they say less. Where trust is high, what people say and what they do overlap more. So explain why you are mapping, welcome workarounds as useful findings, and treat the people who do the work as the experts they are.
Then watch. Kornum describes the audit as sitting with the people doing the work and watching them do it. Ask someone to work a live case while you follow along, and note every step, app and pause.
| Ask | What it shows you |
|---|---|
| “Walk me through the last one you did, from start to finish.” | The real steps, in order, including the ones nobody thinks to mention. |
| “What starts it, and how do you know it’s done?” | The boundaries: the trigger, the finish line and who gets the result. |
| “Which apps, files and messages do you use at each step?” | Where the work happens, and the copying between tools. |
| “What do you decide here? Who has the final say?” | The decision points, the rules behind them and who really decides. |
| “Where do you wait, and for whom?” | Handoffs and queues, where much of the time goes. |
| “What goes wrong, how often, and what do you do then?” | Exceptions, workarounds and loops back to earlier steps. |
| “Which steps would you drop if you could?” | Steps that exist only for show, and candidates to delete. |
| “What do you know that isn’t written down?” | Unwritten rules, and know-how that lives in one person’s head. |
| “Who does this differently from you?” | The next person to interview. |
How do you use system data and process mining?
Use the records your systems already keep to check what people told you and to count what they can’t. Systems of record log events: a deal changes stage, an invoice is approved, a ticket is reassigned. Process mining rebuilds the real flow from these event logs. The IEEE Task Force on Process Mining’s manifesto describes the raw material: each event refers to a case and an activity, often with a timestamp and who did it.
That is enough to see what interviews can’t: how many cases take each path, how often work loops back and how long it waits. Moza described one Varick engagement at a public software company with $5 billion in revenue. Its process document listed seven steps to get a quote signed. Process mining on its CRM found 20 steps and seven loops:
- In 61% of requests, the work looped from the fourth or fifth step back to the first.
- Legal sent quotes back 12% of the time.
- In 30% of cases, a new quote had to go through approval again.
Start from questions, not from data. The manifesto’s second guiding principle is that log extraction should be driven by questions: an ERP such as SAP has thousands of database tables, and without concrete questions you can’t pick the right ones. Your interviews supply the questions. Which path do most cases take? Where do they loop? Where do they wait?
Check what your systems actually record. In Salesforce, for example, field history covers the fields someone chose to track, starting on the day tracking was turned on, and is kept for up to 18 months, or 24 months through the API, unless Field Audit Trail is on.
And know what logs miss. Work done in email, spreadsheets and chat leaves no event in a system of record, and no log says why someone made a choice. That is why Moza’s team pairs the interviews with three to four weeks of live CRM data, which shows what enters the system and how often it is corrected. Where there is little system data, as in many smaller companies, interviews carry more of the weight. Task mining, which records what people do on their screens and should run only with their consent, can fill part of the gap; see how the approaches compare.
How do you compare the SOP with what really happens?
Collect every document that describes the workflow, list the steps it prescribes, and lay them over what people described and the systems recorded. Every step that shows up in only one source is a finding. Look beyond the SOP: Moza points to SharePoint, Notion, Slack, Teams, Gmail and spreadsheets, and finds the documents there sometimes outdated and sometimes good.
The difference between the written process and the real one has a name. Kornum calls it the conformance gap. In typical Varick engagements it is 30% or more. In exception-heavy work, such as accounts-payable exceptions or responding to supply-chain disruptions, it is routinely over 70%. The split is an old one: Shorrock traces the distinction between work as prescribed and work as done to French ergonomics in the 1950s.
The gap is made of small, sensible things. Kornum’s examples include always checking one spreadsheet first, emailing a colleague directly because a system notification doesn’t work, the 17 types of exception a team handles every month, and an unwritten rule that anything over $5 million loops in the controller.
Here is the comparison on an illustrative workflow: the weekly revenue review from Nolli’s product demo. The SOP lists five steps. Four observed Mondays show 20 steps across five apps. Eleven were never written down, and four redo earlier work.
The SOP says
5 steps
- Gather
- Reconcile
- Build deck
- Review
- Send
Four Mondays show
20 steps across 5 apps
- 5 in the SOP
- 11 never written down
- 4 redo earlier work
- One observed step, in the app where it happens
- Redoes an earlier step
Show the data
| Step | App | Redoes | Note |
|---|---|---|---|
| 1 | Gmail | — | — |
| 2 | Slack | — | — |
| 3 | Salesforce | — | — |
| 4 | Salesforce | Step 3 | re-export |
| 5 | Google Sheets | — | — |
| 6 | Slack | — | — |
| 7 | Gmail | — | wait on Finance |
| 8 | Google Sheets | — | — |
| 9 | Google Sheets | — | — |
| 10 | Google Sheets | Step 9 | redo |
| 11 | Google Slides | — | — |
| 12 | Google Slides | — | — |
| 13 | Slack | — | — |
| 14 | Google Slides | — | merge 6 versions |
| 15 | Salesforce | — | — |
| 16 | Google Slides | Step 11 | — |
| 17 | Slack | — | ask the lead |
| 18 | Google Slides | Step 12 | — |
| 19 | Gmail | — | — |
| 20 | Gmail | — | — |
Follow the line and you can see people carrying the work by hand: a re-export in Salesforce, a wait on Finance by email, a redo in Google Sheets, six versions of the deck to merge, and a question for the lead in Slack. None of it is in the SOP. Before you judge a step, ask why it exists. Some steps patch a broken handoff and can go. Others hold real judgment, such as how renewal exceptions are decided, which the SOP should have described all along.
What should a process map for AI capture for every step?
Give every step its own row, with enough detail to decide what should happen to it: the step, who does it, where, what kind of step it is, what is decided, how often it happens and how long it takes.
- The step, as a verb and an object: “Export closed-won deals.”
- Who does it, by role, and who else is involved.
- The app, file or channel where it happens.
- The kind of step: task, decision, handoff, wait, loop back or exception.
- For a decision: the rule, who has the final say, and why.
- What goes in, what comes out, and where the output goes next.
- How often it happens, and how often it goes wrong.
- Hands-on time and waiting time, measured separately.
- How you would check that it was done right.
- Where the know-how lives: in a document, or in one person’s head.
Spend the most time on decisions. Write down who really decides, the rule they apply and the reasons they give. Moza’s interview questions start there: why people work the way they do, who really decides, which steps are theater, what happens when exceptions occur and how often they do. Decision points are where an agent may help, and where a person often needs to stay.
Then measure. For each step, count how often it happens and how often it goes wrong, and time the hands-on work and the waiting separately. Waiting needs its own number. Moza, citing Michael Hammer’s work on reengineering, argues that speeding up each step may not make a process faster, because so much of the cycle time sits between steps, as work passes from one person to the next. In the revenue review, four observed Mondays put the work at two and a half hours each Monday, with six people involved. Record a baseline like this before you change anything, so you can prove the result later.
You don’t need special notation. A table with one row per step is enough, and you can draw it as a swimlane diagram, with one lane per person, team or app, as in figure 3. If your teams already use BPMN, the Object Management Group’s standard for business process diagrams, keep it: lanes group the work, rounded boxes are tasks, diamonds are gateways where the path splits or joins, and circles are events, such as a message arriving. BPMN offers more than 50 graphical elements, the process mining manifesto notes; a map for AI needs only a handful.
A map is ready when every row can be sorted into one of the four buckets: delete it, run it as plain code, give it to an agent, or keep a person on it. Sorted that way, the revenue review loses nine of its 20 steps. Five become plain code, four go to an agent, and two stay with the revenue ops lead. Then test each change on your own cases before it goes live; see how to benchmark AI on your own work.
How do you keep a process map current?
Treat the map as a living record. Processes change while you study them: the process mining manifesto calls this concept drift, observes that few processes are in a steady state, and advises against treating process mining as a one-time activity. AI adds its own churn. Kornum’s six-month plan for an enterprise AI deployment assumes both will move: the model market will change next quarter, and so will your workflow.
Refresh the map when something underneath it moves:
- A system, form, policy or approval threshold changes.
- A team reorganizes, a key person leaves, or a new region or product joins.
- The system data shows a new path, a new loop or a longer wait.
- An agent takes over a step, so the map shows what it does and who checks it.
Keep the map where people and agents can both use it. Written from how the work really runs, it becomes the SOP, the training for new hires and the instructions for any agent. OpenAI’s guide to building agents recommends writing an agent’s instructions from existing operating procedures, support scripts and policy documents. If the SOP is out of date, the agent starts out of date too. Write the SOP from the map, not the map from the SOP.
Keep the people who do the work as its owners. They notice first when the work changes, and the know-how stays with your company. A map also lines up the people who build with the people who do the work. Kornum’s verdict on the audit:
“The document itself matters less than the alignment it forces”
— Daniel Kornum, Varick Agents
Questions people ask
What is the difference between process mapping and process mining?
Process mapping is the whole job of recording how a workflow runs, from any source: interviews, observation, documents and data. Process mining is one technique within it: software rebuilds the process from the event logs of business systems. Mining is exact about what systems record; mapping adds the work done outside them and the reasons behind each step.
How long does it take to map a process?
Long enough to see a full cycle of the work, exceptions included: several weeks for a weekly workflow, at least one month-end close for a monthly one. Varick Agents, for example, spends at least four weeks auditing how a workflow really runs before it touches a model.
How many people should you interview?
Everyone who touches the work, and more than one person in each role, because each person knows their own version of it. Start with the head of each function and work down, then check what people tell you against the system data.
Do you need BPMN to map a process for AI?
No. BPMN is the standard notation for business process diagrams, and it is worth keeping if your teams already use it. What matters for AI is the detail behind each step: who does it, in which app, what is decided, how often and how long. A table with one row per step holds that, and you can draw it as a swimlane diagram.
What if a workflow has little or no system data?
Then interviews, observation and documents carry the weight. Ask people to work through recent real cases while you watch, time each step, and collect the emails, spreadsheets and messages each case touched. If you will need the data later, start recording it now, for example by turning on history tracking for the fields that matter in your CRM.
Who should own the process map?
The team that does the work, with one accountable owner. Forward-deployed engineers or consultants can speed up the first map, but the people closest to the work notice first when it changes, and the know-how should stay with them.
Sources
- Daniel Kornum. “If AI is so great, why isn’t it working?” Varick Agents.
- Greg Isenberg, with Vasuman Moza of Varick Agents. “Become a $1M/yr FDE (Full Course).” The Startup Ideas Podcast, October 1, 2026.
- “AI Forward Deployed Engineering: The blueprint to breaking into FDE in 30 days.” Varick Agents.
- Steven Shorrock. “The Varieties of Human Work.” Humanistic Systems, December 5, 2016.
- IEEE Task Force on Process Mining (Wil van der Aalst et al.). “Process Mining Manifesto.” Business Process Management Workshops (BPM 2011), Springer, 2012.
- “Field History Tracking Overview.” Salesforce Help, accessed October 4, 2026.
- “Business Process Model and Notation (BPMN), Version 2.0.2.” Object Management Group, January 2014.
- “A practical guide to building agents.” OpenAI, accessed October 4, 2026.