A rough calculation is useful if its assumptions are visible. 'This task wastes thousands' is less useful than knowing how often it happens, how long it takes and what a replacement would cost to run. Start with observations rather than a headline saving.
Measure the current effort
Choose a defined task and a representative sample. Record the number of items, time spent handling them and time spent correcting mistakes. Include the people who review or approve the output. Use a range when the work varies.
A simple model is annual task time = items per week × average minutes per item × working weeks ÷ 60. Keep the number of working weeks explicit rather than assuming the task happens every week of the year.
A hypothetical calculation
Suppose an illustrative business handles 80 requests a week at six minutes each for 46 weeks. That is 368 hours a year. At an assumed £25 per hour for the relevant employment cost, the model values that effort at £9,200. These are example inputs, not client results or a promised saving.
If a replacement reduces average handling to two minutes, the model releases about 245 hours. It does not automatically reduce payroll by the corresponding amount. The team may use that capacity to handle more work, respond sooner or reduce pressure.
Subtract the effort that remains
Include review time, exceptions, checking failed runs, software subscriptions and maintenance. Add one-off costs for design, implementation, migration and training. Consider what happens when the systems involved change.
For the example, compare several scenarios rather than a single optimistic number. What if only half the requests are suitable? What if exception handling takes longer? A decision that works only under the best assumptions deserves a smaller pilot.
Keep other benefits separate
A more reliable process may improve customer response times or reduce lost work. Record those outcomes and how you will measure them. Avoid assigning a speculative cash value simply to make the business case larger.
Likewise, the cost of an error depends on context. Do not invent a standard industry error rate. Use your own observed rework and describe any risks that remain uncertain.
Validate before scaling
Run a bounded pilot, compare similar work and replace estimates with measured results. Measure whether automation helped includes how to avoid confusing a faster normal path with a better overall operation. If the task itself is unnecessary, remove it before automating it.
