Ask an operator how a quote goes out the door and the answer takes about fifteen seconds. Request comes in, someone prices it, someone approves it, it goes out.
Follow one actual quote for a week and the picture is different. The request came in on a Thursday and sat for two days because it landed in a shared inbox that two people both assume the other watches. Pricing needed a specification the customer had not sent, so somebody emailed to ask, and that started a wait nobody measured. The price came back, and the approval bounced it once because the margin looked wrong, which meant re-pricing. Then it went out, and the numbers were typed a second time into the accounting system by hand.
Four steps in the telling. Four steps, two loops, two waits and a manual re-entry in the running.
The second version is the process. It is also the one nobody has written down, which is why the first thing worth doing before any software is bought is drawing it.
Two processes, and only one of them is documented
Every business of any age runs two versions of every workflow.
The documented one lives in a handbook, an onboarding doc or somebody’s head, and it describes the path a case takes when everything arrives complete and on time. It is not wrong. It is just the subset.
The real one includes the branches. What happens when the specification is missing, when the customer changes their mind mid-flight, when the person who normally approves is away, when two requests arrive for the same job. Those branches are handled, every day, competently, by people who have absorbed the rules without anyone writing them down.
That gap has a predictable consequence for anyone buying automation. A system built from the documented process handles the clean cases and hands everything else back to a human, which is roughly the same distribution of work as before, minus the satisfaction of having done it yourself. That is a large part of why teams go back to the spreadsheet after a demonstration everyone liked.
The afternoon that pays for itself
The method is unglamorous and it works.
Pick one real case that finished in the last month. Not a typical one, not a clean one, and specifically not a hypothetical one, because a hypothetical case will follow the documented path by construction. Take the actual file with the actual dates on it.
Get the people who touched it in a room, with a whiteboard or a sheet of paper.
Walk it end to end and draw a box for every step. Then apply four rules that do most of the work:
Every handoff gets a line. Any time the case moved from one person to another, or from a person to a system, or from one system to another, draw the line and name what crossed it. Handoffs are where cases wait and where information gets lost, and they are invisible in a description because the person telling the story was present for all of them.
Every wait gets a number. Not “then it goes for approval” but “then it sits for two days”. Real numbers from the real file. The numbers are what turn a drawing into an argument.
Every “and then usually” gets two branches. This is the highest-yield rule in the exercise. The moment somebody says usually, or normally, or most of the time, there is an unwritten branch and it is about to be skipped. Stop and ask what the other case looks like and who handles it.
Every step gets an owner. A named role, not a department. Steps without an owner are the ones that stall.
One afternoon, one whiteboard, one real case. The first pass will be wrong in places and it will still find more than a month of meetings about software.
What the drawing finds, nearly every time
Four things turn up with enough regularity to predict them.
A queue nobody owns. A shared inbox, a folder, a status column that two people both assume the other one watches. Cases sit there. Nobody is failing at their job, because it is not in anyone’s job. This is the same structural hole that shows up when nobody owns the exceptions, and it costs elapsed days rather than labour hours, which is why it never appears in a time study.
The same fact typed twice. A price, an address, a job number entered by hand into two systems because the two systems do not talk. Usually it is defended as a check, and sometimes it genuinely is one. Usually it is a person acting as the integration, which is expensive and quietly error-prone, and it is the clearest signal that the software you already run is deciding the shape of the work.
A rework loop. A step that gets redone because information arrived after it was needed. Pricing done before the specification landed. A schedule built before the parts date was confirmed. Loops are the most expensive structure in most processes and the least visible, because from inside the loop it just feels like the job.
One person who is the process. Someone knows which supplier to call, which customer needs the second phone call, which invoices go to the other address. That knowledge is real, valuable, and stored in exactly one place. It is also the reason the process cannot be automated as-is, and finding it early is much better than finding it during a build.
The number the drawing produces
Two numbers come out of a completed map, and the difference between them is usually the finding.
Touch time is the minutes of actual work in a case. Elapsed time is how long the case takes from the customer’s point of view.
A quote might be forty minutes of touch time across six days of elapsed time. That ratio is not unusual, and it is the whole strategic picture in one line. Automation aimed at the forty minutes saves some labour and produces a modest return. Removing the waits inside the six days changes what the customer experiences, and in competitive work it changes what gets won, which is a different order of value entirely.
Without the drawing, most automation aims at the forty minutes, because touch time is the part people can feel. The waits are invisible from inside the work, and they are sitting right there on the page once somebody draws them.
Why this comes before choosing a tool
The sequence matters, and the common one is backwards.
The common sequence is: notice that AI exists, look at tools, pick one, then discover what the process is while trying to configure it. That discovery happens under time pressure, inside a vendor’s model of how the work should go, and the parts of the real process that do not fit get labelled as edge cases and deferred. The edge cases were the reason the work needed a person.
The better sequence puts the drawing first, because the drawing decides what kind of problem this is. Sometimes the map shows a genuine judgment step buried in a lot of clerical work, and that is a good candidate for an AI build. Sometimes it shows one missing field on a form, and the honest answer is that no AI is required, which is a finding worth having for free. Sometimes it shows that the question is not whether AI applies but which of four different problems to solve first.
There is a notation for this, Business Process Model and Notation, and it is worth learning the working subset of it because standard shapes mean other people can read your drawing without you standing beside it. For a first pass, boxes and arrows on a whiteboard are entirely sufficient. The value is in the walking, not the shapes.
When the process cannot be drawn
Occasionally the exercise stalls. Every attempt to draw the sequence produces disagreement, and three people who all do the work describe three different flows.
That result is not a failure of the exercise. It is the finding.
A process that cannot be drawn is not a process yet. It is a set of individual habits producing acceptable outcomes through competence and goodwill. That works, sometimes for years, and it is genuinely fine at six people. It gets expensive somewhere around fifteen or twenty, when the outcomes start depending on which person picked up the case.
Automating undrawable work produces a system that encodes one person’s Tuesday and imposes it on everybody. The right move is to settle the process first, on paper, with the people who run it, and to accept that the settling is the project for now. It is cheaper than discovering the disagreement halfway through a build, when the disagreement arrives as a change request.
The part worth carrying out the door
The process people describe is the subset where everything went right. The process that runs contains the loops, the waits, the double entry and the person who holds it together, and that is where both the cost and the opportunity sit.
Take one real case. Draw it end to end. Number the waits, split every “usually” into two branches, name an owner for every step, and mark every handoff. An afternoon is enough for a first pass.
What comes back is a one-page picture that tells you whether the problem is worth software at all, and if it is, exactly which part. That page is worth more than any tool comparison, and unlike the tool comparison, it stays true after the tool changes.