%201.svg){kind=small}
Business process automation: why automating chaos just creates faster chaos
Business process automation is using software to run the repetitive steps people currently do by hand. It works when the process gets fixed first and automated second. That order is the whole job. Automate a broken process and you have not fixed it — you have made it fail faster, more consistently, and in places where nobody is watching.
Most teams start by choosing a tool. The tool is rarely what decides the outcome. The process underneath it is.
What happens when you automate a broken process?
Four things, reliably.
- Errors scale. A manual process makes mistakes at human speed, and a human usually catches them. An automated one makes the same mistake four hundred times before anyone opens the report.
- The mess disappears from view. Manual work is visible — you can see the person doing it, and they can tell you where it keeps getting stuck. Automated work is silent. The problem is still there. It has just stopped being anyone's job to notice it, which is not the same thing as being fixed.
- You cement the wrong design. Once a broken process is wired into a tool, changing it costs a rebuild. What was a workaround is now infrastructure.
- You start paying rent on the workaround. Every automated step needs maintaining. Automating steps that should not exist means paying, indefinitely, to keep alive work that should have been deleted.
None of this is an argument against automation. It is an argument about sequence.
What does good business process automation involve?
Most of the work happens before anything gets automated. In practice the sequence runs like this:
- Map what actually happens. Not what the SOP says. Not how anyone remembers it. Follow one real piece of work end to end and write down every step, every handoff, and every point where something sat waiting.
- Delete. Most processes carry steps that exist because of a problem that was solved three years ago. A removed step costs nothing to run and never breaks.
- Standardize what is left. If three people do the same job three ways, there is no process to automate. There are three processes and a coin flip.
- Automate the repetitive remainder. Pulling the weekly update together from several tools, re-typing the same numbers into a second system, routing, reminders, first drafts, summaries.
- Measure against the baseline you took in step one. If you did not take one, you cannot tell whether any of it worked, and neither can anyone else.
Steps one to three decide whether step four is worth doing at all.
How to tell whether a process is ready to automate
Not everything should be automated, and the ones that should not are usually easy to spot. This is the first check any business process automation project should run, and you can run it without us.
| What you see | What it means | Do this first |
|---|---|---|
| Three people describe the process three different ways | There is no process yet, only three habits | Get all three in a room, walk one real job through it, agree on one version |
| The steps change depending on the client or the job type | Several processes are wearing one name | Split them. Handle the most common one; leave the exceptions manual for now |
| One person's judgment is the actual process | The rules live in someone's head, not in the work | Write the rules down. Roughly half turn out not to be rules |
| Work reliably stalls at the handoffs | The problem is ownership, not speed | Name one owner per stage. Speeding up a handoff to nobody just gets the work to nobody sooner |
| It is repetitive, it is stable, and everyone describes it the same way | It is ready | Automate it |
Where AI belongs, and where it does not
AI is the sharpest version of this problem, because it is the easiest thing to point at a mess.
Pointed at a process that has been designed, it gives people their hours back. Somebody on your team spends Friday afternoon copying numbers out of one system and typing them into another. A team lead spends Monday morning pulling the weekly update together by hand from four different tools. An account manager rewrites the same client update every week. AI can take all three, and nobody will miss doing them. Asana's Anatomy of Work research puts the time knowledge workers lose to that kind of task — compiling status updates, moving approvals along, searching for files — at roughly 515 hours per person per year. That is category research across thousands of workers, not a result we measured, but it matches what we find when we count.
Pointed at an undefined process, AI produces confident output nobody can check, built on inputs nobody agreed on.
The test is boring and it holds up: can you write down in one sentence what a correct output looks like? If yes, AI can probably help produce it. If no, you are not automating. You are guessing at scale.
This is about hours, not headcount. Take that Monday-morning update off a team lead's plate and the time goes somewhere: the people on her team who are stuck, the client proposal half-written since June, the new hire nobody has had time to train properly. None of that is work a tool can do. All of it has been waiting.
You probably own more automation than you are using
Before anyone sells you new software: most teams own more capability than they have switched on. The project tool you already pay for has forms, templates, rules and reporting sitting unused. The document and email suite has routing and approvals in it. Getting more out of the stack you already own is usually the first move, and it is cheaper, faster and far less disruptive than a migration.
Modernizing with new technology is the second move, not the first. It earns its place when a tool genuinely cannot carry the work — not because the current setup looks untidy. Our workflow automation engagements run in that order for exactly this reason.
What it looks like when the order is right
A 150-person state government communications team was buried in ad-hoc requests. The fix was not a bot. It was one intake form, templated projects, and five visible stages every job moved through: to-do, in progress, blocked, in review, deployed. Eight weeks, train-the-trainer, internal champions left behind to run it. Ad-hoc requests fell 70%. Visibility into work in progress improved 80%. Three to five hours a week of meeting time was eliminated. Automation came after the stages existed, not instead of them. (Ohio Secretary of State case study)
A small services business in Seattle had hit a manual-process ceiling. Its founder put it plainly: "I wasn't running the business; the business was running me." The rebuild ran on Airtable and Google Workspace, because that suited the work — not because it is what we prefer to install. Internal resolution time dropped more than 60% and manual tasks halved.
The part worth noticing is the part that had nothing to do with automation. Once the data was visible, fulfillment costs turned out to be twice what the business had estimated, and the price was corrected immediately. Automating the old process would have produced the same wrong price, faster and with less friction to notice it. (NonStop Reviews case study)
Do this before you hire anyone
Forty-five minutes, one process, no software.
- Pick the process your team raises most often. Not the biggest one. The one that keeps coming up when people say what is slowing them down.
- Take one real job that went through it last week and write down every step in order, including every wait. Paper is fine.
- Mark each step as necessary, necessary but badly placed, or existing because of something that no longer exists.
- Delete the third category. You now have a shorter process, and it cost you nothing.
- Count what is left. Every step where a person moves information from one place to another without making a decision goes on your automation list. Everything else waits.
That is the method, and you can run it today. Any outside help worth paying for starts there anyway — doing it yourself first means you arrive with the answers instead of paying someone to find them.
Common questions
What should we automate first?
The step where a person moves information from one system to another without making a decision. It is repetitive, the correct output is obvious, and nobody enjoys doing it. Prove the pattern there, then widen.
How long before business process automation pays for itself?
It depends on how much redesign has to happen first. A stable process with an obvious handoff to remove can pay back in weeks. A process that three people describe three different ways will not pay back at all until that is settled — and settling it is usually where most of the return actually sits.
Do we need new software?
Usually not first. Most teams own more capability than they have turned on, and switching it on is faster and cheaper than migrating. New technology earns its place when an existing tool genuinely cannot carry the work.
Will this cost people their jobs?
Not the way we do it. What gets automated is the re-typing between systems, the weekly update assembled by hand from several tools, the approval that has to be carried from one system to another — the tasks nobody was hired to do in the first place. The person who spent Friday afternoon copying numbers between two systems spends it on the backlog instead. Teams do not run out of work. They finally get to the part that kept slipping.
If you want a second set of eyes on the process you just mapped, we run an operations diagnostic at no cost. Book a Completing discovery call and bring your map with you. No pitch attached.
