Automating a Process Without Automating the Mess
The order of operations is measure, delete, then automate. Almost every project skips the middle step, and what it buys is the same process running faster, with a maintenance liability attached and a bad habit now encoded as a control.
· 13 min read · Written by Faceela Research & Editorial Team
There is an order of operations for automating a process, and it has three steps. Measure it end to end, including the waiting. Delete the steps that cannot justify themselves. Automate what survives.
Almost every automation project skips the middle step. It goes from a complaint straight to a build, and delivers the same process running faster — the same approvals, the same retyping, the same person on Thursday deciding whether the spreadsheet or the system is right. Only now there is software in the middle for somebody to maintain.
Automating a step you should have deleted buys a faster wrong answer and a maintenance liability. Worse, it makes the step permanent. A habit can be argued away in a meeting. A habit with a build behind it and a line in next year's support budget cannot.
That is the whole answer. The rest is how each step is run: how to time a process without buying anything, the four questions that kill a step, where automation belongs once it has earned the right to exist, and the processes to leave alone.
The arrangement you will find in almost every operation here
Walk into a mid-market company here and you will find the same three-part arrangement, in badly run companies and well-run ones alike.
The approval lives in a chat app. A purchase is agreed in a group. A price is conceded in a voice note. A signed sheet is photographed from a phone. This is not indiscipline — it is the only channel that reaches a general manager who is travelling, and it produces a decision the same day. The official channel does not.
The record lives in a spreadsheet. Usually a system was bought. The spreadsheet exists because it answers a question the system was never configured to answer, and because somebody competent built it in an afternoon rather than wait a quarter for a change request.
Between the two there is a person. Their job title says something else. Their Thursday says otherwise. They hold the chat, the spreadsheet and the system against each other, find the places the three disagree, and settle each by deciding which version looks likelier.
That person is invariably described as indispensable. They are not. They are a symptom of a business in which no document carries the decision, the record and the evidence in one place.
The instinct here is to automate the reconciliation. Resist it. A reconciliation that runs by itself is one nobody will ever have a reason to remove again.
The real cost is not that person's salary. It is what falls through the gap between the two records — a change agreed in a chat, built on Monday, and never priced because the chain that would have priced it starts three links later. That leak is larger than any clerical saving an automation project will produce.
Step one: time it, and time the waiting
Every business that asks for automation can tell you the process is slow. Almost none can say how slow, and none can say where the time goes. The second figure decides what to build.
Two clocks run on any process. Touch time is how long somebody is actually working on it: reading the request, checking the price, entering the line, signing the thing. Elapsed time runs from the start of the process to its end, and it is the clock your customer and your cash flow both experience.
In most approval chains the work takes minutes and the elapsed time takes days, and nearly all of the difference is a document sitting in an inbox or a decision waiting for somebody who is travelling. That gap is the whole opportunity, and it is almost never inside the step you were about to automate. You were going to automate the typing. The days are in the waiting.
One warning before anything is built on what you find. If the process consumes a figure that is already wrong — a stock quantity, a cost, an available balance — automating it propagates the error faster behind a more authoritative interface. The named causes of an inventory figure being wrong sit upstream of any workflow.
How to measure it this week, without buying a tool
- Pick ten completed instances from last month. Real ones, with the mess still in them. A clean example is the process you wish you had.
- Find the earliest timestamp for each. The message, the email, the date on the form — whatever proves the request existed.
- Find the last one. The point at which the thing was done, not when somebody filed it.
- List every handoff in between and stamp both ends. When it arrived with this person, when it left them.
- Split every gap in two: somebody was working, or it was waiting. Write what it was waiting for, in words. "Waiting for the GM to land" is a valid entry and usually the most important one.
Ten is enough. You are not producing a statistic but a shape, and the shape is visible by the fourth instance.
The measurement is also the intervention. Putting the elapsed times on a wall is usually the point at which people start removing steps themselves — the cheapest work in the exercise, and the reason our process work starts with the clock rather than the tooling.
| What the timing exercise finds | What people expected it to find |
|---|---|
| Days spent in one inbox, repeatedly, always the same inbox | Slow data entry |
| A second approver who has never once changed an outcome | A missing integration |
| The same figures retyped between two systems that both own them | Too few licences |
| A queue that moves only when somebody chases it in person | Staff who need training |
| A step whose output is read by nobody still working here | A reporting gap |
Step two: delete, which is the step everybody skips
This is where the money is, and it is skipped because it is uncomfortable. Deleting a step means telling somebody that the thing they have done every week for six years is not needed. Building an automation means telling nobody anything.
It is also the part of the work that shrinks the bill, which is why it belongs in a written diagnosis handed over before any price is agreed, in the way we run this kind of engagement. A deletion has to be recorded with a date and a name against it, or it comes back.
Put every step the timing exposed through four questions.
Who reads this? Name the person, not the department. If it is a report, find out whether it is opened. A step whose output has no reader is not a step, it is a residue.
What decision changes if it is absent? If the answer is nothing, it is not a control. If the answer is "we would find out later", ask how much later and what that costs.
Who asked for it, and are they still here? A large share of steps were introduced by one person after one incident. The step outlived both, and nobody now has the standing to remove it.
What is the actual consequence of it being wrong? Not the theoretical one — the one that happened last time. Weigh it against what the step costs in elapsed days, multiplied by how often it runs.
Most approval steps fail all four. A second approver who has never once refused is not a control. It is a delay with a signature on it, and the signature is what makes it look like governance. Three signatures below a threshold nobody has revisited since it was set is one control and two people assuming somebody else looked properly.
That is not an argument for having no controls, but for designing authority rather than accumulating it, which is separate work: discount authority is a matrix rather than a percentage, and purchase approval, credit release and write-off behave the same way. Design it once, on one page, with names and limits against them, and most of the queue disappears without anything being switched off.
The steps that look like waste and are not
Some steps fail the four questions on the surface and are load-bearing underneath. Deleting one of those is expensive in a way that shows up exactly once, years later, on the worst possible afternoon, and by then nobody remembers that it was a decision rather than an accident.
The clearest case is capture that exists for an event which has not happened yet. Recording a batch number at a production step has no reader today and changes no decision today. It decides one thing: whether, when a complaint arrives with a batch code on it, you recall a defined set of batches or recall everything you are not sure about.
That is a real answer to the second question, and it is the shape to look for — a step whose entire value sits in a future you would rather not have. Insurance, audit evidence and anything a regulator may ask for all read the same way on a process map: pure cost, no reader, no decision changed. Judge those against the event, not against the week.
The second case is a step defending an integrity nobody wrote down. When the person who owns a step argues hardest to keep it, that argument is information rather than obstruction. Hear it out before deleting anything. If it turns out to be habit you have lost twenty minutes, and if it turns out to be knowledge you have avoided learning the same thing at full price. What is usually being defended is a real risk the process documentation never mentions, which is why the strongest resistance comes from your most competent people.
Step three: automate what survives, and prefer configuration to code
Now, and only now, you are automating a process that deserves to exist. What is left to decide is where the automation lives, which matters more than which tool you pick.
It belongs inside the system that owns the record. Approval rules, escalation, scheduled actions, document generation and portal access are standard capability in most ERPs, switched off in most installations because nobody was asked to configure them. The first question is not which tool to buy but which of the things you already pay for you have never turned on.
A bot pointed at a user interface is the opposite of that: a workaround for a configuration nobody did, invisible to anyone auditing the document it touched, and broken by the next upgrade because a field moved.
| Where the automation lives | What it survives | What a change costs |
|---|---|---|
| Configuration inside the system of record | Upgrades, staff turnover, an audit | A setting, changed by your own administrator |
| Code inside the same system, version controlled | Upgrades, provided somebody maintains it | A developer, and documentation you own |
| A connector between two systems that will never merge | Its own vendor's release cycle | A support contract |
| A bot driving somebody's screen | Very little | A rebuild every time a screen moves |
Read the last column rather than the first. Every option can do the demonstration. The question is what it costs to change an approval limit in two years, and whether anybody inside your company can do it. There are cases where the bottom row is nevertheless the right answer — a boundary you genuinely do not control, for a defined period — and the four questions that separate those cases from the rest are set out in when a robot typing into your ERP is defensible and when it is a confession.
The same test settles the newest version of the argument. An agent that reads a request and acts on it belongs in the bottom row unless it has real permissions, a real audit trail and a named owner, which is the whole distinction between what genuinely runs in production and what is still a four-minute demo.
None of it changes the order of operations. An agent pointed at an unmeasured process with six approvals will execute six approvals, faster.
The notification can stay in WhatsApp. The record cannot
This compromise is worth making explicitly, because a policy banning the chat app will be ignored within a fortnight. Send the alert wherever the approver actually is — often the only way a busy person answers the same day, and same-day response is most of the elapsed time you were trying to recover.
What cannot stay there is the record. The approval has to land on the document, with a name, a timestamp and the version approved. Otherwise you are reconstructing a decision from a chat history two years later, in front of somebody with no reason to accept it: an auditor, a tax authority, or a client arguing a final account. Doing that without asking anyone to change where they work is a specific piece of design rather than a policy, and it is worked through in how to get the approvals out of WhatsApp while leaving the conversation there.
Underneath that sits a rule every capture step obeys. The entry has to start from the work rather than being a separate document about it, which is why enforcement produces full forms and a lower cost of entry produces true ones, and why a timesheet filled in on Friday is a memory rather than a record. A step gets done when doing it is easier than skipping it, and at no other time.
Why nobody can prove the automation worked
Here is the sequence that kills the budget in year two.
A process is automated and genuinely improves. Six weeks later somebody asks what it saved, and the answer is a slide carrying adoption percentages, because nobody recorded what the process cost beforehand. The improvement is real and unprovable, so it is treated as unproven, and next year the money goes somewhere that can produce a number.
The repair is simple, and all of it happens before anything is built.
- Record the baseline first. Elapsed time per instance, how many people touch it, corrections per month, exceptions per hundred. Step one already produced these.
- Measure the same thing afterwards, the same way. A different measure taken after the fact is a fresh claim, not a comparison.
- Expect it to look worse before it looks better. A number that deteriorates in month one is often a number finally being counted.
- Publish it whether it flatters the project or not. An organisation learns more from one honestly negative measure than from a year of green status reports.
None of that is specific to automation — it is the same small set of measures that tells you whether anything you implemented is working, and what to measure in the ninety days after go-live applies here unchanged.
There is one further step, and it is the one that decides whether the budget survives. Hours saved is not money until somebody names the route by which it becomes money, and the routes are few and specific: how to turn saved hours into a number a finance director will accept is the difference between a proven improvement and an unfunded one.
The processes not worth automating
This section is against our own interest. Some processes should be left alone, and taking the work anyway is how a consultancy earns a fee and loses a client.
Low volume. A process that runs four times a month and takes twenty minutes does not repay a build. Do that one by hand and spend the money on the process that runs four hundred times.
High judgement. If the decision at the centre of it is genuinely a judgement — a credit exception, a technical concession, a price on an unusual job — automation can route it and time it, but it cannot make it. Automating the judgement produces a rule that is wrong in the interesting cases, which are the only ones that mattered.
It changes every quarter. Anything driven by a policy still being argued about or a structure mid-reshuffle needs rebuilding before it has paid for itself. Wait until it stops moving.
The exception rate is high. As a rule of thumb rather than a measured threshold, once roughly a third of instances take a path other than the main one, the automation no longer describes your process. The exceptions go to the same people in the same manual way, now with a system to work around as well.
That last one deserves sitting with, because a high exception rate is almost never a technical fact. It means the rule was never settled: two departments hold different versions of when something applies, and the disagreement surfaces as exceptions. Automation then encodes an argument you have not had, on whichever side the person doing the configuration heard last.
The honest advice is to settle the argument. Sometimes that is a decision an owner has to make. Sometimes it is arithmetic nobody has done: whether an item is made to order or made to stock is decided by comparing your lead time against how long the customer will wait, and until that comparison exists, every planning workflow built on top of it gets overridden by hand within a month.
A related case is the one nobody says out loud. Automation does not work in a company unwilling to change how a decision gets made. If the managing director carries on approving everything personally by phone, no workflow holds: the exception is entered afterwards to make the record match, and the system describes a process that does not happen. That is worse than the chat app, which never claimed to be authoritative.
Missing data behaves the same way, and it is easier to miss because it looks like a reporting gap rather than an unsettled rule. Automate the collection of the facts by all means; do not automate a calculation that has nothing to calculate from. No workflow turns a costing process into a true one while the material, labour, machine time and scrap behind it were never captured in one place, which is why manufacturers cannot explain a margin movement.
Run this on one process this quarter
Not five. One — chosen because it runs often, crosses two departments, and irritates somebody senior enough to keep the exercise alive when it becomes inconvenient.
- Write down where the process starts and where it ends. Disagreement about the boundaries is the first useful finding.
- Time ten real instances end to end, splitting every gap into working and waiting.
- Put the result on a wall and hold one meeting in front of it, with the people who do the work.
- Run the four questions on every step. Delete what fails them, in writing, with a date and a name against each deletion.
- Settle the arguments the exception rate exposed before designing anything.
- Automate what is left inside the system that owns the record, configuration before code, and audit what you already pay for before buying anything new.
- Measure the same way you measured at the start, and publish the comparison unedited.
- Then pick the next one, easier because the organisation has watched the first one work.
Most companies have two or three processes that account for the bulk of the manual effort, and a long tail to leave exactly as it is. Getting that order right is worth more than any tooling decision inside it. If the honest next step is timing what you already have before anybody builds anything, that is where a process engagement starts — and a diagnosis that removes processes from its own scope is the one worth paying for.