Automate or standardise first? A rule of thumb
When to automate a process and when to standardise it first: three questions to ask, what each answer means, and where AI fits after that.
Devvion · Published
"We bought a workflow tool last year. It was meant to fix our approvals. Six months later, half the team still sends requests by WhatsApp, the other half uses the tool, and nobody trusts either. Was the tool wrong, or were we?"
Usually neither. The process wasn't ready. Three people were doing the same task three ways, the rules lived in one manager's head, and nobody owned the result. The tool faithfully automated the confusion.
Every operations lead faces this question sooner or later: do we automate now, or do we standardise the process first? Here is a rule of thumb that holds up in most companies of 50 to 500 people.
The rule: three yeses before you automate
Ask three questions about the process.
- Is it done the same way in most cases? Not every case, but most. If each person or branch has its own version, there's nothing stable to automate yet.
- Are the rules written down? Who approves, up to which amount, what counts as complete, what happens when something's missing. If the rules live in someone's head, the automation will either guess or stall.
- Does one person own it? Not a committee. One name, who decides when the process changes and who fixes it when it breaks.
Three yeses: automate. Any no: standardise that part first. Most processes in a growing company get one or two yeses, which is why so many automation projects stall in month two.
What each answer tells you
| What you find | What it means | Do this first | |---|---|---| | Three yeses | The process is stable and owned | Automate it | | Many variants of the same task | Teams have drifted apart | Agree one version, retire the rest | | Rules unwritten | Decisions depend on memory | Write the rules and the approval limits | | No owner | Nobody can approve a change | Name one owner before anything else | | Low volume, high judgement | Little to gain from automation | Standardise and leave it manual |
There's one useful exception. Sometimes a simple tool is the fastest way to standardise: a form that forces the same fields, or a single intake that replaces five inboxes. That's fine, as long as you know you're using the tool to enforce a standard you've agreed, not hoping it will invent one.
What it costs to get the order wrong
Automating too early costs twice. You pay for the build, then you pay again in exceptions, workarounds and a second build once the process is finally agreed. Standardising too long has its own cost: the manual hours continue while the procedure document is polished.
The fixed flow: decision rights before approval automation
Decision rights and approval matrix
- Request raised
- Read the request
- Apply approval matrix
- Within own limit?
- Named approver decides
- Decided in 2 days?
- Decision recorded
- Request goes ahead
- Decided in hours
- Approval wait: 4 days → 6 hours (Example)
Approvals are where this rule matters most. Before any approval is automated, the flow above sets the decision rights: who can approve what, up to which amount, who covers when they're away, and what goes to the next level. Once that matrix is written and agreed, routing approvals automatically is straightforward. Without it, the tool sends requests to the wrong person, people go back to chat, and the automation gets blamed.
Where AI fits
AI doesn't change the rule. It moves the line a little. A process can have messy inputs, such as free-text emails, scanned documents or customer messages in two languages, and still be stable underneath. AI can read those inputs and turn them into the standard format. What AI can't do is decide rules nobody has agreed. Put AI on the judgement steps that remain after the rules, keep a person able to override it, and log every decision it makes.
What to do this week without us
- Pick the process your team complains about most and that repeats every week.
- Ask the three questions with the people who do the work, not only their manager. Write down each answer.
- Count the variants. Ask three people to describe the same task. Note every difference.
- Write the rules on one page: approvers, limits, what complete means, what happens when something's missing.
- Name the owner. One person, with a deputy.
- Then decide. If you now have three yeses, automate. If not, you know exactly which part to fix first.
When to call us
Call us when the process spans several teams or systems, when the variants are too many to agree internally, or when a previous automation stalled and nobody is sure why.
Devvion offers both sides of the rule. Business consulting does the standardising: we assess, map and mature the process, with SOPs, roles, controls and KPIs. Forward-deployed engineering does the automating: our engineer works inside your business, not from a ticket queue, and builds the automation in your stack, then optimises and runs it with you. Most clients buy both in sequence. The people you meet stay on your work from the first day to the last. It starts with the two-week assessment, which marks each process "standardise first", "automate" or "leave alone". See the use cases.
FAQ
How does Devvion decide whether to automate or standardise first?
Devvion asks three questions: is the process done the same way in most cases, are the rules written down, and does one person own it. Three yeses means automate. Any no means standardise that part first, then automate.
Can't automation itself standardise a process?
Devvion uses that approach in a narrow case: a form or single intake that forces the same fields can enforce a standard. It works only when the standard has been agreed first. A tool can't decide rules for you.
How long does standardising take?
Devvion usually sees two to six weeks for one process, depending on how many teams and variants are involved. Writing the rules is quick. Getting the teams to agree one version, and retiring the others, takes most of the time.
Does AI remove the need to standardise?
Devvion's experience is that it doesn't. AI handles messy inputs well, like free-text emails or scanned documents, but it can't decide rules nobody has agreed. Standardise the decisions, then let AI handle the judgement steps that remain.
What if we already automated a process that wasn't ready?
Devvion starts by mapping what the process actually does today, including every workaround around the tool. Often the build can stay. The rules, the owner and the variants get fixed underneath it, then the automation is re-tuned.