Five Signs Your Company Should Not Automate Yet
Size is the wrong question. Five conditions decide whether automation pays now, and failing any one of them is usually a reason to wait a quarter.
Size is the wrong question
The question comes in a standard shape: are we big enough for this yet?
It has no useful answer, because the arithmetic that decides it does not track headcount. A twelve-person rental business with four hundred bookings a month has more automatable volume than a two-hundred-person consultancy where every engagement is bespoke. Size correlates with a couple of things that matter, and it predicts none of them well enough to use.
Five conditions do decide it. Failing one is usually a reason to wait a quarter.
One: the volume has to divide the build cost
Automation economics are a fixed cost spread across throughput. That single sentence explains most projects that disappoint.
A process that runs four hundred times a month and saves fifteen minutes each time is a straightforward case. The same process at eighty times a month has the same build cost spread across a fifth of the benefit, and it usually fails honest arithmetic even though the per-run saving is identical.
Take the volume from your own systems rather than from an interview, use the low month rather than the good one, and ask what the payback looks like if the volume never grows. The four questions that break most ROI numbers go into the rest of that arithmetic.
Two: the process has to hold still
It needs to be recognisably the same process at the end of the payback window, which for us is three to six months.
The test is concrete. Describe the steps as they were six months ago and as they are now. If the difference is in the edge cases, you are fine, because edge cases are what the exception queue is for. If the sequence itself has changed twice, you are automating a design that is still being drawn, and a process that changes materially every month gets rebuilt three to six times before the payback arrives.
Waiting for it to settle is much cheaper than rebuilding it, and it is not close.
Three: someone inside has to own it
One named person, whose job makes the workflow theirs after the vendor leaves, with enough authority to change it without a committee.
Not the person who signed the contract. Usually not the most senior person in the room. What the owner does is unglamorous: watch the exception queue, notice when the volume shape changes, decide whether a new edge case gets a rule or a human.
Automation without an owner degrades quietly, and quietly is the problem. The dashboards keep looking fine while the exceptions pile up and staff invent workarounds around the system. If you cannot name the person before the project starts, fix that first. It costs nothing and it is the single strongest predictor we have.
Four: the data mess has to be the right kind
| Kind of mess | Automate now? | Why |
|---|---|---|
| Missing fields | Yes | The workflow can ask; gaps become visible when they matter |
| Inconsistent formats | Yes | Normalising is cheap and mechanical |
| Stale records | Usually | Automation surfaces staleness faster than people do |
| Two systems that disagree | No | Automating a contradiction executes it at speed |
The precondition is not clean data. It is a decided answer to which source is authoritative for each field the workflow depends on. Without that decision, automation does not clean the mess, it encodes it, and the disagreement gets executed faster than a person could have caught it.
Five: the bottleneck has to actually be here
The most expensive version of this mistake is a beautifully automated back office attached to a company whose real constraint is that not enough people are asking.
Operational automation makes a business faster at fulfilling demand. If demand is the shortfall, it makes you faster at doing less, and the efficiency gain is real and commercially invisible. The gain we measure runs forty to sixty per cent of the automated portion, not of the company, and if the automated portion is not the constraint then the company-level effect is close to nothing.
Test it by asking what would happen if the process took half as long. If the answer is that more work would get done and it has revenue attached, this is the right project. If the answer is that everyone would wait more comfortably, the money is better spent on the thing they are waiting for.
What to do with a "not yet"
The right response is rarely to do nothing for a quarter.
Measure. Pull the timestamps, count the volume in the low month, name the owner, and decide which system is authoritative for each disputed field. That work is useful whether or not you ever automate, it makes the eventual project shorter, and it is exactly the audit described in what a process audit must produce and demonstrated on a real operation in the measurement week.
We say no to projects on these grounds, and it is worth being direct about why that is in our interest as well as yours. A project that fails the arithmetic still fails after we have been paid, and the reference is worth more than the fee.
01Is there a headcount below which automation never makes sense?+
No, and the fact that people keep looking for one is the reason this question gets answered badly. The arithmetic is dominated by how often a process runs and how long each run takes, and neither of those tracks headcount reliably. A twelve-person equipment rental business handling four hundred bookings a month has more automatable volume than a two-hundred-person consultancy where every engagement is different. What headcount does predict is a second-order thing worth knowing: smaller companies more often lack a person who can own the result after handover, and larger ones more often have processes that three departments disagree about. Both are real obstacles, but they are obstacles about ownership and agreement rather than about size, and they should be tested directly instead of inferred from a number of employees.
02How stable does a process have to be?+
Stable enough that it will still be recognisably the same process at the end of the payback window, which for us is three to six months. That is a lower bar than it sounds, because most operational processes are far more stable than the people running them believe; what changes weekly is usually the exceptions rather than the main path. The test is concrete: describe the steps as they were six months ago and as they are now, and see whether the difference is in the sequence or only in the edge cases. If the sequence itself has changed twice, you are looking at a process that is still being designed, and automating a design in progress means paying to rebuild it three to six times before it settles. Wait for it to settle. The waiting is cheaper than the rebuilding and it is not close.
03What does 'somebody owns it' actually mean in practice?+
One named person, inside your company, whose job description makes the workflow theirs after the vendor leaves, and who has enough authority to change it without convening a committee. It is not the person who signed the contract and it is usually not the most senior person involved. What that owner does is unglamorous and decisive: they watch the exception queue, they notice when the volume shape changes, they decide whether a new edge case gets a rule or a human, and they are the one who says something is wrong before the reporting says so. Automation without an owner degrades quietly, because the dashboards keep looking fine while the exceptions pile up and staff invent workarounds. If you cannot name the person before the project starts, that is the thing to fix first, and it costs nothing.
04Our data is messy. Should we clean it first or automate first?+
It depends entirely on which kind of mess it is, and the distinction is worth ten minutes before deciding. Missing and inconsistent data is usually fine to automate around, because a workflow can be built to ask for what it needs, and in practice automation tends to improve this kind of mess by making the gaps visible at the moment they matter. Contradictory data is the dangerous kind: two systems that disagree about the same fact, with no rule for which one wins. Automating that does not clean it, it encodes it, and the disagreement gets executed at speed instead of being caught by a person who knew the second system was the reliable one. The precondition is not clean data; it is a decided answer to which source is authoritative for each field that the workflow depends on.
