MAKIN 
Count the hours before you count the savings.
Inflated ROI figures usually start from an estimated baseline. Measure the actual time a task takes for two weeks first. The measured figure is often lower than people guess, and an honest smaller number survives scrutiny far better than a confident large one.
Include the cost of keeping it running.
Build cost is the visible part. Monitoring, the fix when an upstream format changes, and the person who understands the automation are the rest. An automation that saves six hours a month but needs two hours of care is a thinner win than it looks.
Unglamorous tasks tend to pay back first.
Invoice capture, delivery-status updates and report assembly make good first candidates: they repeat often, follow fixed rules and take inputs that rarely change shape. AI-heavy work can be more interesting and slower to pay back, because its output needs human review until the accept rate is trustworthy.
Freed time only counts if it moves.
Hours saved are not value until somebody does something else with them. If a team simply absorbs the slack, the return is hard to find later. Name in advance what the freed time is for — faster quotes, more follow-ups, an earlier month-end close — and check afterwards that it happened.
The calculation, in plain words
The return on an automation comes down to one comparison: what it costs to build and keep running, against the value of the time and errors it removes. Written as a payback period, which is easier to reason about than a ratio, it looks like this.
Payback in months = build cost ÷ (monthly value of hours saved − monthly running cost). Each term needs an honest number, and each has a usual way of going wrong:
- Hours saved: measured before and after, not estimated, and net of the time people now spend checking the output
- Value of an hour: the person’s monthly cost to the business, including salary, statutory contributions and a share of overheads, divided by the hours they actually work in a month
- Running cost: subscriptions, hosting or API fees, and the hours someone spends looking after the automation
- Build cost: the quoted price, plus the hours your own team spends explaining the process and testing the result
Measuring the baseline
Log the task for two ordinary weeks before anything is built. Count how many times it happens and roughly how long each takes, and include the rework: the invoice keyed twice because the first attempt had a typo, the status update sent again because the customer missed it. Leave out waiting time, such as an approval sitting in someone’s inbox. It matters for speed, but it is not effort an automation gives back.
The automation audit sets out the worksheet for this, column by column. Log the same way once the automation has settled, so that before and after are measured alike.
A worked example, with illustrative numbers
Suppose, purely as an illustration, a 20-person distributor whose accounts assistant types purchase invoices into Tally. The two-week log shows about 30 invoices a day at around 5 minutes each, or 150 minutes a day. Over 25 working days that is a little over 62 hours a month.
An automation reads each invoice and prepares the entry, and the assistant checks and approves it in about a minute, so the task now takes 30 minutes a day, or about 12 hours a month. Someone also spends around 3 hours a month on exceptions and on the occasional supplier who changes their invoice layout. The net saving is about 47 hours a month, not the 62 a quick estimate would claim.
Whether that pays back depends on two numbers only you know: what the build costs, and what an hour of the assistant’s time costs the business. Divide the build cost by the hourly cost to get the hours the automation must save to pay for itself, then divide that by 47 to get the months, after taking any monthly subscription off the value of the saved hours. None of these figures describes a real business; they show the method, and your own log replaces every one of them.
Test the example against worse assumptions
A payback figure is only as good as its weakest input, so run it again with less flattering numbers before committing. If the project still pays back within a period you are comfortable with in the worse case, it is a sound bet. If it only works in the best case, it is a hope. Try at least these:
- Volume halves in a slow month, or after a large customer leaves
- Each check takes two minutes instead of one, because people do not yet trust the output
- A supplier or a portal changes its format and the automation is down for a week
- The person who understood the process leaves, and someone new has to learn it
Value that is not hours
Some of the return never shows up as time. Fewer keying errors mean fewer wrong GST entries to correct and fewer awkward calls with suppliers. A lead answered in minutes instead of the next morning is more likely to become a conversation. A report that assembles itself arrives on Monday rather than Thursday, while it can still change a decision.
Write these down as outcomes you can check, such as the number of corrections in a month or how long a lead waits for a first reply, rather than converting them into a rupee figure nobody can verify. If the hours alone pay for the automation, treat the rest as a margin of safety. If they do not, these are the outcomes to measure before you decide.
Where to start
Start with one task that repeats daily, follows fixed rules and takes the same input each time. A Workflow Automation Sprint from ₹14,000 takes one such process and automates it in up to 7 days, with error alerts, a runbook and two weeks of tuning. Documents retyped into Tally or another system fit Document & Data-Entry Automation from ₹16,000, and customer updates and follow-ups on WhatsApp fit WhatsApp & Support Automation from ₹12,000. The full set is on the automation packages and prices page.