Senthil Info

automating business processes, honestly

Counting Hours Honestly

Hours saved is the foundation of every automation business case, and the headline figure is almost always the gross one: instances per month, multiplied by minutes each, multiplied by twelve.

Four adjustments turn that into a number that survives the second year. Together they typically halve it, and the halved figure is still often a good case. A product-side example of how workforce software approaches this topic is available in learn more.

The four adjustments

One. Apply the straight-through rate. The saving applies to instances the automation actually completes. At a 20% exception rate, start from 80% of the volume — and if the model does not state a rate, it assumed zero. For broader background and an independent point of comparison, see Smartsheet.

Two. Subtract exception handling time, at the new rate. Not the old per-item time. Exceptions take longer once they are handled in isolation — a case that took twelve minutes inside a normal workflow can take twenty when it arrives alone, without the context the routine work provided.

Three. Subtract the new work the automation creates. Monitoring, restarting failed runs, checking output, handling the queue when a system is down. Small per day and continuous.

Four. Subtract maintenance. Rules change, formats drift. Somebody's hours, recurring, from year two.

Worked through

Take a process at 1,000 instances a month, 15 minutes each. Gross: 250 hours a month.

At an 18% exception rate, the automation completes 820 instances — 205 hours.

Exceptions: 180 cases, now taking 22 minutes rather than 15 — 66 hours, against the 45 they previously took. That is 21 hours worse.

Monitoring and output checking: perhaps 8 hours a month.

Maintenance: say 6 hours a month averaged.

Net: 205 − 21 − 8 − 6 = 170 hours, against a headline of 250. A third gone, and 170 hours a month is still a substantial saving.

The point is not that the case fails. It is that the honest number is knowable in advance and the gross one is not defensible in year two, when somebody asks why the team is the same size.

Cash or capacity

The distinction that decides whether hours become money.

Cash saving: you stop paying for something. A contractor ends, overtime stops, a vacancy is not filled. Real money, appears in a budget line.

Capacity gain: the same people have more time. Valuable and it is not cash until something else happens with the time — more volume handled, a backlog cleared, a hire deferred.

Most automation produces capacity and is reported as cash. Which is why headcount gets used as proof, and why it does not work as proof.

State them as separate lines. A case with 170 hours of capacity and no cash saving is honest and may still be worth approving — what fails is a case claiming cash that never appears.

What to measure after go-live

Three numbers, monthly, and the comparison is against your own pre-automation measurement rather than the model.

Instances completed without human touch. The actual straight-through rate.

Hours spent on exceptions. Logged, not estimated.

And hours spent on the automation itself — monitoring, fixes, changes.

Six months of that tells you the real saving, and it is the only version of the number anyone should defend in a review.

The short version