Redesigning a slow process with AI, without automating the wrong step
A process is too slow and the pressure is to automate it. The danger is that you point AI at the step that is easiest to automate rather than the one that is actually the constraint, and scale the wrong thing. Here is how to make AI define the goal and interrogate the step before it automates anything.
AI for process redesign starts with the goal, not the step. The trap is reaching for automation before you have defined what the process is meant to produce, because automation is a multiplier: point it at an efficient step and you magnify the efficiency, point it at a broken one and you magnify the mess, only now faster and at scale. The Havruta Methodology (formerly the Think Partner Methodology) installs the discipline that makes the machine name the outcome first, then interrogate the slow step through the Flip: what is this step for, what breaks if it disappears, which upstream cause makes it slow. You redesign toward the goal, then automate, so AI buys you Decision Velocity rather than High-Speed Waste. This is not a workflow tool. It is how the COO reasons with AI on the process they have to own.
The situation
A core process takes too long and everyone can feel it: the handoffs, the waiting, the rework. The board wants speed, your team wants relief, and there is a vendor in the room promising to automate the worst of it by next quarter. The pressure pushes you toward the step that is easiest to automate, which is rarely the step that is actually slowing the whole thing down. Speed without clarity just gets you to the wrong place quicker. The hard part is not finding something AI could do here. It is being sure the step you are about to scale is the one that should exist at all, and that the process around it is worth keeping before you make it permanent in code.
What commodity AI does with it
Ask an assistant to "automate this process" and it obliges at once: it takes the flow you described, finds the obvious manual steps, and proposes a bot here, an approval there, a tidy before-and-after. It reads like a redesign. But it has answered the easy question, which steps can be automated, and skipped the hard one, which steps should exist. It cannot see the goal the process serves, the upstream cause of the delay, or the cost of leaving the real bottleneck alone, so it paves the existing path rather than questioning it. You get a faster version of the same friction, and a slow process is now a fast one that still produces the wrong result.
Automation magnifies whatever it is pointed at
The oldest rule about business technology still holds, and AI sharpens it. Bill Gates put it plainly in Business @ the Speed of Thought: automation applied to an efficient operation magnifies the efficiency, and automation applied to an inefficient operation magnifies the inefficiency. AI does not change the rule, it raises the gain on it. Point it at a clean step and you scale the result. Point it at a broken one and you scale the mess, only it is harder to see now because the output looks busy and fast. The same step, two destinations. Which one you get is decided before any automation is switched on, by whether the step was the right step.
The Flip: make it interrogate the step, not automate it
The move that changes the task is to stop instructing the machine to automate and start making it question the request. Instead of "automate this step", the opening becomes "before you touch anything, tell me what this step is for, what would break if it disappeared, and which upstream cause makes it slow". An AI made to think that way does not hand you a bot; it hunts for the reason the step exists, tests whether the delay even lives there, and pushes the redesign back toward the goal before any automation is proposed. That is also the cure for the oldest excuse in operations, that the team is too busy running the broken process to stop and fix it. The Flip builds the pause-and-redesign moment into the dialogue, so the stop happens inside the conversation rather than waiting for a quiet week that never comes.
What the machine must ask before it automates
This is the part that proves it is redesigning your process and not a plausible average. Before it proposes a single automation, it has to request what the template cannot know:
-
What is the goal this process exists to produce, stated as an outcome rather than a set of steps?
-
Where is the real constraint: which step is actually throttling the whole flow, by cycle time and queue, not by how visible it is?
-
What is the upstream cause of the delay, and would the slow step even exist if that cause were removed?
-
What does the process map and defect data actually show: the real cycle times, rework rates, and handoffs?
-
What does it cost to leave the constraint unsolved: the do-nothing baseline each redesign is measured against?
Without those answers, an automation is a guess pointed at the easiest target. With them, the same slow step lands in a different place, redesigned, removed, or automated last rather than first, because the constraint is now named. That request is Ground Truth, the methodology's discipline of anchoring AI in your verified operation rather than its generic knowledge. And if the redesign still comes back as a bland "add an approval, add a bot" template, that is the Mirror Principle at work: a generic output is the tell that the input was generic, and the signal to go back and supply what the machine could not see.
Our order-to-cash process is too slow. Automate the manual approval step, it is the obvious bottleneck.
Before I automate anything, what is this process meant to produce, and is the approval actually where the time goes? What does the cycle-time data show, step by step?
The goal is cash collected faster. Looking at it, the approval takes a day, but orders sit waiting for data correction upstream for a week before they reach it.
Then automating the approval scales the wrong step: you would speed up a one-day task while the week-long wait stays. Why do orders need correcting at all? If the upstream data were clean, would the correction step, and maybe the approval, still need to exist?
The errors come from a form three teams fill differently. Fix that and most corrections disappear.
Then the redesign is to remove the cause, not automate the symptom. Let me lay out the new flow against your goal, with the correction step designed out, and only then point automation at what is left, so we magnify a clean process rather than a broken one.
What you walk away with
Not a faster version of the old process. A redesign where every step carries the reasoning that placed it: the constraint it sits on, whether it survives the goal, and only then whether automation magnifies it or removes the need for it. It tells you which step to automate, which to redesign, and which to delete, in that order. The output of a goal-first redesign worked on your operation rather than a template, the kind of work the COO is increasingly asked to lead as the process architect rather than the automation buyer.
- Delete the cause
The upstream data-correction step
Caused by a fixable form Real constraint - Redesign, do not automate as-is
The manual approval step
Mostly unnecessary once data is clean - Automate last
The obvious automation candidate
Clean step On the goal
The 4-Lines you can run yourself
-
Act as a sceptical operations architect who will not automate a step until its purpose is named, then as my process-redesign partner. Hold both seats.
-
Goal: a redesign of this slow process toward the outcome it exists to produce, where each step is kept, redesigned, deleted, or automated on purpose, not a faster version of the same flow.
-
Before proposing any automation, ask me detailed questions and for supporting data: the goal as an outcome, where the real constraint is, the upstream cause of the delay, the actual cycle times and defect rates, and the cost of leaving the constraint unsolved. Do not automate anything until you have what you need.
-
Ask one question at a time, step by step.
Frequently asked questions
How do you use AI for process redesign without automating the wrong step?
Define the goal before you touch a step. The failure is reaching for automation before you have named what the process is meant to produce, so AI scales activity nobody needed. Make the machine state the outcome, then interrogate the slow step: what is it for, what breaks if it disappears, which upstream cause makes it slow. You redesign toward the goal first and automate second. That sequence is what keeps AI from magnifying a broken process instead of fixing it.
Why is automating a broken process worse than not automating at all?
Because automation is a multiplier, not a fix. It scales whatever it is pointed at. Point it at an efficient operation and you magnify the efficiency; point it at an inefficient one and you magnify the inefficiency. AI makes that faster and larger, so a step that should have been removed now runs at scale, and the friction is harder to see because the output looks busy. You end up with chaos faster than efficiency, and a process that is more expensive to unwind.
How do I know whether AI is buying Decision Velocity or just High-Speed Waste?
Ask whether a decision got better or only an output got faster. High-Speed Waste is activity scaled without any decision improving: more throughput on a step that may not be the constraint. Decision Velocity is a decision cycle that is both quicker and sharper. Before you automate a step, name the goal it serves and the bottleneck it sits on. If you cannot, the speed you are buying is waste with a shorter clock, not value.
What is the COO role in AI-led process redesign?
To be the process architect, not the automation buyer. The COO sets the goal the process exists to serve, decides which step is the real constraint, and refuses to automate a step whose purpose has not been named. Operations leaders who move on AI without a settled goal end up automating steps in isolation rather than redesigning the process the step belongs to. The discipline is goal-first: identify the persistent problem, redesign toward it, then let automation magnify the result.
Our team is too busy running the broken process to stop and fix it. How does this help?
It builds the pause into the interaction rather than relying on a busy team to find it. Instead of instructing the machine to automate a step, you have it interrogate the request first: what is this step for, which upstream cause makes it slow, what would disappear if the process were redesigned. That question is the stop-and-think moment your schedule never offers. The redesign happens inside the dialogue, before any automation is bolted onto the existing flow.
How do I stop AI from handing back a generic redesign?
Treat a generic answer as a signal, not a result. If the machine returns add an approval, add a bot, you fed it a generic, ungrounded request and framed the wrong step as the whole problem. A bland output is the tell that the input was bland. Go back and supply the real process map, the defect data, the cycle times, the actual constraint. Once the machine reasons from your ground truth, the redesign stops being a template and starts being yours.
References
- Grant Thornton. "2026 AI Impact Survey Report." Grant Thornton, 2026 (fielded 23 February to 18 March 2026, n=950 business leaders).
- Cordon, C., Trantopoulos, K., Wade, M. R. "AI and the COO: Operational excellence in the AI era." I by IMD, 13 March 2026.
- Reeve, M. "Why automating a broken workflow with AI is a trap." MarTech, 13 February 2026.