Document it, or automate it
How much writing down is enough, and when you can skip it.
Write down the steps, the exceptions and who decides, which is usually an afternoon rather than a project. Then automate the part that did not change while you were watching. Skip the writing only when the process is one step, or when it is already running inside one system.
Work it out in a minute
Six questions on one task, scored on volume, rules, stability and judgment. Returns a straight verdict.
What we take on
Documenting is smaller than it sounds
Steps in order, what triggers it, what finishes it, the exceptions somebody handles without thinking, and who decides when it is ambiguous. One page, written by the person who does it.
The exceptions are the whole point
Every process has a handful of cases the regular steps do not cover. They are what an automation meets in week two, and they are invisible in any description written from memory in a meeting.
Watch it run before writing it
A process described from memory and a process observed for two weeks are different documents. The gap between them is where automations fail.
Skip it when the process is one step
Moving a file, sending a fixed reminder, copying a record from one system to another. If the whole thing fits in a sentence, writing the sentence is the document.
Skip it when it already lives in one system
A workflow entirely inside one tool is already written down, in the tool. Automating inside it is configuration, and it can be undone.
The document outlives the automation
Software changes, providers change, people leave. The page describing what the process is for and who decides survives all three, and it is what makes the next version cheap.
How much is enough, and when to stop writing
The honest amount is one page per process, written by whoever does it, after two weeks of watching it happen. That is enough to automate from, and it is far less than the process manuals that get commissioned and then never read.
Write the trigger, the steps in order, the definition of done, the exceptions and the decision points. Everything else is detail that changes faster than the document can, and adding it is how a page becomes a binder nobody opens.
The reason to watch first is that people describe the ideal version of their own work. Not deliberately: the exceptions have become so routine that they no longer register as exceptions, and those are exactly what breaks an automation.
Two cases genuinely skip the writing. A single-step task, where the sentence is the document. And a workflow already contained inside one system, which is documented by its own configuration and can be reverted.
The failure mode worth avoiding is automating an unmapped process. It does not become a broken automation, which would at least be visible. It becomes a faster version of the mess, with a longer explanation of why nobody can change it.
The order that works: watch, write one page, fix the worst handoff by hand, then automate what stayed the same through all of that. Each step makes the next one smaller, and the last one is usually much smaller than expected.
Questions we get
How long should documenting take?
An afternoon per process, after a couple of weeks of noticing how it actually runs. If it is taking a week, the scope has grown from a process to a department.
One page, one owner, one date on it.
Who should write it?
The person who does the work, in their own words. A document written by somebody who has never run the process reads well and misses the exceptions.
Edit for clarity afterwards if you like. Do not replace their sentences with tidier ones that mean something slightly different.
What if the process changes constantly?
Then it is not ready to automate, and the document is worth even more. Write what is stable, note what is moving, and revisit in a month.
A process that changes every week is telling you something about the decision underneath it, and that is usually the thing to fix first.
Is a video walkthrough enough?
As a supplement, yes, and it captures the exceptions well. As the only record, no. Nobody scrubs a twenty minute video to check one step, and it cannot be edited when the process moves.
Record the video, write the page from it.
Do we need special software for this?
No. A shared document with a name and a date on it does the job. What matters is that there is one copy, everybody knows where it is, and somebody owns keeping it current.
Tooling helps at a scale most companies asking this question have not reached.
What if nobody will write anything down?
Start with the one process that hurt most recently, and write it with them rather than asking them to. A single page that saves an argument does more for the habit than a policy about documentation.
One page, one week, then the next one.
More in the guides and every answer in one place.
Shaheer leads the work, with engineers, writers, filers and analysts behind him. C-suite operations for a San Francisco AI company, Six Sigma on the process side, Anthropic certified on the Model Context Protocol, ten years across eight industries. See what we have built