To map a business process before automating it, watch the work as it is really done and write down each step with its trigger, input, owner, tool, output and exceptions. Use one row per step, mark every handoff between people or tools, and test the map against real past cases. That map becomes your automation spec.
Key takeaways: Map the process as it is actually done, not as people say it is, and spend most of your time on exceptions and handoffs. A one-page table is enough for a small team.
Why map a process before you automate it?
Because an automation can only follow rules someone has written down, and in small teams most of those rules live in people's heads. The person who handles new enquiries knows that "urgent" emails from one client skip the queue, that quotes over a certain size need the owner's approval, and that the CRM field for source is never filled in correctly. None of that is written anywhere, so a tool built from the "official" description misses it. The result is an automation that works on the easy cases and quietly breaks on the rest.
Mapping also exposes work you should not automate yet. Sometimes a process has three people doing the same step in three different ways, and automating it just hardcodes the confusion. Writing it out forces you to pick one way first. If you are still deciding which process to start with, our guide on what to automate first in a small business covers that choice, and the ROI worksheet helps you check it is worth building. This article picks up after both.
What goes into a process map?
A process map for a small team is a table with one row per step and a fixed set of columns. You do not need flowchart software or formal notation, and a spreadsheet or a Notion table is fine. The point is that every step answers the same questions, so gaps are obvious when a cell is empty. Start with the columns below and add one only if you keep needing it.
| Column | What to write | Example |
|---|---|---|
| Step | One action, starting with a verb | Check whether the customer already exists |
| Trigger | What starts this step | New form submission arrives |
| Input | Data or documents needed | Name, email, request text |
| Owner | The person or role who does it | Sales assistant |
| Tool | Where the work happens | HubSpot, shared inbox |
| Output | What exists when the step is done | Contact record created or updated |
| Decision or exception | What changes the path | Duplicate found, so merge instead of create |
| Handoff | Who or what receives it next | Goes to account owner in Slack |
The decision and handoff columns matter most. Handoffs are where work gets dropped, since a message sits in someone's inbox or a status never gets updated. Decisions are where an automation needs explicit rules, or where it needs to stop and ask a human. Keeping them as their own columns means you cannot skip them by accident.
How do you map the process step by step?
Start from observation rather than memory. Ask the person who does the work to walk you through a real, recent case while you watch their screen, or have them narrate it. People describing a process from memory leave out the awkward parts, while a live case shows the copy-pasting, the spreadsheet on the side and the quick message to a colleague. Here is a sequence that works for one process in an afternoon or two.
- Name the start and the end. Write the exact event that starts the process and the exact state that means it is finished. "Enquiry received" to "customer has a booked call or a polite no" is clear. "Handle leads" is not.
- Walk through one real case. Pick a recent case, ideally an ordinary one, and record each action in order as a row in your table.
- Fill in the columns. For each row add trigger, input, owner, tool, output and handoff. Mark any cell you cannot fill as a question.
- Add the exceptions. Go back through each step and ask what happens when it goes wrong or does not fit. More on this below.
- Check it with a second person. Someone who does the same work, or covers for them, will spot steps you missed.
- Test it against five to ten past cases. Run real examples through the map on paper. Every case that does not fit is a missing rule.
Keep the map at the level of actions a person would recognise. If a row reads "process the order", split it until each row is something one person does in one tool. If it reads "click the blue button", you have gone too far, since the tool may change but the intent will not. A good test is whether a new hire could follow the table on their first day.
How do you find the exceptions?
Ask the person doing the work what they do when things do not go as expected, and then look at the cases that took longest. Exceptions rarely come up when you ask "are there any special cases?", because people have absorbed them as normal. Better questions are "what was the last time this went wrong?", "what do you check twice?" and "when do you ask someone else?". Your sent folder, support tickets and any thread with the word "sorry" in it are also good evidence, since they show where the process failed in practice.
For each exception, record three things: how you recognise it, what the correct handling is, and who decides. Then sort them into three groups. Some can be turned into a clear rule the automation applies, such as "if the order is above a set value, notify the owner". Some should send the case to a person with the context attached. Some are rare enough that a human should keep doing them. How much to leave to the system is a design choice, and our article on autonomous versus semi-autonomous agents explains how to think about it.
What does a mapped step look like in practice?
Take an illustrative example: a small agency receives project enquiries through a web form. A mapped row might read: step "Check for existing contact", trigger "form submitted", input "email address", owner "sales assistant", tool "HubSpot", output "contact record created or matched", exception "email domain matches an existing client, so notify the account owner instead of creating a lead", handoff "new lead task assigned in HubSpot and a message posted in Slack". That single row already tells a builder which fields to read, which rule to apply and where to send the result.
Now compare that with the usual description, "we log new leads in the CRM and tell the team". Both sentences describe the same work, but only the row can be built from. It also shows where tools fit. A trigger and a handoff between HubSpot and Slack are a natural job for a tool like Zapier, while a step that reads a free-text request and classifies it is where an AI model might help. Mapping tells you which kind of step you have, so you choose the tool for each step rather than one tool for everything.
What do you do with the finished map?
Mark each row as keep manual, automate with rules, or use AI, then pick the first slice to build. Rows with clear inputs and clear rules suit a plain workflow, while rows that involve reading messy text or documents may suit an AI step with a human checking the output. Do not try to automate the whole map at once. A good first slice is a few consecutive rows with a visible result, since you can test it against your past cases and see whether it behaves as the map predicts.
The map is also most of the brief you would send to an agency or freelancer. Add the goal, the volume, the tools you use and what a good result looks like, and you have what is described in our guide to writing an AI project brief. It also feeds the first phase of a project, as described in what a custom AI agent project involves. If you would rather not do the mapping alone, Kuan AI starts every project with a diagnosis of how the work is really done, and you can send us a message through the contact form.
Frequently asked questions
Do I need special software to map a process?
No. A spreadsheet or a Notion table with one row per step is enough for most small-team processes. Flowchart tools can help later if the process has many branches, but the columns matter more than the drawing.
How detailed should each step be?
Detailed enough that a new hire could follow it on day one, but not down to individual clicks. If a row says something vague like "process the order", split it until each row is one action by one person in one tool.
How long does mapping one process take?
For a single, fairly simple process, usually an afternoon or two of observation and review. Longer processes with many exceptions or several people take more time, and it depends on how well the work is already understood.
Who should be involved in the mapping?
The person who does the work every day, a second person who covers for them, and whoever owns the outcome. Managers often describe the official process, while the person doing it knows the real one.
Can I map a process if it is messy or inconsistent?
Yes, and the messiness is useful information. Map what actually happens, note where people differ, then decide on one way of doing it before you automate. Automating an inconsistent process just fixes the inconsistency in place.
What if I do not know which tools should do each step?
Fill in the map first and mark each row as manual, rules-based or needing AI. The tool choice becomes easier once you can see each step's inputs and decisions. An agency can help with this during a diagnosis; you can get in touch here.
Process maps go out of date, so treat yours as a living document. When you change a tool, add a client type or notice a new exception, update the row first and then the automation. A map kept in a shared place with a named owner stays useful, and it also makes it easier to onboard people, whether they are new staff or the next person building on your setup.
