How to Map a Business Process Before You Automate It

Pick one process with a clear trigger and a clear finished outcome, then walk three real recent cases through it with the people who do the work. For each step, note who does it, in which tool, with what information, how long it takes and how long it waits. Mark every decision and exception. One process takes two to four hours.

Map what actually happens, not what the procedures manual says, because the exceptions are where automations break. In the import-export example below, the clean path covered 31 of 48 orders in a month; the other 17 were part shipments, changed delivery addresses, missing certificates and a customer who always emails a photo of a printed order. A map without exceptions on it isn't finished.

Follow me on Instagram@sagnikteaches

Set the boundaries: one trigger, one finished outcome

Most mapping sessions go wrong in the first five minutes by trying to map "sales" or "operations". A mappable process starts with one event you could point to in a system and ends with one outcome you could check.

Connect on LinkedInSagnik Bhattacharya

Write the start and end on the top of the page. When someone in the session starts describing what happens after the invoice is paid, you can point at the boundary and park it for another map.

Subscribe on YouTube@codingliquids

Collect three real cases before anyone draws a box

Ask for three cases from the last month: one that went smoothly, one that was messy, and one that went wrong. Have the actual emails, order screens and spreadsheets open. Real cases stop people describing the ideal version, and the messy one shows you the exception paths straight away.

Questions that surface what matters, asked of each step:

• What tells you this step needs doing? (An email, a status change, someone shouting across the office?)
• Where do you do it: which system, spreadsheet or piece of paper?
• What information do you need, and where does each piece come from?
• How long does the work take, and how long does it usually sit before someone picks it up?
• When does this step go differently, and how often?
• What do you check before passing it on, and what happens if you get it wrong?

