AI Opportunities
Process improvement or automation: which one first
Automating a broken process makes it fail faster. A decision test for when to simplify, when to automate, when to apply AI — and when to do nothing.
Miguel Torres, Founder, Merjora · Published 4 September 2026 · Updated 4 September 2026
In short
Simplify first when the process contains steps that exist only for historical reasons, when exception rates are high, or when the rules are disputed between the people who run it. Automate when the path is stable, high volume and rule-based. Apply AI when the blocking step involves unstructured input — text, documents, mixed formats — that rules cannot handle. Do nothing when the total annual cost of the process is smaller than the cost of changing it, which is more often than most vendors will admit.
Key takeaways
- Automation multiplies whatever the process already does, including the mistakes.
- A high exception rate is a design signal, not an automation requirement.
- The cheapest improvement is frequently deleting a step or a required field.
- 'Do nothing' should be a live option in every business case, with its cost stated.
The four-way test
| Condition | Intervention | Why |
|---|---|---|
| Steps nobody can justify; disputed rules | Simplify | Automating a disputed rule automates the dispute |
| Stable path, high volume, structured data | Automate | Deterministic work is cheaper without a model |
| Unstructured input blocks the step | Apply AI, with review | Rules cannot read varied documents or free text |
| Low volume, low cost, high variability | Leave it alone | Change cost exceeds the value released |
Simplify first: what that means concretely
- Remove approval steps whose threshold has not been reviewed in years
- Delete required fields nobody reads downstream
- Collapse two handovers into one by moving a decision to where the information already exists
- Standardise the intake format before trying to interpret twelve variants of it
- Fix the master data that causes the exceptions, rather than building exception handling
The exception-rate rule
Exception rate is the most useful single number when deciding what to build. A process where most cases follow one path is a good automation candidate. A process where a large share of cases take a different route is telling you the design does not match reality — automation there hard-codes the mismatch and creates a permanent maintenance burden.
Measure exceptions before scoping, and be specific about their causes. Three recurring causes usually explain most of them, and two of the three are frequently data quality.
When AI is the right answer
AI belongs where the bottleneck is comprehension: reading a supplier email, extracting fields from documents that never share a layout, classifying an enquiry, summarising a long case history for the person who has to act on it. In those steps, rules have already been tried and produce brittle results.
Even then, design the review point first. A step that produces a draft for a person to approve can tolerate imperfect accuracy; a step that writes directly to a system of record cannot.
The cost of changing something
- Discovery and specification time from people who also have day jobs
- Build or configuration, plus integration into systems that were not designed for it
- Testing against real historical cases, including the awkward ones
- Training, and the temporary productivity dip while people adapt
- Ongoing ownership: someone must notice when it stops working
Frequently asked questions
- Can we simplify and automate at the same time?
- You can, but you lose the ability to attribute the result. If sequencing is possible, simplify, measure, then automate — the automation scope usually shrinks after simplification.
- How do we know whether the rules are disputed?
- Ask three people who run the process to describe the decision independently. If the answers differ materially, the rules are disputed and no software will resolve that.
- Is 'do nothing' really a legitimate outcome?
- Yes, and a discovery exercise that never produces one is not screening honestly. Recording why a candidate was rejected also prevents it being re-proposed every year.
Find the process worth fixing first
Merjora maps how your business actually operates, scores each opportunity and quantifies the value range before you commit budget.
Discover your AI opportunitiesRelated reading
Editorial standard. Merjora publishes analysis, frameworks and publicly documented examples. We do not publish invented statistics, unattributed benchmarks or unverified customer stories.