How to Work Out the ROI of an Automation Before You Build It

What is the exact formula for automation ROI?

Automation ROI is the net monthly saving divided by the monthly cost to run the automation, shown as a percentage. Net saving equals hours saved multiplied by your hourly rate, minus the automation’s monthly cost. The formula is: ((hours saved × hourly rate) – monthly cost) ÷ monthly cost × 100.

In plain terms, you are asking one question: does the automation put more money back in your pocket each month than it takes out? The hours saved are the tasks you no longer do by hand. The hourly rate is what your time is worth, whether you bill clients at that rate or simply value an evening back at home. The monthly cost includes the tool subscription, any hosting, and the time someone spends keeping the automation running.

Work out the monthly net saving first. If a workflow saves you six hours a month and you value your time at EUR 50 an hour, that is EUR 300 saved. If the automation costs EUR 40 a month to run, your net saving is EUR 260. Divide that by EUR 40 and you get 650%. That number sounds enormous, which is exactly why percentage ROI can mislead at small scale.

A 650% return on a EUR 40 tool is only EUR 260 in real money. A 40% return on a EUR 600 service is EUR 240. The percentage flatters the cheap option, but the cash in your account is nearly identical. Before you build anything, work out the real cost of business automation and set a simple threshold: if the net saving is under EUR 100 a month, the automation may not be worth the mental overhead of owning it.

Which costs should I include beyond the software subscription?

Beyond the subscription or build fee, include the time you spend maintaining the workflow, fixing it when an app changes its API, and manually checking outputs. Also include the cost of any new tools the automation needs, like a dedicated inbox or a monitoring service. These ongoing costs often exceed the visible price.

Maintenance is the quiet line item. A workflow that syncs invoices between two apps may need an hour a month when a field name changes or a token expires. Exception handling is worse: a failed run at 11pm still needs a human to look at it in the morning. Then there is the review time, the ten minutes a week you spend opening a spreadsheet to confirm the automation did not quietly duplicate rows. And hidden subscriptions pile up: a monitoring tool to watch the automation, a dedicated email address to keep alerts out of your main inbox, perhaps a second connector account.

Before you commit, put these against the build cost. What one automation actually costs changes once you add the hours you will spend owning it.

These ranges are examples based on common small business workflows. Your actual costs will vary.

How do I estimate hours saved per week without overstating it?

Time one full week of doing the task by hand and note every minute, including switching between apps, correcting errors, and rechecking. Then multiply by four to get a monthly figure. If the task is not weekly, measure one full cycle and extrapolate. Never use a guess from memory; it is almost always too high.

1. Open a spreadsheet or a notebook and log every start and stop time for the task across five working days.
2. Record the minutes spent switching between apps, hunting for data, fixing typos, and rechecking the same row twice.
3. Add a line for interruptions: a two minute task that gets paused three times often costs ten minutes of real attention.
4. Check the same week last quarter and the same week last year, then adjust your weekly figure up or down for seasonal volume.
5. Multiply the adjusted weekly hours by four to get a monthly baseline, and keep the raw log so you can defend the number later.

For example, a bookkeeper who reconciles Stripe payouts into Xero every Friday might log 90 minutes the first week. But 25 of those minutes are tab switching and correcting two mismatched rows. In March, refunds are heavier, so the weekly figure rises to two hours. A fair estimate is 7 hours a month, not the 4 hours memory suggests. That gap is exactly where the payback sum goes wrong.

How do I value the owner’s or employee’s time in the calculation?

Use the fully burdened hourly rate you would pay someone else to do the task, not what you hope to earn. For an owner, that is often the cost of a virtual assistant or a junior employee, around EUR 15 to EUR 30 per hour. For an employee, use their gross wage plus about 30 percent for taxes and benefits.

For an employee, start with the gross hourly wage and add roughly 30 percent as a rough guide. A staff member on EUR 20 per hour gross costs about EUR 26 per hour once employer taxes, pension contributions and paid leave are included. That EUR 26 is the number to use, because that is what each hour of their time actually costs the business.