Record the session (with everyone's agreement). You'll use the recording in a moment to let AI do the note-taking.

A two-hour session for the import-export business ran to this agenda, which works for most processes of this size:

1. 10 minutes: agree the start and end, and name who does what.
2. 40 minutes: walk the smooth case step by step, with the real emails and screens open.
3. 30 minutes: walk the messy and the failed case, noting only where they differ.
4. 20 minutes: list every other variation people can remember, and who would know how often each happens.
5. 20 minutes: rough work and wait times for each step, and the one step everybody would like gone.

The last question is worth asking even though you won't act on the answer immediately. In this session, three of the four people named the same step (retyping orders that arrive as photos), which told the owner where goodwill for the project would come from.

Skipping the real cases is the most expensive shortcut in process mapping. Here is how it tends to show up: an owner sketches the order process from memory in six tidy boxes, a freelancer builds an automation to match, and in the first week nine orders fall out of it. Three were photos of printed purchase orders, four were part shipments, and two came from a customer whose PO numbers include a slash that broke the matching. None of those were on the six-box map, because the owner hadn't keyed an order personally in two years. The rebuild cost more than the original build.

Record each step in six columns

A table is easier to fill in than a diagram and holds more information. Here is an illustrative map for a nine-person import-export business that buys industrial fittings from overseas suppliers and sells them to trade customers from its own warehouse:

Two columns do most of the work later. "Information needed" tells you what an automation must read and where from; "Work / wait" tells you where the time really goes.

Draw it as swimlanes, with AI doing the first version

A swimlane diagram puts each role in its own horizontal lane, so hand-offs between people become visible as lines crossing lanes. Every crossing is a place where work waits and gets lost. You don't need to draw it by hand: paste the table into an AI assistant and ask for Mermaid, a text format that diagram tools can turn into a flowchart.

Convert this process table into a Mermaid flowchart (flowchart LR) with one
subgraph per role as a swimlane. Use a diamond for every decision.
Label each arrow with what is handed over. Output only the Mermaid code.
[paste table]

An illustrative fragment of what comes back:

flowchart LR
  subgraph Sales admin
    A[Read PO email] --> B[Check stock]
    B --> C{In stock?}
    C -- yes --> D[Key order]
    C -- no --> X[Back-order and tell customer]
  end
  subgraph Accounts
    E{Within credit limit?}
  end
  D -- order number --> E
  E -- yes --> F[Send confirmation]
  E -- no --> G[Hold and call customer]

In draw.io, which is free, go to Arrange, then Insert, then Advanced, then Mermaid, paste the code and insert it as an editable diagram (draw.io's Mermaid instructions). Check the result against the table: in the fragment above the model put "Send confirmation" in the Accounts lane, when sales admin does it. Diagrams generated from text are fast, and they need the same careful read as any other AI draft.

Mark decisions, exceptions and hand-offs

Go back through the three real cases and the last month's records, and count each variation. This exception log is usually the most valuable page of the whole exercise:

Seventeen exceptions from 48 orders means any automation that only handles the clean path would need a person for more than a third of the work. That's not a reason to stop; it's a design requirement. Each exception needs an answer: handle it automatically, route it to a person with the context attached, or fix the cause (such as asking the four photo-order customers to send PDFs).

Put numbers on the map

Add up the work minutes on the clean path: 71 minutes of hands-on time per order across four people. At 48 orders a month, that's about 57 hours of work. Now add the waits: roughly three and a half working days from PO to invoice. A day of that is the pick queue, a day is the gap before the invoice goes out, and five hours is the order sitting with accounts for a three-minute credit check.

That split changes what you automate. Keying the order (8 minutes) is the obvious target, but the five-hour wait at the credit check delays the customer more than all the typing combined, and the day-long invoice gap delays your cash. An automation that runs the credit check the moment the order is keyed, routing only over-limit orders to a person, and raises the invoice when the order is marked dispatched, cuts elapsed time more than any amount of faster typing. Without the numbers, the team would have automated the wrong thing first. These figures also become your baseline for judging the automation later, and feed straight into calculating the ROI of an automation before you build it.

Let AI take the notes, not do the thinking

Transcribe the session recording and ask an assistant to draft the six-column table from it:

From this transcript of a process-mapping session, draft a table with
columns: step, who, tool, information needed, work minutes, wait time.
Only include what was said. Where a value wasn't mentioned, write "?".
Then list every exception or workaround mentioned, with who mentioned it.

This saves an hour of writing up. Read the output against your own memory of the session, because models make three characteristic mistakes. They merge steps ("check stock and key order" becomes one line, hiding the decision between them). They tidy away workarounds: in an illustrative run, the model dropped "I keep a list of customers who always need certificates on a sticky note", which was the only thing stopping missing-certificate complaints. And they sometimes add a step that sounds right but nobody described, such as "manager approves order". The "?" instruction helps you see what's genuinely unknown rather than invented.

Label every step: rule, AI step, fix first or person

With the map and numbers in front of you, give each step one of four labels. The distinction between rule-based and AI steps matters; AI versus rule-based automation explains it in more depth.

"Fix first" is the label people skip. Automating step 8 as it stands would automate a sticky note. If a step only works because one person remembers something, write it down and fix it before you build, or you'll get the problems described in automating a broken process.

Draw the future map before anyone builds

Once each step is labelled, sketch the process as it will run after automation, with the same six columns. This "to-be" map is the brief for whoever builds it, and it exposes new steps the automation creates, such as someone checking the AI's extraction. An illustrative version of the first half of the import-export process:

Work time on these steps falls from 26 minutes to about 3 per order, and the order can reach the warehouse within an hour of arriving instead of the next day. Notice the new step two: somebody still checks what the AI extracted, at least for the first couple of months. Leaving that check off the to-be map is how teams end up trusting an extraction they've never measured. The map also shows where the part-shipment exception now goes (to sales admin, with both order numbers attached), so the builder doesn't have to guess.

A smaller map: a courier firm's failed deliveries

Not every map needs eleven steps. An illustrative courier firm mapped "failed delivery recorded by driver" to "parcel redelivered or returned" in 90 minutes. Seven steps: driver records failure reason and photo in the app; controller reviews at end of shift; office emails the recipient; recipient replies or calls; office rebooks; parcel goes out next day; after three failures it's returned to the sender.

The numbers were telling. Each failed delivery took about 9 minutes of office time, but waited an average of 20 hours before the recipient was contacted, because emails went out the next morning. Of 160 failures a month, 38 recipients called in angry before the email reached them. The labels: the recipient email becomes an automatic message within minutes of the driver's entry, with a rebooking link (rule); the controller's photo review stays with a person, because disputes over "left safe" depend on it; the reply sorting ("please leave with neighbour at 14") becomes an AI step that proposes the rebooking for a person to confirm.

Signs the map isn't finished yet

• Every step has a named role and a named tool, with no "someone" or "the system".
• There's an exception log with counts, not just a note that "sometimes things are different".
• Work time and wait time are filled in for every step, even as estimates.
• The people who do the work have read it and agree it's what really happens.
• Each step has one of the four labels.
• You can say which single step you'd automate first and roughly what it saves.

If you can tick all six, you're ready to check the process against the signs a process is ready to automate and start building. The same interview notes also give you most of what you need to write the procedure down; writing SOPs with AI picks up from there, and the finished map is the reference when you later document your processes before adding AI across the rest of the business.

Process mapping questions that come up

Do I need process mapping software?

No. A spreadsheet with six columns and a free diagram tool such as draw.io is enough for a small business. Paid tools like Lucidchart or Miro help when several people edit the same map at once, but the value is in the conversations and the numbers, not the drawing. Many good maps start on a whiteboard photographed with a phone.

How detailed should each step be?

Detailed enough that you could say which tool the step happens in and what information it needs. 'Process the order' is too vague; 'type the PO lines into the order screen' is right. If a step has a decision or a wait inside it, split it. As a rough guide, most small-business processes map to between 8 and 25 steps; far more usually means you've included detail an automation won't care about.

Who should be in the mapping session?

The people who do each step, not just their manager, plus the person who will own the automation afterwards. Two to four people is ideal. Managers tend to describe the official process; the people doing the work know the workarounds, the spreadsheets on desktops and the customers who always send orders differently, which is exactly what the automation needs to handle.

Further reads

• How to Add Human Approval Steps to AI Automations — Where your map shows a judgement, add an approval step like this.
• How to Set a Baseline Before You Introduce AI — Turn the numbers on your map into a baseline to measure against.
• AI Use Case Template: Score Every Idea on One Page — Score each automatable step on one page before you build.
• How to Run a Pre-Mortem Before You Launch an AI Project — Stress-test the automation plan your map suggests.
• AI Workflow Automation Examples: 20 Processes to Automate First — Twenty processes worth mapping and automating first.
• How to Brief a Developer on a Custom AI Workflow You Need — Hand your finished map to a developer as a clear brief.
• How to Map Your Customer Journey and Find Where AI Helps — A journey grid, evidence sources and the signs a step suits AI, walked through with a new puppy owner's first year at a veterinary practice.
• Is It Worth Automating a Task You Only Do Once a Week? — The payback sum for weekly tasks, the factors beyond time that change the answer, and three worked cases: one yes, one partly, one no.
• How to Create SOPs From Screen Recordings With AI — Record a task once, talk through the why, and let AI draft the procedure. Covers Gemini video uploads, Loom, Scribe and Tango, redaction and the cold-run test.
• How to Build Your First AI Automation in Make, Step by Step — A beginner's build in seven steps: sort website enquiries with Make AI Toolkit, route them with filters, log them to a sheet and keep credit use under control.
• How to Stop Zapier and Make Automations Breaking Silently — Four layers of protection against quiet failures: notifications, error handlers that alert someone, heartbeat and volume checks, and validation of AI outputs.
• Opening and Closing Checklists: Build Them With AI in an Hour — Turn a walk-through of your premises into opening and closing checks that staff can follow, record and hand over between shifts.
• Business Continuity Planning With AI: A Template for Small Firms — A ten-section continuity plan template with the checks for each item, plus prompts that let AI interview you and run a tabletop test.
• What Is n8n, and Should a Small Business Use It? — n8n explained for owners: how executions are counted, what the AI nodes do, cloud or self-hosting, a wholesaler's first workflow and who should skip it.
• What Connecting Two Business Apps Really Costs: Four Options — Price the whole app connection with four routes, a worked annual budget and tests for duplicates, delays and failures.
• How to Run a Paid Discovery Phase Before a Full AI Project — A stage-by-stage plan for a paid AI discovery phase, with a filled-in brief, a feasibility test on real emails and a go or no-go decision rule.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: draw.io documentation on inserting Mermaid diagrams; Mermaid flowchart syntax. The business, steps and timings are illustrative.