The demo always goes well. You take the process as it works on the day of the meeting, automate it, time it and show the number: “from 40 hours a month to 8.” Three weeks after go-live a discount rule changes, the supplier redesigns the format of its delivery notes and someone in finance adds a new field to the report. The automation is still there, but it no longer automates the process: it automates the version of the process that existed on demo day.
The thesis in one line: the criterion missing from almost every “what to automate” list isn’t volume or savings, it’s stability. A process that changes every month eats in maintenance what it frees in execution, and the return calculation is always done against a frozen version that no longer exists. If the process moves faster than your ability to rework it, don’t automate it yet: stabilize it first.
Automating a process that keeps changing costs more than it frees
Candidate lists score three things: how often the task repeats, how long it takes and how much an error costs. All three measure the process today. None asks how much it will still resemble itself in six months, which is exactly what decides whether the automation ages well or turns into a recurring bill. That’s why a process can score top marks on volume and bottom marks on real return.
The short answer to the question we get asked: yes, you can automate a process that changes often, but it doesn’t pay off when the cost of reworking it every time it changes approaches the hours it frees. And maintenance is rarely budgeted, because at demo time no change has happened yet.
The arithmetic: hours freed minus hours of rework
The sum fits on one line: net hours per month = hours freed per month − (changes per year × hours per change ÷ 12). An “hour per change” includes what almost nobody writes down: understanding what changed, modifying the flow, retesting it on real cases and deploying without breaking what already worked. An example with made-up numbers, only to show the calculation (replace them with yours), for a process that takes 40 hours a month by hand and that a stable automation brings down to 8:
| How the process behaves | Changes per year × hours per change | Rework hours per month | Net hours freed per month |
|---|---|---|---|
| Stable | 1 × 10 | 0.8 | 31.2 |
| Changes every quarter | 4 × 12 | 4 | 28 |
| Changes every month, parameter changes | 12 × 20 | 20 | 12 |
| Changes every month, structural changes | 12 × 40 | 40 | −8 |
Look at the last row: the automated process costs more than doing it by hand. It isn’t an exotic case; it’s what happens when the change isn’t a value you adjust but a way of working that gets redone. And the sum doesn’t even include supervision, which is subtracted separately, as we explain in why freed hours aren’t savings.
What “changes” means (not every change costs the same)
Saying a process “changes a lot” isn’t useful: some changes are absorbed in minutes and some force a rewrite. The difference is in what moves:
- The values change. A threshold, a rate, an exceptions list. If those values live in a table outside the flow, the change takes minutes. If they’re written into the logic, it takes an intervention.
- The format of the input changes. A supplier redesigns its invoice, or a client changes its template. The cost depends on how robust the input reading is, and it’s the change that breaks things most silently.
- The system it runs through changes. An ERP migration, a new CRM, a retired API. That’s a structural change: it costs days, not minutes.
- The decision-maker’s criterion changes. What was approved automatically yesterday is reviewed by a person today. It’s the most expensive one, because the flow keeps running and produces wrong decisions without any alarm going off.
How to measure stability before automating: four questions
You don’t need a model. You need four answers, and you can get them in an afternoon with the person who runs the process:
- How many times has it changed in the last twelve months? With dates. Look at the work-instruction history, the “from now on we do it this way” emails and the open incidents. If nobody remembers a change, there are probably many small ones.
- What moved each time: a value, a format or the structure? Classify each change with the list above. Three value changes and one structural change don’t weigh the same as four structural ones.
- Who decides the change, and do they warn you beforehand? If the change comes from outside (a supplier, a regulator, a client) without notice, the rework will always be urgent and always late.
- Is the process written down? A process that only exists in the head of the person running it can’t be reworked: it has to be extracted first. That’s why documenting your automations isn’t bureaucracy; it’s what makes the next change cheap.
What to do with the process that changes every month
There are four ways out, and almost nobody considers the first because it sounds like doing nothing:
- Stabilize it first. Freeze a version for a quarter, decide who authorizes changes and batch them into a single window. Sometimes the process changes every month because nobody has decided how it should be, not because the business demands it.
- Automate the stable core and leave the variable tail to a person. 80% of cases follow the usual rule; the 20% that changes gets handled by someone. It’s less spectacular in the demo and much cheaper to maintain.
- Take the rules out of the flow. Let thresholds, rates and exceptions live in a table the process owner can edit without touching the automation.
- Wait. If the big change is already on its way (a migration, a new regulation), automating now means paying twice.
Whichever way out you take, rework needs a safety net: every change should go through a test before it touches production, because an unstable process with an untested automation is exactly where the incidents the customer discovers are born.
When it is still worth automating even if it changes
There are reasonable exceptions. If volume is very high and the changes are almost always of values (not structure), the rework is diluted and the sum works out. If the cost of an error is very large, paying for maintenance can be worth it for the traceability. And if the process changes because the business is in the middle of a transformation, automating the stable core and leaving the rest to a person is still better than waiting for everything to settle. What isn’t reasonable is discovering the maintenance cost after you’ve signed the project.
Where to start
With the list, before the tool: add a stability column to your selection criteria and score it with the four questions. The guide on which processes to automate with AI explains how to rank candidates by task; this column decides which ones go first. And if you’d rather have someone measure it with you on your real processes, that’s exactly what we do when we audit your processes for AI: what’s suitable, what it really costs and in what order it goes in, with stability as a filter from day one.
The line to take away is the one from the beginning: the demo is run against today’s process, and you’ll be living with the one from six months from now. Pick first the one that will move the least.