Measure the hours before you choose the tool

The usual sequence runs like this. Someone senior sees a demonstration. A budget is approved for the department that seems most willing. Six weeks later there is a tool in place, a modest efficiency claim, and no way to check whether the claim is true, because nothing was measured before the tool arrived.

The sequence is backwards, and the cost of reversing it is about ten working days.

What gets measured

An audit records tasks, not opinions. For every person in the company, each recurring task is captured with four quantities:

1. Hours per week the task consumes
2. The share of it still performed by hand
3. The systems it touches, in the order it touches them
4. What it waits on, and who owns that wait

Those four numbers are enough to build a complete operational picture, because they compose. Tasks aggregate into workflows, workflows aggregate into departments, and the hours carry all the way up without anyone having to estimate at the top.

Why the order matters

A tool decision made before measurement optimises the step that is easiest to see. Measurement almost always relocates the constraint somewhere less photogenic: a queue, a handoff, an approval that sits with one person because of an access permission nobody has revisited in three years.

The formula that ranks candidates is unremarkable, which is the point:

const annualHours = hoursPerWeek * workingWeeksPerYear;
 
const recoverable =
  annualHours * manualShare * automationPotential;
 
const annualSaving = recoverable * loadedHourlyRate;
 
const breakEvenMonths =
  implementationCost / (annualSaving / 12);

Nothing here is clever. What makes it trustworthy is that every input on the right hand side is a recorded quantity rather than an assumption, and every output traces back to the interviews it came from.

The input that decides the answer is automationPotential, and it is the one most often set by optimism. It is not the question of whether a model can perform the task on a clean input. It is the proportion of real cases that survive contact with the exceptions. Setting it to 0.9 rather than 0.55 does not make a project better; it makes the break-even date arrive on paper roughly eighteen months before it arrives in reality.

What changes as a result

Three things, consistently.

The first initiative is rarely the expected one. The department that asked loudest is usually not the one holding the largest recoverable figure. Volume of complaint and size of opportunity turn out to be unrelated quantities.

The business case survives contact with a finance team. A saving expressed as hours times a loaded rate, with the assumptions printed alongside, can be argued with. A saving expressed as a percentage improvement cannot be argued with, which is why nobody believes it.

The measurement continues. The same tasks are re-measured monthly, against the same baseline. If the saving does not appear in the record, the record is what gets reported, not the projection.

That last point is the one that makes the first two matter. A number that is only ever produced once is a forecast. A number produced every month against a fixed baseline is a measurement, and it is the only kind worth putting in front of a board.