Most automation that fails in a small office fails for the same reason: it was built before anybody wrote down what it was replacing, so when it breaks nobody can say what it was supposed to do. These six steps exist to prevent that. They take longer than diving in and they produce something that survives the person who built it, which is the only kind of automation worth having in an office where one person is the whole administration and holidays are real.
Map it, write it, run it by hand
Map the process as it actually happens, including the step everybody skips and the exception nobody mentions. Write it down in order, in the words the office uses, short enough that somebody could follow it cold. Then run it manually from the written version, twice, and correct the writing where reality disagreed. That third step is the one people skip and it is the one that pays: almost every process is wrong on paper the first time, and automating a wrong process makes the error faster and much harder to see.
Automate one step, then watch it
One step, not the process. Pick the step that is most repetitive and least judgemental, automate that alone, and leave the rest manual for a month. Watch what happens either side of it, because the effect of automating one step is usually to move a pile rather than to remove it, and the pile appears next door. If nothing piled up and nothing broke, take the next step. If something did, you know exactly which change caused it, which you would not if you had automated four steps at once.
Hand it over, which is the test
The last step is to have somebody else run it from your written version while you say nothing. Whatever they get stuck on is what your automation actually depends on that you did not write down. Fix the writing, not the person. An automated process that only its author can operate is a single point of failure wearing the costume of efficiency, and offices discover this in the week the author is away, which is the worst possible week to discover it.
Questions people ask about how to automate office work
How long should the whole thing take?
A fortnight per process, most of it waiting rather than working: a couple of hours to map and write, two manual runs, a month of watching. Doing it faster is possible and mostly produces the failure this page is written to prevent.
What if the process is somebody else's?
Then they write it, not you. A process written by an observer is a description of what they saw, and the parts that are in the doer's head are exactly the parts that break. Your job is to ask the questions that surface the exceptions.
When is a process not worth automating at all?
When it runs a few times a year, when it varies every time, or when the step that takes the time is a decision. In those cases the honest answer is to write it down well and leave it manual, which is a real outcome and not a failure of the method.