What not to automate
Almost every automation list we have seen started from the steps that are easiest to see, not the steps that cost the most. That mistake costs months.
The visible step is usually not the expensive one
Data entry looks like the waste. It is measurable, boring, and everyone agrees about it. But if the typing takes four minutes and the chasing that preceded it took twenty, you have automated the cheap part.
It is worth asking once: how long passes between a request arriving and it being handled, and where exactly does that time go? The answer is almost always surprising.
Three tests
Before deciding a step should run unattended, put it through these:
- Reversibility. If the action is wrong, how easily is it undone? Updating an internal field — easily. An email that reached a customer — not at all.
- Cost of error. A mistake that costs a few cents once in a hundred times is noise. A mistake that costs an order is not.
- Frequency. A step that happens twice a month almost never justifies automating, however irritating it is.
The approval point
When an action fails two of the tests, the answer is not to abandon automation. It is to stop before the last step.
The system does all the work: reads, understands, checks against the systems, prepares the action. Then it presents it for approval. The person is not redoing the work, they are reviewing a finished result — and that is the difference between twenty seconds and twenty minutes.
Why full autonomy is the wrong target
Many projects state zero human touch as the goal. In practice the price of that last stretch is very high: every edge case needs handling, and every edge case you did not think of becomes a silent failure.
A process that handles ninety percent by itself and stops gracefully on the remaining ten is almost always worth more than one that attempts a hundred and fails on a few percent without anyone noticing.
How to actually do it
Start with one process. Map it as it really happens, including the conversations on the side. Score each step against the three tests. Automate what passes and build an approval screen for what does not.
After a month you will know what genuinely stops and why. Then you widen it.
Questions that keep coming up
- Which business processes should not be automated?
- Steps that are hard to reverse, expensive when wrong, or rare. An email that has reached a customer cannot be recalled, and a step that runs twice a month rarely repays the work. The usual answer for those is not to skip automation but to stop before the final action and let a person approve it.
- Is full automation with no human involvement a good goal?
- Usually not. The last stretch to zero human touch is where the cost is: every edge case has to be handled, and the ones you did not anticipate fail silently. A process that handles ninety percent and stops clearly on the rest is normally worth more than one that attempts everything.
- How do I decide what to automate first?
- Measure where the time actually goes, not where it is most visible. Data entry is easy to see and often cheap; the chasing and checking around it is usually the expensive part. Pick one process, map it as it truly happens including the phone calls, and start there.
- What is a human-in-the-loop approval step?
- The system does the whole job — reads the input, checks it against your systems, and prepares the action — then presents the finished result for a person to approve before it is committed. The reviewer is checking, not redoing the work, which is the difference between twenty seconds and twenty minutes.
The short version
The right question is not what can be automated but what should be. The difference between the two is usually the difference between a project that lasts and one that gets switched off after a quarter.