When a team is overloaded, the instinct is to automate. Find the tool that does the repetitive part, connect it up and give people their time back.
Sometimes that works. Often it doesn't, and the reason is almost always the same. The process being automated was carrying work that should never have existed. Automation made that work faster. It did not make it go away.
Before you automate anything, find the duplicated work.
What duplicated work looks like
Duplicated work is rarely obvious. It hides inside processes that everyone accepts as normal. A few common patterns:
- Re-entry. The same information typed into two or three systems because they don't share data. A new client's details go into the CRM, the finance system and a spreadsheet someone keeps "just in case".
- Reconciliation. Time spent checking that two sources agree, because nobody trusts either one on its own.
- Shadow records. Personal spreadsheets, notebooks and email folders that exist because the official system doesn't do what people need.
- Re-formatting. Reports rebuilt by hand each month because the data comes out in the wrong shape.
- Chasing. Emails and messages asking where something is, because the process has no visible status.
Each of these feels small in the moment. Together, they can consume a surprising share of a team's week. And each is a symptom of a process or system design problem, not a lack of automation.
Why automating first goes wrong
Say a team spends hours every week copying data from one system into another. The obvious fix is an integration that does the copying automatically.
But ask a different question: why does the data need to be in both places? Sometimes there is a good reason. Often there isn't. One system was bought for a purpose it no longer serves. Or the second copy exists because the first one was once unreliable, and nobody went back to check whether it still is.
If you automate the copying, you have built and now have to maintain an integration that props up a design nobody would choose today. You have also made the duplication harder to see, because nobody feels the pain any more.
Automating a broken process just makes it break faster, and more quietly.
How to find it
Finding duplicated work doesn't need a large program. It needs close attention to how work actually moves. Here is the approach I use.
Pick one process and follow it
Choose a process that matters and that people complain about. Then follow a single piece of work from start to finish: one enquiry, one invoice, one new staff member. Not the documented version. The real one.
Talk to the people doing it
The people who do the work know exactly where the friction is. They have usually built workarounds to cope with it. Ask them what they do, what they wait for, what they check twice and what they keep outside the system. Listen for phrases like "just to be safe", "I always double check" and "I keep my own copy".
Mark every touch
Each time a person handles the work, write it down. Who touched it, what they did and why. Then look for patterns: the same information entered twice, a step that only exists to fix an earlier step, a handoff that adds nothing but delay.
Ask why each step exists
For every step, ask what would happen if it stopped. Some steps are essential. Some exist for a reason that disappeared years ago. Some exist because another step is unreliable. That last group is where most of the value is.
Then decide what to automate
Once the duplicated work is visible, the options become clearer. In rough order of preference:
- Remove it. If a step exists only to compensate for something that no longer applies, stop doing it.
- Simplify it. Change the process so the information is captured once, in the right place, by the right person.
- Fix the source. If people keep shadow records because the official system is wrong or incomplete, fix the system.
- Automate what remains. Now automate the steps that are genuinely necessary, stable and repetitive.
By the time you reach step four, the automation is usually smaller, cheaper and more reliable than the one you would have built at the start. And the process it supports is one you would actually choose.
A practical test
Before approving any automation project, ask one question: if we were designing this process from scratch today, would this step exist?
If the answer is no, you don't have an automation opportunity. You have a design problem. Solve that first. The time you get back will be greater, and it will last.