A mid-sized business wakes up to the same internal complaint every morning: orders are waiting, invoices are stuck, and sales keeps asking why things have not moved. The reflex is predictable: automate the step that creates the most noise. If the warehouse is slow, add a workflow. If finance approves late, add a rule. If customer service answers manually, build a bot.
The first bottleneck is often the worst place to start automating.
My thesis is simple, and worth arguing with: the first visible pain point is not always the best automation target. Often, it is better to slow down, understand why that step exists, and decide whether it should be automated, simplified, or removed. The conventional advice — automate early to gain efficiency — is still right in many situations. But when the process is poorly designed, automation does not fix it; it hardens it.
Why the visible queue can mislead you
The most common mistake is confusing volume with cause. A team sees 80 tasks piling up at one stage and concludes that is the problem. In reality, that stage may simply be where the process reveals its flaws.
A common scenario: orders arrive incomplete from several channels, and someone manually checks them before they enter the ERP or reach the warehouse. The queue grows, leadership wants “people out of the loop,” and the conversation quickly turns to automation. But if 30 percent of orders arrive with ambiguous data, automating validation only speeds up returns, incidents, or exceptions.
Before automating, the signals worth watching are less glamorous than a demo, but far more useful:
- rework rate in the same step;
- number of exceptions per 100 cases;
- time spent clarifying data rather than executing work;
- approvals that exist only because of mistrust;
- differences in how each person performs the task.
If variability is the main issue, blind automation usually costs more than it saves.
The manual step that prevented a bigger mess
In a mid-sized distribution company, the team wanted to automate order release as soon as an order entered the system. The case was persuasive: too much waiting, too many calls, too much pressure at the desk. But when the process was reviewed, another reality surfaced: a small share of orders arrived with incomplete addresses, vague references, or last-minute changes negotiated by phone.
Automating that first step would have created an illusion of efficiency while sending errors downstream with no safety net. The fix was less dramatic: keep a short human check for doubtful cases, automate only the initial sorting, and change the intake form so minimum data became mandatory. The outcome was not “zero manual work,” but fewer interruptions, fewer urgent escalations, and fewer corrections later.
That is the uncomfortable point: real improvement is not always about removing people from a process. Sometimes it is about reserving human judgment for the decisions where it actually matters.
The uncomfortable choice: keep one step manual
This clashes with a common belief: that every manual step is inefficient by definition. Not always. In some processes, the cost of automating an exception is higher than the cost of reviewing it manually.
Keeping a manual step makes sense when:
- the normal case is stable, but exceptions are frequent and costly;
- the decision requires commercial context, not just rules;
- an automatic error would have high impact and be hard to reverse;
- the volume does not justify added complexity;
- the process is still changing every week.
The bad decision is not keeping human review. The bad decision is hiding it. When a team knows review exists but no one measures or limits it, the process becomes opaque. So the real question is not “automate or not?” but “which decision should remain human, under what criteria, and for how long?”
What to automate first instead
If the visible bottleneck is not always the best first target, where should you start? With steps that have three traits:
- Clear rules: they repeat in nearly the same way most of the time.
- Low cost of error: if something fails, correction is simple.
- High frequency: small gains add up over the month.
That usually means classification, basic validation, data copying between systems, internal alerts, or recurring document creation. By contrast, the exception, the ambiguous case, or the step that mixes internal politics with operational judgment is usually a poor first automation candidate.
The sign that you are improving is not that the process looks elegant. It is that interruptions drop, reviews decline, and the team stops operating in constant firefighting mode.
A practical test before you automate
Before automating a painful step, ask this: if this step disappeared today, would the problem shrink, or simply move downstream? If it would move, you have not found the right target yet.
Delaying automation can feel slow. But automating the wrong step early is far more expensive. At Codefuente, we often find that the best automation project does not start with tools. It starts with an honest conversation about where the real operating cost lives. Done well, that conversation prevents a lot of rushed implementations.