Business process automation gets sold as removing work. That is the outcome, sometimes. The activity itself is different and less glamorous: it is writing down what actually happens, precisely enough that a machine can follow it, including every way it can go wrong.
Most automation projects fail at that step rather than at the technical one.
Business process automation starts with an undocumented process
Ask three people how an order gets from enquiry to dispatch and you will get three answers. Not because anyone is wrong, but because each of them knows a different part, and the parts have exceptions nobody has written down.
“We always invoice on dispatch, except for account customers, and except when it is a repeat order under a certain value, and except for that one client who wants a monthly consolidated invoice.”
Every one of those exceptions is real, and every one has to be expressed explicitly before anything can be automated. This is why the first phase of an automation project is mapping, and why it takes longer than clients expect. You are not documenting the process. You are discovering it.
Automate the boring middle, not the judgement
The best candidates share a shape: high volume, low judgement, clearly defined inputs and outputs.
Copying data between two systems. Generating a document from a template. Sending a notification when a value crosses a threshold. Reconciling two lists. Chasing an approval that has gone quiet.
Poor candidates are the ones requiring judgement: deciding whether a complaint warrants a refund, whether a supplier delay needs escalating, whether an unusual order is a mistake or an opportunity. Attempts to automate judgement usually produce a system people quietly work around, which is worse than no system.
Failure handling is most of the work
The happy path is the easy part and typically a small fraction of the effort. The rest is what happens when things do not go to plan.
- The other system is down. Does it retry? How many times? How far apart?
- The data is malformed. Does the run stop, or skip the record and carry on?
- The same message arrives twice. Does that create two orders?
- Something failed at three in the morning. Who finds out, and how?
An automation with no failure handling is not an automation. It is a scheduled way of creating problems that nobody notices until a customer does.
Audit trails are not optional
When a person does a task and gets it wrong, you can ask them what happened. When a machine does it ten thousand times and gets it subtly wrong, you need a record.
Every automated step should log what it did, to which record, when, and with what result. This costs almost nothing to build in from the start and is painful to add later. In regulated environments it is a requirement rather than a nicety, but it is worth having everywhere, because the first serious question you will be asked is “why did it do that?”
The honest measure of success
Not hours saved, which is nearly always estimated optimistically and rarely revisited.
Better measures: how long the process takes end to end, how many items need human intervention, how many errors reach a customer. Those are countable before and after, and they are hard to argue with.
Be prepared for the answer that the automation saved less time than hoped but removed a category of error entirely. That is usually the more valuable outcome anyway.
Start small enough to finish
The instinct is to automate the biggest process. Resist it. Pick one that is annoying, well understood, and contained enough to complete in weeks rather than quarters.
You will learn more from finishing a small one than from being halfway through a large one, and the organisation gets evidence rather than a promise.
Our business automation work starts with the mapping rather than the tooling, because the mapping is where the real answers are.
Related reading
- API integration: what actually goes wrong between two systems — An API integration is easy to demo and hard to keep running. The failure modes that appear in month three, and how to design around them from the start.
- Why internal tools stop being used three months after launch — Internal tools rarely fail technically. They fail because they make someone slower, cannot express the exception, or have nobody who owns them.
- RFID or barcode: when the upgrade is actually worth it — RFID is not a better barcode. Choosing RFID or barcode depends on whether you must count many things at once, and what the tag cost does to your margin.