Repetitive work
Workflow automation
Automation usually starts with choosing a tool, which is the last decision rather than the first. Useful work starts by describing the process as it actually runs — with its exceptions, its skipped steps, and the one person who knows what to do when something does not match. Often that step shows some actions are no longer needed at all, and removing them is more honest than automating them. Automated unnecessary work is still unnecessary; it is merely no longer visible.
Discuss a processIn short: what is worth automating
Automation pays off when the process repeats, its rules can be written down, and the result can be checked. If the rule is different every time, the problem is not manual work but an unsettled process. If the decision relies on human judgement over free-form text, that is not automation but an AI solution — a separate service with different risks. The distinction is simple: automation gives the same answer every time, not a mostly-correct one.
When automation is the right answer
- The work repeats often enough for its duration to be noticeable, and is done essentially the same way each time.
- The decision rule can be written as conditions rather than described as experience.
- The data already lives in a system, not only in email or in someone’s head.
- The result can be checked: there is a way to say whether the step was done correctly.
When something simpler is enough
- The process can simply be removed or shortened — the cheapest “automation” anyone can buy.
- The system in use already offers this, and it is only switched off or unconfigured.
- The work happens a few times a year — then a clear written procedure pays back sooner than something that needs maintaining.
Whether a process is ready to automate
Most failed automations were not technical failures: a process was automated that was not ready for it. Below is the illustrative check we run first. It is not a price list and not a promise about time saved.
| Process state | What it looks like | What to do first |
|---|---|---|
| Documented and stable | Steps are consistent, exceptions are known and countable, and the result can be checked. | Ready to automate. Start with one step rather than the whole process at once. |
| Works but undocumented | It runs smoothly while the same person does it; the rules live in their experience. | Write the flow down with that person first. That alone often speeds the work up. |
| Full of exceptions | Almost every case is special in some way, and the rule description keeps growing. | Automate only the common case and route the rest to a person explicitly. |
| Unclear result | Nobody can say whether the step was done correctly until something breaks later. | Agree what a correct result looks like first. Without it there is nothing to verify. |
| Not needed | The step is done out of habit and nobody uses its output to make a decision. | Remove it. Automating it here would only make it invisible. |
How the work runs
- 01
Describing the process as it is
We record the flow as it is actually performed rather than as it should be, and count how often each exception occurs. This step often shows that less automation is needed than expected, or that a decision about the process itself has to come first.
- 02
What to automate and what not to
We set the boundary: which steps run by themselves, which stay with a person, and where the handover point is. The boundary is written down, because what happens in an unusual case depends on it. Where a rule cannot be written, that is recorded as an open question rather than worked around.
- 03
Implementation with an audit trail and an exception path
An automated step records what was done and when, so a result can be reconstructed and explained. Unusual cases travel down an explicit exception path instead of quietly stopping. An error has to be visible, not hidden.
- 04
Measurement and transferring ownership
We agree how the benefit is measured: the share of cases completed, how often exceptions occur, and time saved where it can genuinely be counted. We record who may change a rule, who notices a fault, and how the process is returned to manual if it has to be.
What drives cost and duration
- Whether the process is already documented — writing down an undocumented flow usually takes longer than the implementation.
- The number of exceptions: each real exception is a separate rule that will need maintaining.
- Whether the data is already in a system or has to be collected from free-form sources first.
- How many systems take part and whether they offer a usable interface — without one, automation becomes integration work.
- Whether a human approval step is needed, and how detailed it has to be.
Worth considering before we talk
- 01Which repetitive task takes the most time, and who does it today?
- 02Can its rule be written down, or is every case decided individually?
- 03How often do exceptions occur, and who handles them today?
- 04Who uses the output of this work to make a decision?
- 05Who will be able to change the rules after handover?
Let us look at the process
Describing one repetitive task is enough: who does it, how often, and where it gets stuck. If it turns out not to be worth automating, we will say so — that is a common and entirely reasonable answer.