Questions we answerProcess and ownership
Should I document the process before automating it?
Yes, and not because documentation is virtuous. Writing it down is how you find the steps that should not exist — which is most of the value automation ever delivers.
Free · a few minutes · starts from “We're overloaded”
The short answer
Yes, and the reason is practical rather than procedural. You cannot automate steps nobody has written down, and the act of writing them down reliably reveals steps that exist only because of how something else is configured. Removing those is usually worth more than automating what remains. Documentation here means a page, not a manual: the trigger, the steps, the decisions, the exceptions and what done looks like. If that page is hard to write, the process is not ready, and that is the finding.
The instinct to skip documentation is understandable — it feels like preparation rather than progress, and the people who know the process are the busiest people you have.
But automating an undocumented process automates the mess, including the workarounds nobody remembers introducing. The write-up is not a formality; it is the part that finds the waste.
Is it really this?
Worth checking before you spend anything. These are the signals that tend to tell the two apart.
Signs it is
- Two people describe the same process differently and both are right about their version.
- There are exceptions nobody can enumerate without thinking hard.
- The steps are known but have never been written in one place.
Signs it's something else
- The process is already documented, accurate and followed.
- The work genuinely differs each time, so the document would be a description of judgement.
- It comes round rarely enough that neither the document nor the automation pays back.
What's usually behind it
- A process that has evolved through people rather than design, and lives in habits.
- Pressure to show progress quickly, which makes building feel better than describing.
- Several people doing the same work slightly differently, none of them wrongly.
What people usually get wrong
- Producing a thirty-page manual instead of a one-page description of what actually happens.
- Documenting the official process rather than the real one, then automating the fiction.
- Treating the write-up as overhead, and missing that most of the saving is in the steps it deletes.
The options, and when each one fits
In no particular order. Which of these fits depends on your situation, not on the question you typed.
Write it down first
The process is real, repeated and undocumented. This is almost always the answer.
Simplify, then decide
Writing it down revealed steps that exist for no current reason.
Leave it alone
It runs rarely and works well enough that neither effort pays back.
When doing nothing is the right call
A process that runs a few times a year and works is not a good automation candidate, and documenting it may be the whole of the useful work. Writing it down is worth doing anyway for the key-person risk it removes.
What the diagnostic asks
- How much of the process is written down.
- Whether the work is mostly repeatable or different every time.
- How often it comes round and how much judgement it needs.
- Whether software already exists for it.
“I don't know” is always an answer. Nothing is assumed on your behalf.
The routes it weighs
Every diagnostic weighs all ten routes. These are the ones that tend to matter for this question — a description of the rules, not a promise about your answer.
Process improvement
Change how the work flows — remove steps, name an owner, fix the hand-offs.
AI Assist
Keep a person in charge and give them AI for drafting, summarising, checking or analysis.
AI Agent
Delegate a defined, repeatable workflow to software inside boundaries you set, with human oversight.
Redistribute
Move ownership of the work to where it fits, and make that explicit.
Do nothing yet
Record the issue, set a revisit date, and decide what would change your mind.
What changes the answer
- A process that lives in people's heads is not ready to automate, however repetitive it looks.
- Work that varies every time will not become consistent because it has been written down.
- An existing system that already does most of this changes what you would build at all.
Get your own read
A handful of short questions, then the strongest route for your situation, what's also credible, what we still don't know and what would change our view. No account, no setup.
Related questions
- Is my process ready to automate?Four things have to be true: the steps repeat, they are written down, it happens often enough to pay back, and someone can say what a failure costs.
- What should I automate first?The most frequent, most repeatable, best-understood, lowest-stakes thing you do. Not the most annoying one, and not the one with the best demo.
- Should I automate this work?If it is repeatable, frequent, low-judgement and written down, quite possibly. If any of those is missing, fix that first.
- Should I fix the process before hiring?Usually yes, at least far enough to know what the new person would own. It is cheap and quick, and it either removes the need or tells you exactly what to recruit for. It stops being sensible once it becomes a reason never to decide.
- Do I need a new hire or a better process?Usually the process first, because it is cheap to try and tells you how much of the load is design rather than volume. Sometimes both.
- How do I fix handoff problems?Work fails at the joins more often than in anyone's hands. Fixing it means agreeing what "ready" means at each boundary — and having someone own the outcome across it.