What a manual process actually costs

The hardest part of justifying automation is not the build. It is that the thing you want to replace has never had a number attached to it.

Salaries are already being paid. There is no invoice for “three days a month of copying data between two systems”. So the cost sits inside payroll, invisible, and competes badly against projects that have a clear line item.

Here is how to make it visible without pretending to a precision you do not have.

Measure the process, not the people

Start with one workflow and follow a single item through it end to end. Not the documented version — the real one, including the bit where someone checks a spreadsheet that is not mentioned anywhere.

For each step, record two things: how long it takes, and how often it happens. Nothing else yet.

Do this by sitting with the people who do the work, not by asking them to estimate. Estimates of one’s own repetitive work are consistently wrong in both directions, and asking someone to self-report how long they spend on something also tends to make them defensive about the answer. Watching is faster and produces better data.

The arithmetic

Once you have times and frequencies, the calculation is deliberately simple:

hours per month  = (minutes per item × items per month) ÷ 60
annual labour    = hours per month × 12 × fully-loaded hourly cost

Use a fully-loaded cost, not the salary figure — include on-costs, superannuation, and whatever your finance team normally applies. They will have a number for this. Using the raw salary understates the cost by a margin large enough to matter.

A worked example, with entirely made-up inputs so you can substitute your own:

Suppose invoice matching takes 6 minutes an item, and you process 900 invoices a month. That is 90 hours a month, or 1,080 hours a year. At a fully-loaded A$65 an hour, that is roughly A$70,000 a year.

Those numbers are illustrative arithmetic, not a claim about your business or anyone else’s. The point is the shape of the calculation: it produces a figure you can defend in a meeting, because every input is something you measured rather than something you assumed.

Then subtract the part you will still be doing

This is where most business cases overstate themselves.

Automation rarely removes 100% of a process. Exceptions still need a person. Someone still reviews the edge cases. Something still breaks at month end. If you claim the full A$70,000, the first person who has to actually run the new process will tell you the number was wrong, and they will be right.

Estimate the residual honestly — what proportion of items will still need human handling, and how long the exception path takes. Subtract it. A business case that survives contact with reality is worth more than one that looks better on the slide.

Count the costs that are not time

Some of the strongest arguments for automation are not about hours at all:

Error cost. What does a mistake in this process cost when it escapes? Not the average case — the bad one. A duplicate payment, a missed renewal, a compliance breach.
Latency cost. If the process runs weekly because it is manual, what does the delay cost? Slower supplier payments, slower customer onboarding, decisions made on stale data.
Key-person risk. If one person holds the whole process in their head, what happens when they are away for a fortnight? This one rarely gets counted until it happens.

These are harder to quantify than hours, so they usually get left out. That is a mistake, because they are frequently larger than the labour number and they are what actually causes the business pain.

What good looks like

You should end up with a page that says: this process consumes roughly this many hours a year, at roughly this cost, with these specific risks attached; automating the parts we can would leave roughly this much residual work.

Ranges are fine. “Between 800 and 1,100 hours” is more credible than a single confident figure, and it is more honest about how the measurement was done.

That page is useful whether or not you automate anything. Sometimes the conclusion is that a process should simply be stopped rather than automated — it turns out to produce a report nobody reads. That is a better outcome than automating it, and considerably cheaper.