For an owner, use a proxy rate. Ask what you would pay a competent virtual assistant or junior hire to do the same admin. That is usually EUR 15 to EUR 30 per hour. Do not use your revenue per hour. If you bill clients at EUR 90 per hour, that rate reflects the value of work only you can do, not the cost of data entry you should not be doing. Using EUR 90 inflates the automation’s apparent return and pushes you toward automating the wrong things. The honest question is what the task costs if delegated, not what your time is worth when selling.

Here is a worked example. A five-person firm manually copies invoice details from Stripe into Xero. The owner does it, and it takes 6 hours a month. A virtual assistant would charge EUR 20 per hour, so the burdened cost of that task is 6 times EUR 20, which is EUR 120 per month. If an automation removes 5 of those 6 hours, the monthly saving is 5 times EUR 20, or EUR 100. That is the figure to compare against the real cost of business automation, not the owner’s imagined EUR 90 hourly rate.

What is a realistic payback period for a small business automation?

A realistic payback period is the number of months until cumulative savings equal the total cost to build and run the automation. For a small business, aim for six months or less. If payback takes over a year, the process may change before you break even, or the tool may need replacing.

The formula is simple. Take the one-off build cost, add the monthly running cost, and divide by the monthly saving. Payback in months equals build cost plus running costs so far, all divided by monthly saving. In practice, you solve for the month where the cumulative saving first covers the total spent.

Here is a worked example with invented but realistic figures. A bookkeeper spends 4 hours a week copying invoice data from one system to another. At a fully burdened cost of EUR 25 per hour, that is EUR 100 a week, or roughly EUR 433 a month. An automation removes the copying entirely. The build costs EUR 800 one-off, and the tools and hosting cost EUR 39 a month. Payback is EUR 800 divided by EUR 433, which is 1.8 months. After two months, the saving has covered the build and the running cost, and everything after that is time the bookkeeper spends on actual reconciliation.

Six months is a useful threshold because it forces you to be honest about how stable the process is. A workflow that changes every quarter will break before it pays for itself. A longer payback can still make sense when the automation removes a compliance risk or a task nobody wants to do, but you should treat that as a different decision. Before you commit, it is worth running the payback sum first with the three forgotten costs included: maintenance, the exception path, and the human who still checks it.

What goes wrong with automation ROI calculations?

Most calculations ignore the exception path: the 5 to 10 percent of cases that do not fit the happy path and need manual handling. They also ignore the time spent monitoring for failed runs and the gradual drift as apps update. These hidden costs can turn a positive ROI negative within three months.

The exception path. You automate invoice creation from a quote, but one client has a purchase order number, another pays in two currencies, and a third wants a different billing address. The automation stumbles on all three. Symptom: your team still opens the app every day to fix the same handful of records the automation was supposed to remove. Fix: list every exception before you build, and price the automation as if 10 percent of cases still need a human.

Failed run alerting. The automation runs, but nobody notices when a step fails until a customer asks why their order never arrived. Symptom: you check logs weekly, or worse, only after a complaint. Fix: budget for a daily or twice-daily review of failed runs, and treat that review time as a recurring cost, not a one-off.

API changes and maintenance. Your CRM updates its API, the automation breaks, and the fix takes half a day. Symptom: the automation works for six weeks, then quietly stops. Fix: assume one or two breakages a year per integration, and include the repair time in your ROI sum. This is the same maintenance cost covered in what one automation actually costs when you compare DIY, freelancer and agency options.

Overstated hours saved. You estimate the task took three hours a week, but that included interruptions, chasing missing data and fixing mistakes. The automation removes only the clean 40 minutes. Symptom: the ROI looks strong on paper, then the owner wonders why nobody has spare time. Fix: measure the actual task for two weeks before you automate, and only count the minutes the automation removes entirely.