Why automations slide back
Key takeaways
- Most automations do not break on launch day. They drift back down a level over the following months.
- Five things pull a routine back: the systems around it change, the work changes, the AI model changes, the owner moves on, and the approval goes soft.
- A rising exception rate, a spreadsheet kept on the side and an owner nobody can name are the early signs.
- A named owner, a monthly look at the run log, a quarterly check of the level and a test set re-run on every change hold a routine in place.
- Moving a routine down a level while you fix it is sound practice, not failure.
Launch day is the easy part. The automation is new, everyone is watching it, and the first week of runs looks clean.
The trouble comes later, and it is rarely loud. Six months on, the connector has been failing quietly since a vendor update, or the approval queue has become a person redoing the work by hand. On paper the routine is at level 2. In practice it has slid back to level 1, and the hours have gone back to where they were.
How the slide happens
Five things pull a routine back down the ladder. None of them is a bug in the original build. They are what happens to any system that sits inside a business that keeps moving.
The systems around it change. A vendor updates its software, a field is renamed, a new question appears on a form. A connection that worked on Friday fails on Monday, and if nothing is watching, nobody knows.
The work changes. A new service, a new type of client, a new price list. Cases the automation has never seen start to arrive, and each one becomes an exception. The exception rate creeps up a little every month until handling them takes longer than the original work did.
The model changes. AI providers update their models and retire older ones on their own schedule. A newer model is usually better overall, and it can still answer the same instruction differently. A routine that was tuned on one model can drift on the next without a single line of your own changing.
The owner moves on. The one person who understood the exception queue changes role or leaves. Nobody else knows what the queue is for, so it fills up, or it gets switched off.
The approval goes soft. At level 2 a person approves each run. After a few hundred clean ones, approval becomes a click. The step is still there. The control is not.
There is an older warning under all five. Lisanne Bainbridge's paper Ironies of Automation, from 1983, pointed out that automating the routine part of a job leaves people the hardest cases with the least practice. At level 3 that is exactly the job the exception queue does, so the skill to handle it has to be kept alive on purpose.
The signs it is slipping
Most slides show up in the run log well before anyone complains.
- The exception rate rises month on month.
- Approvals take a second each, or get skipped altogether.
- Someone keeps a spreadsheet on the side, just in case.
- Runs in the log fall while the volume of work does not.
- Nobody can say, straight away, who owns it.
Any one of these is worth a look. Two together mean the routine is already running at a lower level than anyone thinks.
What holds a level in place
None of this is expensive. It is mostly a calendar and a name.
A named owner. One person, written down, with time set aside for it. Not a team, and not whoever set it up.
A monthly look at the run log. Runs, exceptions, approvals and undos, compared with last month. Fifteen minutes is usually enough to see whether anything has moved.
A quarterly check of the level. Is the routine still at the right level? A routine that has run at level 2 for about ninety days with a low, steady exception rate may be ready for level 3. One whose exceptions are rising moves down.
A test set, re-run on every change. Keep a set of real past cases with the right answers. Run them again whenever the model, the instructions or a connected system changes, and compare the results before the routine goes back on real work.
A way back to manual. A stop switch the owner can use without calling anyone, and a written note of how to do the work by hand. Rotate who handles the exceptions so more than one person still knows how.
Moving down is not failing
When the signs show, the right move is often down a level. Put a person back on approval while the connector is fixed or the new cases are understood, then step back up once the log is steady again.
A level 2 routine that works is worth more than a level 3 routine nobody trusts. The ladder runs in both directions, and a routine that stays honest about where it sits keeps paying back.
That is also why looking after a routine after launch is part of the work, not an afterthought. Where automation stalls, and why covers the failures that happen before a routine ever gets this far.
If you have an automation that has started to slip, talk to us. If you want to know where your routines sit today, start with the free assessment.
Questions this answers
Why do automations stop working after launch?
The systems they connect to change, the work they handle changes, the AI model underneath is updated, the person who owned them moves on, or the approval step turns into a rubber stamp. Each one pulls the routine back down a level, usually without anyone deciding it should.
How do you know an automation is slipping?
The exception rate rises month on month, approvals take a second each or get skipped, people keep a spreadsheet on the side just in case, runs in the log fall while the work does not, and nobody can say who owns it.
How do you keep an automation working?
Give it a named owner with time set aside, look at the run log every month, check every quarter whether it still sits at the right level, and keep a set of real past cases to re-run whenever the model, the instructions or a connected system changes.
What should you do when an AI model is updated?
Re-run a saved set of real past cases with known right answers through the new model before it goes live, and compare the results. If they differ, find out why before the routine runs on real work.
