There is a strong temptation to skip this step. Everyone involved knows how the process works, so writing it down feels like bureaucracy. In our experience it is the step that most reliably determines whether the project succeeds, and skipping it is the most expensive shortcut available.
The documented process is not the real one
Almost every process we map differs from its description. Not through negligence — through accumulated adaptation. A step was added after an incident. Another is skipped when the customer is urgent. A check officially performed by one department is actually done by someone else who noticed it was being missed.
Automating the documented version produces a system that fails whenever reality diverges, which is often. And nobody predicted it, because everyone was describing the official version in good faith.
Map by watching, not by asking
People describe processes as they should be, and omit steps that have become automatic. The most useful hour you can spend is sitting with the person doing the work and watching them handle real cases.
You will see things nobody mentions: the sanity check performed by eye, the informal list kept in a private spreadsheet, the message sent to a colleague to confirm something before proceeding. Those are load-bearing and they are invisible in any interview.
Record the decisions, not just the steps
Steps are easy. Decisions are where the value is. At each branch, what information is used and what rule is applied?
Expect to hear "you can just tell" or "it depends". That is not an unhelpful answer — it is the signal that you have found expert judgement that has never been articulated. Keep going with concrete cases: show me one you rejected, and one you accepted, and tell me the difference. Repeat until the rule becomes sayable.
If it cannot be made sayable, that part of the process cannot be automated. Knowing that before you build is valuable.
Chase the exceptions
Ask directly: what happens when the document is missing a field, when the customer is in another country, when the amount is unusually large, when it arrives after the cutoff.
Exceptions are typically a small share of volume and a large share of effort and risk. A system handling only the clean path may cover most items while leaving almost all of the actual work untouched — a result that looks like success in a report and feels like nothing changed.
Note the handovers
Every point where work passes between people is a place where time disappears and context is lost. Write down what is transferred, how, and what the receiver has to reconstruct.
Handovers are frequently the largest single source of delay, and they are often easier to fix than the work itself.
Then ask the uncomfortable question
With the process written down, ask whether all of it needs to exist. It is common to find an approval that has never rejected anything, a report nobody reads, a form field nobody uses.
Removing a step is cheaper than automating it, permanently. Mapping frequently pays for itself here alone, before any software is built.
Keep it short
This is not a documentation project. One or two pages per process, produced in a few days, is the right scale. The point is a shared, accurate picture that the people doing the work recognise — not an artefact for a shelf.
