Skip to content
Devendra Jangiddevendra.pro
Automation7 min read

How to calculate automation ROI before you spend anything

A step-by-step method for costing manual work, ranking automation candidates by return, and avoiding the automations that feel urgent but pay back slowly.

D

Devendra Jangid

ERP Consultant & Business Technology Integrator

Automation projects get chosen by irritation. Whichever task annoys the loudest person gets automated first. Sometimes that is also the highest-return task. Usually it is not.

Here is a method that takes about a day and consistently reorders the priority list.

How do you find the work worth automating?

Spend a day observing. You are looking for anything where a human moves information without adding judgement:

  • Re-typing data from one system into another
  • Building the same report on the same schedule
  • Chasing approvals through messages or email
  • Copying details from a document into a form
  • Checking whether something happened, repeatedly
  • Reconciling two lists that should already agree

Ask people directly what they find tedious. Tedium is a reliable marker for work that requires no judgement — and work requiring no judgement is exactly what software should do.

How do you cost a manual task?

For every task, record minutes per occurrence, occurrences per week, and the loaded hourly cost of whoever does it (salary plus benefits and overhead, roughly 1.3x base).

Annual manual cost = minutes ÷ 60 × occurrences per week × 52 × loaded hourly cost.

Time the task by watching it, not by asking. Self-reported estimates are wrong in both directions: people overstate tasks they dislike and dramatically understate frequent short interruptions. A two-minute task done forty times a day is over five hours a week, and nobody ever reports it as significant.

Count the error cost too

Manual data movement produces errors at a rate somewhere around 1%. Some are harmless. Some are a wrong price on an invoice, a wrong quantity on a dispatch, or a payment to the wrong account.

Estimate error frequency and average cost per error, including the time spent finding and fixing it. On tasks touching money or stock, this often exceeds the labour cost.

Step 3: estimate build cost realistically

Get an estimate for each automation and add 30%. Then add the ongoing cost: subscriptions, maintenance, and the fact that anything integrating with an external system will break when that system changes.

A rough guide: connecting two systems that both have decent APIs is small. A workflow with approvals and notifications is moderate. Anything involving unstructured documents, or a system with no API, is substantially more — and needs a maintenance budget attached.

How do you rank automation projects?

Payback in months = build cost ÷ (annual saving ÷ 12).

Sort ascending. Anything under six months is compelling. Six to eighteen months is worth doing if the process is stable. Beyond two years, only proceed if there is a strategic reason beyond cost — capacity for growth, compliance, or error elimination on something critical.

Then apply two filters that override the arithmetic:

Is the process stable? Automating a process you are about to redesign wastes the build. Fix the process first, then automate it.

Does it unlock growth? Some automations show mediocre payback on today's volume but remove the ceiling on tomorrow's. If a task is linear in order volume and you plan to triple orders, its future value is three times its current calculation.

What does the automation ranking usually show?

Three patterns show up almost every time.

The loudest complaint is mid-table. It is annoying but infrequent. Real cost sits in short, invisible, constant tasks.

Reporting automation is nearly always top three. It is cheap to build, saves days every month, and improves decisions because the numbers arrive while they are still actionable.

Approval chasing costs far more than anyone expects. Not the approval itself — the waiting, following up, and downstream work blocked while it sits. Measure the delay, not the click.

Measure after, not just before

Record the baseline before you build: task time, error rate, cycle time. Re-measure a month after go-live.

Two reasons. Automations sometimes shift work rather than remove it — exceptions now handled manually can consume much of the saving, and you only notice by measuring. And a documented, verified saving on project one is what makes the budget conversation for project two straightforward.

Frequently asked questions

automationROIoperations

Going through this right now?

I've worked through this with over a hundred business owners. Thirty minutes on a call is usually enough to point you the right way.

Book a free call
CallWhatsAppEnquire