The plain definition
Process automation is getting a sequence of work to happen without somebody doing each step by hand.
An order arrives, so stock is checked, the customer is verified, a delivery is created, and accounts are notified.
That sequence exists in every business. The question is whether it runs because somebody remembers, or because the system makes it happen.
What it is not
Three things it gets confused with.
Not a tool. RPA, workflow tools and AI are ways of automating. The process comes first, and picking a tool before understanding the process is the most common expensive mistake.
Not the same as digitising. Moving a paper form to a screen is useful and it is not automation. Somebody still does every step.
Not the same as speed. A bad process running faster is a bad process running faster.
The prerequisite
You cannot automate a process you cannot describe.
And most companies cannot describe theirs accurately.
Why: the written procedure describes what should happen. The actual process includes exceptions people handle without noticing — the customer who always pays late, the supplier who ships short, the month the file arrives on a different day.
Those exceptions are where automation projects fail, because they were never in anyone’s description.
Which makes the first step non-technical: watch the work being done, several times, by more than one person.
FIGURE 1: WHAT HAS TO BE TRUE FIRST
The process is described accurately
- Including the exceptions nobody wrote down.
People agree on it
- If two people do it differently, decide which is right.
It is worth doing at all
- Automating a pointless step makes it faster, not better.
Somebody will own it
- An unowned automation breaks quietly.
The question before any of it
Should this process exist?
Automating a step nobody needs makes it cheaper to do something pointless.
Three questions worth asking of any process before automating it:
Why does this step exist? If the answer is “we’ve always done it”, investigate.
Who uses the output? A report nobody reads should be deleted, not automated.
What would break if we stopped? Sometimes nothing.
Removing three of eight steps often saves more than automating all eight — and costs nothing to maintain afterwards.
What makes a process suitable
Four characteristics. The more it has, the better it automates.
Repetitive. It happens often. Daily or weekly, not twice a year.
Rule-based. The steps follow from the inputs, without judgement.
Structured input. Data in a consistent form, in a known place.
Stable. It is not changing every month.
And one that matters as much: somebody will own the result. An automation with no owner breaks quietly and stays broken.
What makes it unsuitable
Judgement at the centre. If the core of the task is a decision, automate the gathering and leave the decision.
High variety, low volume. Every case different, few cases.
Unstable. A process changing monthly will need reworking monthly.
Undocumented and contested. If two departments disagree about how it works, that is not a technology problem.
FIGURE 2: SUITABLE AND UNSUITABLE
Automates well
- Happens weekly or more often
- Steps follow from the inputs
- Input is consistent and structured
- Stable, and somebody owns it
Does not
- Judgement at the centre
- Rare and always different
- Changing every month
- Two departments disagree on how it works
Full or partial
Partial automation is often the better answer, and it is underused.
A process might be twelve steps, of which nine are mechanical and three need judgement.
Automate the nine. The system gathers, checks, prepares and presents. A person decides.
Why this is frequently better:
Faster to build. No need to encode judgement as rules.
More reliable. Fewer cases where the rules do not cover reality.
Safer. Nothing irreversible happens unreviewed.
And most of the time saved is in the gathering anyway — the decision usually takes a minute.
The tools, briefly
In the order you should consider them.
Your existing system’s settings. Most business systems do more than people know. Odoo has automated actions, scheduled jobs, approval rules and reordering. A setting needs no maintenance.
A workflow tool. For multi-step logic across systems, where both have APIs.
Custom integration. High volume, complex logic, or business-critical.
RPA. Where there is genuinely no programmatic way in.
AI. Where the input is unstructured — documents, free text — and no rule handles it.
Most requests are satisfied at the first or second level. Reaching for the last two first is how projects become expensive.
Measuring it
Before you automate anything, record the baseline.
Time. Minutes per run, runs per month.
Errors. How often the manual process goes wrong.
Delay. How long from trigger to completion.
Afterwards, compare — including maintenance time.
That last part is what people leave out, and it is the difference between a real saving and an apparent one.
A rough guide: if the annual saving is not several times the annual cost including maintenance, it is marginal. Marginal automations get abandoned when whoever built them leaves.
FIGURE 3: THE SEQUENCE
Watch the work
- Several times, more than one person
Question the steps
- Should each one exist?
Choose the lightest tool
- Settings first, RPA and AI last
Measure against a baseline
- Including maintenance time
Where projects fail
Automating an undocumented process. Halfway through, you discover it is not what anyone described.
Automating a process nobody questioned. Faster, in the same wrong direction.
Picking the tool first. Then fitting the process to the tool.
No owner. Something changes, it breaks, nobody fixes it.
Silent failure. Nobody notices for weeks, and by then you cannot reconstruct what was missed.
No baseline. Nobody can say whether it helped.
Where to start
- Pick the most repetitive process, not the most annoying one
- Watch it being done, and write down the exceptions
- Question every step — should it exist?
- Check whether your existing system already does it
- Automate the mechanical parts, leave the judgement
- Measure against the baseline
- Name an owner before it goes live
The short version
Process automation is getting a sequence to run without somebody doing each step — and the process comes before the tool.
You cannot automate what you cannot describe, and most written procedures leave out the exceptions where automation fails.
Ask whether each step should exist before making it faster.
Automate the mechanical parts and leave the judgement. Partial automation is usually faster to build, more reliable, and captures most of the saving.
A process somebody repeats every week?
Get in touch. We start by watching it done — the exceptions nobody documented decide whether it can be automated at all.
