Measuring Manual Work Before Automation: Build the Baseline First

Most automation projects start with a savings figure. Somebody estimates how long a task takes, multiplies it by how often it seems to happen, and the result goes into the proposal: this will give back ten hours a week.

That number then does two jobs it was never measured for. It justifies the build, and after launch it becomes the thing the automation is judged against. If it was an estimate, the team cannot say afterwards whether the automation delivered, because nobody ever knew what the work cost before.

Measure before promising savings. The baseline takes about two weeks, costs the people doing the work a few seconds per item, and it usually changes the number in the proposal.

#Why estimates of manual work are unreliable

Estimates of manual work are unreliable because people remember the task, not the time. They recall the instance that went wrong and the afternoon it swallowed, and they forget the forty that went through without trouble. So the duration drifts up and the frequency drifts to whatever last week felt like.

The larger error runs the other way. An estimate describes the normal case, the item that arrives complete and goes straight through. It leaves out the item that came back with a wrong code, the one that sat waiting for an answer, and the one that did not fit the process at all. Those are rarely counted, and they are where the uncounted hours sit.

#Count how often the task happens from records

Frequency is the easiest number to get right, because something usually counts it already: a ticket queue, a shared mailbox, an export from the finance system, a form's submissions, rows added to a spreadsheet. Pull at least three months if the records allow it.

Look at the spread, not just the total. A task that averages 120 a month but runs at 300 in the last week of each quarter needs capacity for the peak, and a log kept in a quiet fortnight will make the task look smaller than it is. Note any peaks you find; they become assumptions later.

#Time sampling: a two-week log kept by the people doing the work

The duration has to come from the work itself. The simplest method that holds up is a time log kept by the people who do the task, as they do it, for two weeks that include whatever makes the process busy, such as a month end.

Keep the log small enough that nobody resents it. For each item: a reference, the time it started, the time it finished, and one word for how it ended: done, rework, waiting, or exception. Hands-on minutes only. If someone is interrupted, they stop the clock.

Two weeks matters for a specific reason. People work more carefully for the first day or two after being asked to time themselves, and the difference fades as the log becomes routine. A single run timed in a meeting measures that careful case and nothing else.

Tell people why the log exists. It measures the process, not them, and the most useful entries are the awkward ones.

#Include rework in the baseline

Rework is the second touch on an item that was supposedly finished: an invoice returned with the wrong cost code, a customer record corrected after the customer called, an order re-keyed after the warehouse rejected it. It is manual work in every sense, and it is the part estimates leave out most often.

Log rework as its own entry, linked to the original reference, so it can be counted separately. Two things come out of it. The first is how much time it takes, which in a messy process can rival the first pass. The second is where it comes from. Rework caused by bad input upstream will survive the automation unless the input is fixed, and automating the first pass faster can deliver the same bad data to the next team sooner.

#Separate waiting time from working time

Waiting time is how long an item sits between steps; working time is how long someone spends on it. An approval that takes three days to come back and ten minutes to give is ten minutes of work and three days of delay.

Measure both, and never add them together. Automating the effort gives back hours. Removing a wait, by routing an approval to whoever can give it or by dropping a step nobody can explain, gives back speed, and speed is often what the business actually wanted. They are different promises, measured in different units, and a proposal should say which one it is making.

#Tag the exceptions as you log them

An exception is an item that does not fit the process the automation would follow: no matching order, a supplier on an old template, a request that needs a judgment call. Tag it in the log when it happens and record how long it took, because exceptions tend to take several times longer than the normal case.

This is the part of the baseline that stops the savings figure being overstated. The automation will handle the normal path. The exceptions come back to a person, usually with extra diagnosis attached, which is why their share and their cost belong in the baseline rather than in a footnote after launch.

#An illustrative time log, and what it changes

The figures below are illustrative, not from a real engagement. They show the shape of a two-week log for one task, entering supplier invoices into a finance system, and how the summary differs from the estimate.

A few rows from the log:

Ref	Minutes	Outcome	Note
INV-2231	4	Done
INV-2232	3	Done
INV-2219	11	Rework	Wrong cost code, returned by approver
INV-2233	26	Exception	No matching purchase order
INV-2234	5	Waiting	Queried with supplier
INV-2235	4	Done

The two-week summary:

Measure	Result
Invoices entered	120
First-pass hands-on time	520 minutes
Rework, 14 items at about 12 minutes	168 minutes
Exceptions, 9 items at about 22 minutes	198 minutes
Total hands-on time	886 minutes, about 14.8 hours
Typical wait from receipt to entry	3 days, mostly awaiting approval

The estimate given before the log was four minutes an invoice, which is 8 hours a fortnight. The measured figure is nearly twice that, and 41% of it is rework and exceptions.

That changes the proposal in both directions. Today's work costs more than anyone thought. And automating the first pass does not remove the exceptions, which stay with a person, while some of the rework only goes away if the cost codes are fixed where they are entered. The honest savings figure sits below 14.8 hours, and it can only be stated once the exceptions and the cost-code fix are accounted for. The three-day wait is a separate problem with a separate fix.

#Write down the assumptions next to the numbers

Every baseline rests on choices, and they belong on the same page as the numbers: which weeks were logged and whether they included a peak, who kept the log, what counted as rework, which items were excluded and why, and how frequency was counted. Without them a figure gets quoted months later as if it were a law of nature.

The assumptions also fix the method for the second measurement. After the automation has run for a few weeks, log the same task the same way over a comparable period. The difference between the two logs is the saving, and it is the first number the project can defend.

Once a process has a baseline, the question of which process to automate first gets much easier to answer; we covered that ordering in how to prioritize an automation backlog. Building this kind of time cost into a map of the process is the first step of our business process optimization work. If there is a repetitive process your team would like gone, map it with us and put real numbers on it before anyone promises a saving.