When a repetitive task appears, it is tempting to start with a tool that could solve it. I prefer to start with another question: do we understand the process well enough to explain it to someone else?
Create: address a concrete need
The first step is to make something work. Understand what the customer needs, what the operation can produce and which decision needs to be made. At this stage, manual work is also a way to learn.
There may still be exceptions, incomplete information and decisions that depend on one person. It helps to observe them before turning them into rules.
Standardise: make the reasoning explicit
A process becomes clearer when we can describe its inputs, its steps and its expected output. Also when we know what to do if information is missing or an unfamiliar case appears.
Documenting that reasoning lets another person continue the work. It also reveals which parts repeat and which still require judgement.
Optimise: measure what matters
Once a process is repeatable, we can look for where time is spent or mistakes occur. I prefer to measure first and change one thing at a time.
In production, the bottleneck might be file preparation, batch organisation or understanding an enquiry. A sophisticated tool does not help if it works on something that is not constraining the outcome.
Automate: preserve what you learned
Automation has a stronger foundation when the rules are already understandable. Deterministic decisions can become code; ambiguous ones may still need human review.
I use this sequence as a working guide, not a rigid recipe. Sometimes a prototype helps us understand the problem better and makes us go back. What matters is that the system preserves what we learned about the operation.
The question I find useful at the start: what would someone else need to know to do this task well?