Field notes. John Arndt, Soxoa. Published .
Every honest drawing has parts marked leave alone. On a workflow map it is the note that says this step stays in human hands, and in my experience it is the most useful mark on the sheet. It is also the one people treat as a failure, as though the design fell short of a target of automating everything.
It is not a failure. It is the part of the design that makes the rest of it credible.
Four things that belong on the list
There are more than four, but these four cover most of what I end up marking.
- The rare cases
- Automation economics are not uniform across a workflow. The long tail of unusual cases often carries a small share of the volume and most of the risk. Those cases cost more to build for, more to monitor, and far more when they go wrong, and the payback on them is thin. A workflow where the common path runs automatically and the odd ones go to a person is a finished design, not a half-finished one.
- Judgment with consequences attached
- Whether to extend the deadline. Whether this is a complaint or a threat. Whether to price the job at the number that wins it. These are the business, and the reason to keep them human is not sentiment. It is that the inputs are not fully written down anywhere, so a system evaluating them is guessing at a standard nobody has articulated. Put better information in front of the person faster, and stop there.
- Anything irreversible
- Money leaving, a filing submitted, a record that cannot be unwritten, a message to a customer that will be forwarded. The test is whether a wrong answer can be corrected before it has a consequence. Where it cannot, a person presses the button. The system can do everything up to the button, which is usually where most of the time was going anyway.
- Work where reviewing costs as much as doing
- This one gets missed. If checking the output takes as long as producing it from scratch, automating the step buys nothing and adds a dependency. It shows up in short judgment-heavy tasks: a two-paragraph reply that has to be exactly right, a categorisation where the reviewer has to reconstruct the reasoning to accept it. The honest mark there is leave manual, and it is often the mark that saves the project’s credibility.
Write the list early, and write the reason
The list should exist before anything is built, at the same time as the workflow map, because a leave-manual list produced afterwards reads as an excuse. Produced beforehand it reads as scope, and scope is what a client is buying.
Every mark carries a written reason, and the reason is specific. Not too risky, but: this step commits funds and there is no reconciliation before the payment runs. Not judgment, but: the acceptance criteria for this reply are in one person’s head and we have not written them down. A reason like that is testable. It also tells a future team what would have to change for the decision to be revisited, which means the map stays usable after the circumstances move.
Keep the list short enough to read. If half the workflow is marked manual, the answer is probably not a smaller automation; it is that this was the wrong workflow to pick, which is a question I have written about in how to pick the first workflow.
Why it makes the automated part trustworthy
Here is the mechanism. When a system is described as handling a step, the people who do the work have to decide how much to check it. If they believe it was built by someone who thought carefully about where it should not be used, they check the cases the notes tell them to check and get on with their day. If they believe it was built by someone who wanted to automate as much as possible, the rational response is to check everything, and a system that gets checked everywhere has saved nobody any time.
So the leave-manual list is not a concession extracted from the builder. It is the thing that converts the automated part from a claim into a boundary. Inside the boundary, run it. Outside it, do not, and here is why.
It is also the part of my advice you can verify without technical knowledge. Anyone who tells you every step of your process can be automated has told you something about their commercial model rather than about your process. Ask for the list. If there is no list, there was no analysis.
One caution in the other direction
Leave manual is a design decision, not a place to hide. It is possible to mark so much manual that the exercise becomes a way of avoiding any real change, and I have seen that used deliberately by people who did not want the project to succeed. The guard against it is the written reason: an opinion dressed as caution does not survive being written down next to the step.
Review the list when the work changes. Volumes grow, a tool gets better at a thing it was bad at, a manual step that was protecting a reconciliation stops being needed because the reconciliation moved. A drawing with dated marks on it is a live document. A drawing nobody revisits is decoration.
Where this fits
Marking automate, keep a reviewer, and leave manual is the first substantive hour of a Live Build Workshop, and it is the document an AI Build Sprint is scoped from. If you want to see the reasoning applied to a workflow of your own, bring it to a strategy call; if you would rather start with where your organization stands, the AI Readiness Assessment is free and runs in your browser.