How to Calculate the Cost of Manual Work
Reviewed by Nova Labs AI Operations
To calculate what a manual task costs, multiply the minutes it takes by how often it happens by the number of people involved, convert to hours, and multiply by the loaded hourly cost of those people. Annualise it using realistic working weeks. Treat error and delay costs as a separate estimated line, because they rest on assumptions the time figure does not.
| The formula | (minutes per occurrence x occurrences per period x people) / 60 x loaded hourly cost. |
|---|---|
| The input that matters most | Minutes per occurrence. Measure it. Remembered times are the single largest source of error. |
| Loaded cost, not salary | Total annual cost of employment divided by realistic working hours. Salary rate alone understates it. |
| What the number proves | That a process is worth investigating. It does not prove the process should be automated. |
| What to do with it | Compare against a modelled future state that includes review and exception handling, not against zero. |
Why most automation business cases are unfalsifiable
A familiar sequence: someone proposes automating a task, the proposal says it will save several hours a week, the tool is bought, and a quarter later nobody can say whether it did. The reason is almost always the same. The saving was asserted rather than derived, and the current process was never priced, so there was nothing to compare against.
McKinsey's State of AI in 2025 found that measurable impact tracked workflow redesign rather than adoption on its own. That is consistent with what pricing a process tends to reveal: the expensive part is usually the shape of the work, not the absence of a tool.
Pricing the current state is the cheapest step in the whole exercise and the one that makes everything after it arguable in a useful way.
The five inputs
| Input | How to get it | Common mistake |
|---|---|---|
| Minutes per occurrence | Time the task across a full cycle. A stopwatch or a timestamped log beats an estimate. | Asking people to recall it. Habitual steps vanish, irritating steps inflate. |
| Occurrences per period | Count from the system of record: tickets, invoices, jobs, emails. | Using a good week. Use an average and state the period. |
| People involved | Count everyone the work passes through, including approvers and chasers. | Counting only the person who owns the task. |
| Loaded hourly cost | Total annual employment cost divided by realistic working hours. | Using the salary rate, which excludes tax, benefits, and overhead. |
| Error and delay rate | How often it goes wrong and what the consequence costs. | Folding this into the headline figure instead of listing it separately. |
Getting the loaded hourly cost right
The loaded rate is the input people most often get wrong, and it typically moves the answer more than any other correction. Take the full annual cost of employing someone, including employer taxes, benefits, equipment, software licences, and a share of overhead. Divide by the hours they realistically work in a year after holiday, sickness, training, and internal admin.
- Salary = $52,000
- Employer taxes + benefits = $11,400
- Equipment, software, space = $6,200
- Total annual cost = $69,600
- Working weeks = 46
- Productive hours per week = 34
- Productive hours per year = 1,564
- Loaded hourly cost = $69,600 / 1,564 = $44.50
Loaded rate $44.50/hr, against a headline salary rate of about $28.60/hr.
Every figure above is an illustrative input, not a benchmark. Replace each one with your own. The point of showing the arithmetic is that the result changes by roughly 55 percent depending on which rate you use, so the choice is not a technicality.
The calculation
The core formula is deliberately plain:
- minutes_per_occurrence
- x occurrences_per_period
- x people_involved
- / 60
- x loaded_hourly_cost
- = cost per period
Applied to a concrete case: a firm processes supplier invoices by hand. Two people touch each invoice, one to enter it and one to approve it.
- Minutes per invoice = 9 (entry 6, approval 3, timed over 3 weeks)
- Invoices per week = 85 (12-week average from the finance system)
- Loaded hourly cost = $44.50
- Weekly minutes = 9 x 85 = 765
- Weekly hours = 765 / 60 = 12.75
- Weekly cost = 12.75 x $44.50 = $567
- Annual cost = $567 x 46 weeks = $26,082
Baseline: about $26,000 a year to process supplier invoices by hand.
Note what this number is and is not. It is a derived figure, reproducible from four stated inputs. It is not a saving. Nothing so far suggests that automation would remove $26,000 of cost, and assuming it would is exactly the error that makes business cases collapse under scrutiny.
Modelling the future state honestly
The saving is the difference between two modelled states, and the second one is never zero. An automated invoice process still needs someone to handle exceptions, review flagged items, and maintain the system. Model those minutes the same way you modelled the current ones.
| Line | Current | Modelled future |
|---|---|---|
| Invoices per week | 85 | 85 |
| Straight-through, no human touch | 0 | About 70 (estimated) |
| Exceptions needing a human | 85 | About 15 (estimated) |
| Minutes per exception | 9 | 11 (estimated, harder cases) |
| Weekly review and oversight | 0 | 40 minutes (estimated) |
| Weekly minutes total | 765 | 205 |
| Weekly cost at $44.50/hr | $567 | $152 |
| Annual cost | $26,082 | $6,992 |
Every figure in the future-state column is an estimate, not a measurement, and is labelled as such. The straight-through rate is the assumption doing the most work here. If it lands at 40 percent rather than 82 percent, the case looks materially different. Sensitivity to that one number should be stated in any business case built this way.
The modelled annual difference is about $19,000. Against that you set the build cost, the licence cost, and the maintenance burden. Now there is an argument that can be had on evidence rather than enthusiasm.
Where the estimate stops being trustworthy
Three failure modes account for most bad numbers we see, and all three are avoidable.
- Remembered times. If minutes per occurrence came from a conversation rather than a measurement, the whole figure inherits that uncertainty. This is the one to fix first.
- A good week used as the average. Volume taken from a single busy period inflates the annual figure. Use a multi-week average and say which weeks.
- Error costs stacked onto time costs. Time cost rests on observed minutes. Error cost rests on assumed failure rates and assumed consequences. Combining them into one headline number makes the solid part look as shaky as the speculative part.
When this does not apply
The work is genuinely variable. Some processes have no meaningful average occurrence. Creative and investigative work often falls here. Forcing an average produces a confident number that describes nothing.
The cost is not really time. If the actual damage is a slow response losing you deals, model response time and conversion instead. Time saved is the wrong unit for that problem.
The people would not do anything else. Recovered hours only become value if they are redeployed. If nobody can say what the reclaimed time will be spent on, the saving is theoretical, and it is more honest to describe the benefit as capacity or resilience.
The process should not exist. Sometimes pricing a workflow reveals that its output has no consumer. Deleting it beats automating it, and the calculation is what made that visible.
Next step
Price your three most repetitive processes. Take the largest number and do not buy anything yet: run it through a workflow audit to find out whether the cost comes from the tooling or from the shape of the process. Then choose one candidate using the scoring method.
Frequently asked questions
- What hourly rate should I use in the calculation?
- Use a loaded hourly cost, not the salary rate. Take total annual cost of employment including tax, benefits, and overhead, then divide by realistic working hours per year. Using the raw salary rate understates the true figure, often substantially.
- Should I count the cost of errors and delays?
- Count them separately and label them clearly. Time cost is comparatively easy to defend because it comes from observed minutes. Error and delay costs require assumptions about failure rates and downstream consequences, so present them as a separate estimated line rather than folding them into one headline number.
- Does a high manual cost mean I should automate the task?
- No. It means the task is worth investigating. A process that is expensive because it is badly designed should be redesigned before it is automated, or you will pay to run a broken process faster. Cost tells you where to look, not what to do.
- How accurate is this calculation?
- It is an estimate built from observed inputs. Its accuracy depends almost entirely on whether the minutes-per-occurrence figure was measured or remembered. Timing the work over one or two weeks typically moves the estimate more than any other refinement.
- What is a realistic saving to assume from automation?
- Do not assume one. Model the future state the same way you modelled the current state: estimate the minutes the new process will take, including human review and exception handling, and compare. Any saving figure that appears before the future-state process has been designed is a guess wearing a percentage sign.
Sources and method
- McKinsey, The State of AI in 2025
- Cited for the finding that measurable value tracks workflow redesign rather than tool adoption alone.
- Nova Labs calculation method
- The formula in this article is the one behind the Manual Work Cost Calculator. Inputs and arithmetic are shown in full so any figure can be reproduced or challenged.
Figures in this article are either cited to a named source above, derived from arithmetic shown in full, or labelled as an estimate with the assumptions stated. Last reviewed August 3, 2026.
Keep reading
The Complete Guide to AI Workflow Audits
An AI workflow audit measures a process before anyone proposes a tool for it. Here is the five-stage method, a worked example with the arithmetic shown, and the checklist we run.
How to Choose the First AI Use Case
The first AI project should be chosen for how convincingly it can be judged, not for how impressive it sounds. Here is the scoring method and a worked comparison.