Before any tool decides whether AI suits a process, someone has to describe the process clearly enough to judge it — not as a diagram of what should happen, but as an honest account of what actually does. This guide is that description exercise, in order.
Key takeaways
STEP 01 OF 11
Start with a plain description of the process as people currently run it — including the workaround nobody put in the manual and the exception that happens every second Tuesday. The gap between the documented version and the real one is usually where an automation project fails first, because the tool gets built against the tidy version.
This is not a NIST requirement, it is a precondition for using one: the U.S. National Institute of Standards and Technology’s AI Risk Management Framework opens its Map function with exactly this instruction — “Context is established and understood” (Map 1) — see the AI RMF Core. NIST is a United States agency; the framework has no Canadian legal force, but the sequencing is sound regardless of who wrote it.
STEP 02 OF 11
Walk the process again and mark each place a person chooses between options, weighs something ambiguous, or pulls in information that is not written down anywhere in the system — a judgment call about a customer’s tone, a exception for a long-standing client, a guess at what a vague request actually means.
These decision points are the parts of the process most likely to need a person to stay involved even after automation, because they depend on context an AI system will not have access to unless someone deliberately gives it that context.
STEP 03 OF 11
Canada’s Cyber Centre draws a useful line between two kinds of AI: “traditional AI systems can recognize patterns or classify existing content”, while generative AI “can create unique content in many forms” — from ITSAP.00.041. Apply that split to your own process map: steps that classify, sort, extract, or match against a known pattern are the strongest automation candidates. Steps that require weighing unwritten context are the weakest, whatever tool you point at them.
A step can contain both. Mapping it honestly means noting where the pattern-matching part ends and the judgment part begins, rather than treating the whole step as one uniform block.
STEP 04 OF 11
For every step, write down exactly what information a person looks at to make the call — a spreadsheet, an email thread, a system field, something said on a phone call and never logged. See structured versus unstructured data, explained for why this distinction matters: a step fed by a clean database field is a different automation problem from one fed by a free-text email nobody has ever parsed.
If the honest answer is “the person just knows this from experience,” write that down too. It is a real finding, and it usually means that step needs a person for longer than the rest of the process.
STEP 05 OF 11
Before comparing the process to an automated version, establish the baseline: what happens right now when a person gets this step wrong? How often does it happen, who catches it, and how expensive is the fix? This is the number an automated version has to beat — not zero errors, but fewer or cheaper ones than the current baseline.
Skipping this step is why so many automation pitches sound better than they turn out to be: without a real baseline, any error rate the new system produces looks like it needs explaining, when the honest comparison might still favour it.
STEP 06 OF 11
A process map that ends in “automate all of this” has not actually been used to make a decision. Pick the single step with the clearest pattern-matching signature, the cleanest data, and the lowest cost if it goes wrong occasionally — and treat that as the actual automation candidate. The rest of the process stays exactly as it is for now.
This is also the more honest use of the map: a step is small enough that a person can genuinely audit what the AI is doing to it, which is much harder to do across an entire multi-step workflow at once.
STEP 07 OF 11
NIST’s framework organises risk management into four functions: Govern, Map, Measure, Manage. Their own wording, read off the AI RMF Core: Govern 1.1 — “Legal and regulatory requirements involving AI are understood, managed, and documented”; Measure 1.1 — risks are “selected for implementation starting with the most significant”; Manage 1.1 — “A determination is made as to whether the AI system achieves its intended purposes and stated objectives and whether its development or deployment should proceed.”
You do not need the government-scale paperwork behind these functions. Ask the four questions in plain language for your one mapped step: what rules apply to it, what could go wrong, how will you know if it did, and who decides whether to actually proceed. If you cannot answer one, that is the gap to close before building anything — not after.
STEP 08 OF 11
A mapped step usually touches a system — a CRM, an inbox, a document store, a calendar. Before automating, write down exactly which systems the AI would need access to and what it would be able to do inside them. See what an AI can reach once it’s connected: the real risk in most automation projects tracks what the system is allowed to touch, not how capable the underlying model is.
Write the access list down before it exists, not after — it is much easier to keep an access list narrow from the start than to discover months later that a tool built for one task quietly has permissions for three others.
STEP 09 OF 11
Mapping the process and deciding who approves its output are two different exercises, and conflating them is a common failure mode. Once you know exactly what the step does and what it touches, work through how to decide what a human must approve for that specific step — using the map you just built as the input, not a general policy written before anyone looked at this process in detail.
A process map with no approval decision attached to it is half a plan. It tells you what the system will do; it does not tell you who is accountable if it does it wrong.
STEP 10 OF 11
Whoever mapped the process — often a manager or an outside consultant — usually knows the intended version better than the lived one. Before treating the map as finished, hand it to the person who runs this process most days and ask a specific question: what did this leave out? The exceptions in Step 1 are the ones most likely to surface here, because they are the ones the person doing the work has stopped mentioning simply because they have become routine to them.
This check is cheap and it catches a specific, common failure: a map that is internally consistent and completely wrong about what actually happens, because it was built from how the process is supposed to work rather than from someone who runs it.
STEP 11 OF 11
A process map is accurate on the day it is written and starts drifting the moment the process, the tool, or the data changes. Put an actual date on when you will re-check it — tied to any change in what the automated step is allowed to do, not to a fixed calendar interval that may or may not line up with when something actually changed.
The map is worth keeping specifically because it is the document that lets a new person, six months later, understand why the automation was built the way it was — and whether the assumptions it rested on still hold.
Mapping the documented process instead of the real one. The tidy, written-down version omits the exceptions and workarounds that make up a meaningful share of real cases — and those are usually the cases where automation causes the most trouble.
Automating the whole process because mapping the whole thing felt more efficient. A single step is the unit you can actually reason about, test, and hold someone accountable for. A whole-process automation is really several unmapped steps wearing one name.
Skipping the baseline error rate. Without knowing how often the current, human-run process gets this step wrong today, there is no honest way to judge whether an automated version is actually an improvement.
Treating the map as a one-time document. A map that is never revisited becomes actively misleading once the process changes underneath it — worse than having no map, because it still looks authoritative.
Letting the person who built the map be the only one who checks it. A map written and approved by the same person who wrote it never gets tested against the version of the process that actually runs day to day — see Step 10.
Illustrative only — a hypothetical to show the method, not a real case or a benchmark for how long this should take.
The process: a small business approves supplier invoices before payment. The honest map: most invoices match a purchase order exactly and get approved in seconds; roughly one in five needs a person to check against an email exchange that is not in the accounting system; a rare few get approved anyway because the supplier is trusted, regardless of the mismatch.
What this reveals: the exact-match cases are strong pattern-matching candidates — structured data, a clear rule, low cost if occasionally wrong. The email-exchange cases are judgment calls fed by unstructured data outside the system — a weak candidate until that data is captured somewhere the AI can actually reach. The trusted-supplier override is a judgment call dressed up as a rule, and mapping it honestly is what stops someone from quietly automating a habit rather than a policy.
The automation candidate that comes out of this map is narrow: match exact invoices to purchase orders and route only the mismatches to a person. That is a smaller, more defensible step than “automate invoice approval” — and it is what the map was for.
Not quite. A flowchart usually shows the intended sequence of steps. A process map, for this purpose, needs to also capture the exceptions, the judgment calls, and the data each step actually relies on — the parts a flowchart tends to leave out because they complicate the diagram.
Only for the process you are actually considering automating, and ideally only for the specific step inside it that looks like the strongest candidate. Mapping an entire operation before touching any of it is a much bigger project than most businesses need to start with.
That is common, and it is itself useful information — it usually means the process runs on individual judgment more than anyone realised, which is a reason for caution, not a reason to skip the mapping step. Write it down for the first time as part of this exercise.
Both, but not in the same draft. A manager or outside reviewer is often better placed to write the first pass, because they can see the process from outside; the person doing it daily is essential for Step 10’s check, because they know the exceptions the first draft is most likely to have smoothed over.
What the process actually touches determines what connecting it involves.
