Delivery2026-07-28
Measure the process before you automate it
The most expensive automation failures we are called in to fix all share one property: nobody recorded what the manual process actually cost, so nobody can tell whether the replacement is better.
- Author
- Hana Sørensen
- Published
- 28 JUL 2026
- Read
- 5 MIN
- Ref
- 855618
Every automation proposal we receive arrives with a saving attached. Almost none of them arrive with the measurement that saving was derived from. The number came from an estimate given in a meeting, usually by a manager rather than by the person doing the work, and it is nearly always wrong in the same direction.
That would be a minor problem if the estimate only affected the business case. It does not. It affects what gets automated.
The estimate is wrong about where, not just how much
When we sit with a team and time the work, the total is often close to what the manager guessed. The distribution rarely is.
A finance team told us their month-end reconciliation took two days. It did. But the two days were not spent reconciling. Eleven hours of it was spent waiting for a report that ran on a schedule set in 2017, and a further four were spent re-requesting access to a system that expired credentials every ninety days. The actual matching work — the part the proposed automation was aimed at — was under five hours.
Automating the matching would have taken four months and saved five hours a month. Changing the report schedule took twenty minutes.
This is the normal result, not an unusually embarrassing one. Process time concentrates in waiting, in rework and in re-keying, and none of those are visible to the person describing the process from memory. They remember the work. They do not remember the gaps between the work, because during the gaps they were doing something else.
What "measure it" actually means
It does not mean a time-and-motion study, and it does not need to take a month. Two weeks is usually enough, and three things are worth capturing.
Volume, by category. How many of these are there, and how do they split? The split matters more than the total, because it tells you what proportion of cases a rule could actually handle. A process where 85% of cases are one of four shapes is a very different proposition from one where the cases are all slightly different.
Elapsed time, not effort. Record when a case arrives and when it leaves. The difference between that and the hands-on effort is the queue, and the queue is frequently the entire opportunity. Queue time also has the useful property of being visible in system logs, so you can often reconstruct months of it without watching anyone.
Rework rate. How often does a case come back? Rework is the strongest signal available about where a process is genuinely fragile, and it is the number most likely to be missing from the original proposal, because nobody enjoys reporting it.
Here is what a fortnight of measurement produced on one month-end reconciliation, against the two days the process was believed to take:
| Step | Believed | Measured | Where it went |
|---|---|---|---|
| Waiting for the scheduled report | — | 11h | A schedule set in 2017, never revisited |
| Re-requesting expired access | — | 4h | Credentials expiring on a 90-day cycle |
| Matching transactions | 2 days | 4h 40m | The step the automation was aimed at |
| Investigating exceptions | — | 3h | 14 cases, 11 of them the same cause |
| Sign-off and filing | — | 1h 20m | — |
The automation would have taken four months and addressed the third row.
The uncomfortable part
Measurement changes what gets funded, and not always in the direction the sponsor wanted.
We have measured processes and concluded that the automation should not be built. Twice in the last two years the answer was a scheduling change and a permissions fix. Once it was that the process should be stopped entirely, because the report it produced was being read by nobody — we asked all eleven recipients, and the last person to open it had done so fourteen months earlier.
None of those are comfortable findings to deliver against a proposal someone has already socialised internally. They are all cheaper than the alternative, which is four months of build followed by a year of nobody being able to say whether it worked.
The baseline is also your defence
There is a second reason to measure, and it arrives later.
Automations get questioned at budget time. Somebody new looks at the line item and asks what it is for. Without a baseline, the answer is a story. With one, it is a comparison — this took 41 hours a month and now takes six, here is the measurement from before and the dashboard from after.
We have watched a genuinely successful automation get switched off because nobody could evidence its value to a new finance director. The work had been done well. The measurement had not been done at all.
What we do
Nothing gets built here until the baseline exists. It is the first stage of the engagement, it is fixed price, and the client keeps the findings whether or not they proceed — including in the cases where the finding is that they should not.
That is not generosity. It is the only arrangement under which we can honestly tell a client that the automation they asked for is not worth building.
