Any vendor who answers this with a percentage is guessing about your business. The savings depend on your volumes, your salary costs, and how much of the work is genuinely repetitive — none of which an industry average knows. What follows is the calculation you can run yourself, before signing anything.

Why published averages are unreliable

Cost-saving statistics circulate widely and rarely survive scrutiny. They tend to come from self-reported vendor case studies, measure a single best-case deployment, and omit implementation cost entirely. A figure drawn from a thousand-person enterprise automating invoice processing tells you very little about a thirty-person firm automating call handling.

Treat any number you did not calculate from your own volumes as marketing rather than evidence.

The calculation that does work

Savings from a process come down to four numbers you already have or can measure in a week: how often the task occurs, how long it takes, the fully loaded hourly cost of whoever does it, and the share of it that can realistically be automated.

Multiply the first three for the annual cost of the process today. Multiply by the fourth for the realistic ceiling on savings. That ceiling, not a vendor's percentage, is the number worth discussing.

  • Frequency: how many times per week the task runs
  • Handling time: how long one instance genuinely takes, measured rather than estimated
  • Fully loaded hourly cost: salary plus overhead, not salary alone
  • Automatable share: the portion that does not need judgment, typically well below 100 percent

The costs most estimates leave out

A savings figure is only meaningful net of what the automation costs to build and run. The build itself is the obvious one. The less obvious costs are the ones that determine whether a project pays back.

  • Implementation and integration effort
  • Ongoing platform, model, and infrastructure usage
  • Internal time spent on process mapping and review
  • Monitoring, tuning, and handling exceptions after launch

Savings that are real but harder to price

Some of the largest returns do not appear on a labour-cost line. A call answered instead of missed is revenue that would not otherwise exist. A document error caught before submission avoids rework whose cost is real but unbudgeted. Faster response on inbound enquiries changes conversion rates.

These belong in the business case, but they should be stated as estimates with their assumptions visible — not blended into a single headline figure.

A worked example, with the assumptions visible

Suppose a five-person admin team spends a combined ten hours a week extracting data from supplier invoices. At a fully loaded cost of sixty dollars an hour, that process costs roughly thirty-one thousand dollars a year. If eighty percent can be automated — leaving exceptions to a person — the ceiling on annual savings is about twenty-five thousand.

Whether that is a good investment depends entirely on build and running costs, which is why the honest sequence is to scope first and quote second. The numbers here are illustrative; substitute your own.

How to protect the estimate

Measure the baseline before anything changes, and measure it the same way afterwards. Agree what counts as success before deployment. Keep the first project small enough that the result is unambiguous — a clear answer on one process is worth more than a contested estimate across five.

Frequently asked questions

What is the average ROI of AI automation?

There is no credible average, and figures quoted as one usually come from vendor case studies that exclude implementation cost. The defensible approach is calculating the number from your own frequency, handling time, and fully loaded labour cost.

How quickly does AI automation pay for itself?

Payback depends on the ratio between the annual cost of the process and the cost of automating it. A high-frequency process with a simple integration pays back far faster than an occasional process requiring custom development, which is why scoping precedes pricing.

Should we count headcount reduction as savings?

Usually not, and it is often the wrong goal. Most automated work is work nobody was hired to do. Counting capacity gained — more volume handled by the same team — is generally both more accurate and easier to defend internally.

What ongoing costs should we budget for?

Platform and model usage, monitoring and tuning, and the internal time spent reviewing exceptions. A savings figure calculated without these is a gross number, not a net one.

How do we measure savings accurately?

Capture the baseline before you deploy, using the same method you will use afterwards. A baseline reconstructed from memory after go-live is the single most common reason automation results are disputed later.