The short answer: Automating a broken process does not fix it. It runs the break faster, and it often removes the people who were quietly catching the errors. Before you automate, ask which kind of broken you are looking at: broken steps, conflicting targets, an unowned decision, or a workaround for something you already own. Each one needs a different response, and automating the wrong kind locks the real problem in.
The usual advice is “fix the process first, then automate.” You will find it on vendor blogs and consultancy guides alike. Canarlo puts it cleanly: automation does not correct inconsistency, it runs it faster and at higher volume.
I think that advice is half right.
It treats the process as the root cause. In my view, most processes that look broken are doing exactly what they are rewarded to do. Automating them, or even “fixing” the steps and then automating, encodes the same cause in a cleaner diagram.
I am an economist by training, with fifteen years in business analysis and commercial control inside multinationals, and roughly eight years running a business and technology consulting agency. I am writing this from the side of the person who signs off the spend, not the side that sells the build.
What happens when you automate a broken process?
You scale the break, and you remove the humans who were absorbing it.
A person doing a messy process catches some of the mess without writing it down. Canarlo’s examples are good ones: they notice a form looks wrong, they remember that one client wants invoices worded differently, they pause on an edge case that does not feel right. That judgment quietly absorbs a lot of inconsistency. None of it is in the process map. It is the safety net.
A bot has none of that. It runs the rules it was given, on every case, the same way. Errors that used to be occasional and caught become constant and invisible, because nobody is watching each one go through.
That is the part the commodity answer underweights. Automating a broken process does not only make the break faster. It removes the people who were the error correction.
Is the process actually broken, or doing exactly what it is rewarded to do?
This is the question I start with.
A process that looks broken from outside is often a rational response to something else: two targets that cannot both be met, a decision that sits with nobody, or a capability the company already owns and never switched on. In those cases the steps are not the disease. They are the body’s adaptation.
Steven Kerr named the incentive version of this in 1975. His paper in the Academy of Management Journal, “On the Folly of Rewarding A, While Hoping for B”, describes reward systems that “pay off” for one behavior even though the rewarder hopes dearly for another. The abstract is free to read; the full paper is paywalled on the publisher’s site. In my view the people inside those systems are not failing. They are succeeding at the wrong instruction.
I have written about that pattern when two departments hit their numbers and the company lost margin. The argument between them was the evidence. I think automating either side’s workflow would only have made the contradiction run on a schedule.
So before you tidy steps, ask why the process survived. If it is faithful to a bad instruction, fixing the steps alone will not help.
Ten questions to ask before the money moves
Real cases where the problem was not the one anyone named, the questions that would have caught them, and what a dodge sounds like. Free, and you join the weekly letter. Confirm the link I send and you are in. Unsubscribe any time.
How do you tell which kind of broken process you have?
I use four kinds. This is my own working framework, not a published one, and the names are plain on purpose. For each one, automating does something different, and so does the right next move.
1. Broken steps
The sequence is wrong, ownership is unclear, or there is no real review. Two people do the same task differently. Exceptions are the normal path.
What automating it does: locks in whichever version happened to get built, and removes the humans who were catching the gaps.
What to do instead: map how it actually runs, name an owner, write the steps so the same input produces the same output, and run the fixed version by hand long enough to see ordinary cases. Canarlo’s consistency audit is a workable checklist for this kind. Only then automate.
2. Conflicting targets
Two teams are measured on goals that cannot both be true. Volume versus margin. Speed versus quality. Close the deal versus deliver the deal at a profit.
What automating it does: makes each side hit its number faster, and accelerates the damage at the seam between them. The dashboard stays green. The company gets worse.
What to do instead: put every department’s annual target on one page and read them as a single instruction. If one person could not satisfy them all, rewrite the targets before you touch a workflow tool. I walked through that diagnostic in Everyone Hit Their Number.
3. An unowned decision
Something important sits with nobody. Approvals bounce. Exceptions wait for a person who was never named. Or the room doing the work is not the room that can decide.
What automating it does: builds a faster path into a dead end. The bot escalates to a queue that still has no owner, or it routes work to people who cannot say yes.
What to do instead: name one person who bears the consequence of the decision and give them the decision, in writing. Then design the process around that person. If nobody will take it, you have found the real problem, and no workflow tool will solve it.
4. A workaround for something you already own
People re-key data, chase paperwork, or wait on a desk because a capability inside software the company already licenses was never switched on. The manual chain looks like the problem. It is the adaptation.
What automating it does: builds a second, paid system on top of a first system you already own. You now maintain two ways to do the same job, and the original license still sits unused for the part that mattered.
What to do instead: take the painful manual process and ask what you already own that touches it. Open the plan you pay for and read what is included, not what you currently use. I have seen this end with switching on a capability that was already on the invoice.
If you only remember one thing from this section: do not automate until you know which of the four you are in. Automating kind 1 after you fix the steps can be right. In my view, automating kinds 2, 3, or 4 almost always encodes the real problem.
What did Tesla’s 2018 Model 3 ramp show about automating too early?
A public case, because the primary sources are open.
In April 2018, Tesla was struggling to ramp up Model 3 production. CBS News framed its report as a period of “production hell.” That phrase is in CBS’s narration, not in Musk’s answers in the interview. During a factory tour, Gayle King asked him: “In some cases, the robots actually slowed the production. Right?” Musk answered: “Yes, they did.” In the same interview he said: “We put too much new technology into the Model 3 all at once.”
The same day, Musk posted: “Yes, excessive automation at Tesla was a mistake. To be precise, my mistake. Humans are underrated.” Reuters and TechCrunch reported the wording. The post is at x.com/elonmusk/status/984882630947753984.
A few weeks later, on the Q1 2018 earnings call, Musk gave a concrete example. Tesla had built a robot to place fiberglass mats, which he called “basically fluff,” on top of battery packs. According to Slate’s account of the call, he said the line kept breaking down because the robot would often fail to pick up the fluff, or put it in a random location. When Tesla tested the car with and without the mats, there was “no change in the noise in the cabin.” Tesla concluded the part was unnecessary and did away with the robot.
Tesla’s own First Quarter 2018 Update, filed with the SEC, put it in writing: “we made a mistake by adding too much automation too quickly.” In select areas where fully automated processes had struggled to ramp, Tesla “temporarily dialed back automation and introduced certain semi-automated or manual processes.” The same letter says automation had been very successful through the vast majority of Model 3 production, and that Tesla remained “as committed to it as ever.”
I read this as an order problem, not a robot problem. Steps were automated before they were understood and stable, and at least one of them turned out not to be needed at all. That is my reading, not Tesla’s. Tesla’s words are the ones quoted above. In the terms of this post, it is kind 1: genuinely broken steps, found by running them.
Should you fix the process before you automate it?
Yes. And “fix” has to mean “find why it is this way,” not “draw a tidier flowchart.”
If you only tidy the steps, you risk encoding conflicting targets, an unowned decision, or a workaround into a cleaner diagram, then paying someone to automate that diagram. You will get a neat system that faithfully produces the same bad outcome, with better reporting.
The right sequence, in my view:
- Name which of the four kinds you are in.
- Fix the cause that belongs to that kind.
- Run the repaired version by hand until ordinary cases hold.
- Then automate.
That is slower than buying a tool. I think it is almost always cheaper than unwinding an automation that scaled the wrong thing.
What if you already own the fix?
Then the automation quote is not the decision. Looking at what you already own is the decision.
I wrote the longer version in They Already Owned the Fix. The short version: buying and using are different acts, done by different people, at different times. The expensive form of unused software is not a license nobody opens. It is a capability inside a tool you use every day that nobody switched on, because switching it on would require a team to change habits.
Before you sign a new automation build, open the plans you already have. Compare them to the three most painful manual processes. Anything in the overlap is something you have already paid for.
How do you know a process is ready to automate?
Vendor matrices usually look for the same signals. Softentgroup’s readiness guide is a fair example: frequency, stable rules, usable data, classifiable exceptions, an operational owner, bounded risk, and an observable outcome.
Those are useful. They answer “could we automate this.”
They skip the question that decides whether you should: is this the problem that costs money?
A process can be repetitive, rules-based, and full of structured data, and still be kind 2, 3, or 4 above. Scoring high on readiness and automating it anyway is how you get a successful project report and an unchanged P&L.
I wrote earlier about why AI automation agencies often deliver exactly what they sold while the business does not improve. That piece has three questions to ask before you hire. I will not repeat them here. Use them. Then run the four-kinds diagnostic on the process itself.
When is it fine to automate a messy process?
Honest limits matter, or this becomes dogma.
It is often fine when:
- The stakes are low. A failure costs minutes, not a client or a compliance problem.
- It is easy to reverse. You can turn it off, fix it, and rerun it.
- It is already consistent. The same input already produces the same output, whoever runs it.
Canarlo makes the same exception for low-stakes, reversible, already-consistent tasks. I agree with that limit.
There is a second exception, and this one is my opinion. Sometimes building a small, reversible automation is how you discover the break, because the build forces someone to write down every step and every exception. Use that discovery. Do not scale the automation until you have decided which kind of broken you found.
What should you ask before you sign an automation quote?
Do not start with the tool.
Start with the four kinds. Then, before you hire, use the three questions in Most AI Automation Agencies Are a Scam. Not for the Reason You Think. In my view, an agency that will not sit through diagnosis before it quotes is selling a tool, not solving your problem.
If you want the longer list I use before money moves, get my free Ten Questions guide.
Related reading
- Most AI Automation Agencies Are a Scam. Not for the Reason You Think.: the three questions to ask before you hire, and why delivery is not the same as improvement.
- Everyone Hit Their Number: conflicting targets that look like a personality clash.
- They Already Owned the Fix: when the manual chain is a workaround for software already on the invoice.