There is a pattern to these projects. A company calls and says the work is slow and they want to automate it. They have usually picked the tool already. When we ask which specific step is slow, there is no clear answer.
That question typically sets the project back a few weeks — and those weeks produce most of its total value.
Why speeding up the wrong thing is worse
When a manual process is broken, it breaks slowly and visibly. Someone notices that something is off and stops it. That slowness acts as a safety brake nobody designed.
Automate the same process and you remove the brake. Now the error propagates at machine speed, and because it is all "automatic", nobody is watching.
Automation amplifies the process — good or bad.
Signs you are not ready to automate yet
- Two people on the team describe the path of an order differently.
- Nobody knows how long it takes from entry to delivery.
- There is no rule for "special cases" and each one is decided ad hoc.
- Steps exist that nobody can explain the origin of.
If two of these are true, whatever tool you buy will eventually reproduce the same disorder at greater expense.
What to do instead
- 01Follow one real caseTrack a single order or file from arrival to completion and note every handoff. It is usually twice what you expected.
- 02Separate waiting from workingIn most processes the effective work is a few minutes and the rest is waiting. Automation affects the waiting, not the working.
- 03Delete firstAny step whose purpose you cannot state in one sentence is a candidate for removal. Deletion is the cheapest optimisation there is.
- 04Then automateWhat remains now deserves automating — and is easier to build, because its rules have become clear.
On projects that follow this order, the build phase is usually shorter than the client expected. Not because the tooling is simple, but because by the time we get there, no ambiguous decisions are left.