Automation pays off if the time it actually frees up is worth more than the ongoing costs, and the difference earns back the investment before the process or the systems change. Never calculate with the full time the work takes now: exceptions stay manual work, the automation needs a daily check, and maintenance and licences cost money. In the worked example below, of about 1,227 hours of manual work per year, some 985 hours are actually freed up. At a quarter of that volume, the same automation practically no longer pays for itself.
The worked example
All figures are assumptions for this example. Replace them with your own figures. How to collect them is explained further down.
Four kinds of time to keep apart
| Item | Calculation | Per day | Per year |
|---|---|---|---|
| Gross time: the manual work now | 80 × 4 minutes | 320 minutes | ≈ 1,227 hours |
| Exceptions stay manual work | 12 × 4 minutes | −48 minutes | ≈ −184 hours |
| Daily check | fixed | −15 minutes | ≈ −58 hours |
| Time actually freed up | 320 − 48 − 15 | 257 minutes | ≈ 985 hours |
The full 320 minutes never count as a saving. There are four reasons for this:
- Exceptions go to a person. An employee still reads and processes them. An exception can even take more time than a normal order, for example if you have to call the customer. The example uses the same 4 minutes; measure this in your own company.
- The automation needs a daily check. Someone checks every day whether all orders have arrived and looks at the alerts. That time comes off the gain.
- Maintenance and licences are costs, not time saved. They belong on the cost side of the sum, as an amount per year. Do not subtract them from the hours of the inside sales team, because then you count them twice or forget them.
- Time freed up is only money if it has a destination. For example, quotes or process planning that are now left waiting, growth without an extra employee, or less hired help and overtime. If the time disappears without anything else happening, it delivers nothing.
Calculating the payback period
With three formulas, you can calculate any recurring process. Each letter stands for one number from your own process. Below each formula is what the letters mean.
Step 1: hours actually freed up per year
H = (n × t × (1 − a) − c) × d / 60
In words: take the minutes of manual work per day, subtract the work on exceptions and the daily check, and convert the result to hours per year.
- H: the hours per year that are actually freed up. This is the result.
- n: the number of cases per working day, for example orders.
- t: the minutes per case when an employee does it by hand.
- a: the share of the cases with an exception that an employee has to assess, as a decimal: 15% is 0.15. The automation handles exceptions with a fixed rule itself; those do not count here. Then 1 − a is the share that the automation handles itself: 0.85.
- c: the minutes per day that the check of the automation takes.
- d: the number of working days per year.
- / 60: dividing by 60 turns minutes into hours.
For the example: (80 × 4 × 0.85 − 15) × 230 / 60 = 257 × 230 / 60 ≈ 985 hours.
Step 2: net benefit per year
W = H × K − D
In words: the hours freed up times what an hour of your employee costs, minus what the automation costs every year.
- W: the net benefit per year, in euros. This is the result.
- H: the hours freed up per year from step 1.
- K: what an hour of your employee costs: gross salary plus employer's costs, divided by the productive hours. Your payroll administration can give you this figure.
- D: the ongoing costs per year, in euros: licences, machine, maintenance and a budget for small changes.
Step 3: payback period
Payback period in months = 12 × E / W
In words: divide the one-off costs by the net benefit per year. That gives the number of years; times 12 gives the number of months.
- E: the one-off costs, in euros: analysis, build, test, go-live and the hours of your own people.
- W: the net benefit per year from step 2.
You can read how to build up E and D in what it costs to automate a business process. If W is zero or negative, the automation never pays for itself, however long you wait.
Calculating without an hourly rate
Do you first want to know whether a process comes close, without amounts? Then express the costs in hours of your employee:
- Eu: the one-off costs, divided by K. That is the number of hours of your employee that cost as much as the investment.
- Du: the ongoing costs per year, divided by K. That is the number of hours of your employee that cost as much as a year of licences, machine and maintenance.
The formula then becomes:
Payback period in months = 12 × Eu / (H − Du)
In words: subtract the ongoing costs from the hours freed up, and divide the investment by what remains. The worked example below does this. That way, it does not have to assume an hourly rate. If you want euros, multiply the hours by your own K.
Worked example: payback period for order processing
The example uses two assumptions about the costs. They are round numbers and not market averages. They do not follow from the budget in the costs article, because that budget counts hours of the developer, who has a different rate than your employee. For your own process, fill in the figures from your quote.
- Eu = 400 hours. Together, the one-off costs equal 400 hours of the inside sales employee.
- Du = 200 hours per year. Licences, machine and maintenance cost as much per year as 200 hours of that employee.
| Item | Calculation | Result |
|---|---|---|
| Actually freed up per year (H) | Step 1 | 985 hours |
| Ongoing costs per year (Du) | Assumption | −200 hours |
| Net benefit per year | 985 − 200 | 785 hours |
| One-off costs (Eu) | Assumption | 400 hours |
| Payback period | 12 × 400 / 785 | ≈ 6 months |
For comparison: anyone who calculates with the gross time and forgets the ongoing costs arrives at 12 × 400 / 1,227 ≈ 4 months. At this volume, that seems a small difference. At a lower volume, it becomes the difference between "pays off" and "does not pay off", as the next table shows.
Sensitivity: what if the volume is lower or there are more exceptions?
The same automation with the same costs (Eu = 400 hours, Du = 200 hours per year), but different numbers. The daily check stays at 15 minutes.
| Orders per day | Exceptions | Actually freed up per year | Net per year | Payback period |
|---|---|---|---|---|
| 80 | 15% | 985 hours | 785 hours | ≈ 6 months |
| 80 | 30% | 801 hours | 601 hours | ≈ 8 months |
| 80 | 50% | 556 hours | 356 hours | ≈ 13.5 months |
| 40 | 15% | 464 hours | 264 hours | ≈ 18 months |
| 40 | 30% | 372 hours | 172 hours | ≈ 28 months |
| 20 | 15% | 203 hours | 3 hours | Practically never (well over 100 years) |
What the table shows:
- Volume weighs most. At half the volume, earning back the investment takes three times as long. This is because the ongoing costs and the daily check stay the same, while the time freed up more than halves.
- There is a lower limit. In this example, it lies around 20 orders per day. There, the time freed up just covers the ongoing costs. Below it, the automation costs more every year than it delivers. You find the limit in three steps. Convert the ongoing costs to minutes per working day: 200 × 60 / 230 ≈ 52 minutes. Add the check: 67 minutes. Divide that by what one order delivers on average: 4 × 0.85 = 3.4 minutes, because 15% stays manual work. That gives about 20 orders per day.
- With many exceptions, the table is too optimistic. A process with many exceptions also needs more rules to build and maintain. Eu and Du then become higher than in the table. If you can reduce the exceptions, for example with a fixed order form, do that first.
Value that is not time
Some benefits are hard to measure in hours. They are real, but put them next to the calculation and not in it. Never use them to make a negative result positive after all.
- Fewer errors. An automation follows fixed rules and does not skip a step, as long as the rules and the data are correct. It does not prevent an error that is already in the source, such as a wrong item number from the customer. A built-in check can make such an error visible earlier, for example an order for an outdated drawing revision, before the production papers go to the shop floor. If you still want to count errors, count your own corrections, credit notes, complaints and rework of the last few months. Only count the errors that the automation really prevents.
- Less dependence on one person. The way of working is recorded in the automation and the documentation, not only in the head of one colleague. Against this is a new dependence: someone must be able to maintain the automation.
- Speed and peaks. Orders that come in during the morning can be in the ERP the same morning, also in a busy week. Then process planning and purchasing can also continue with them sooner.
- Auditability. A log shows per order what happened and when, for example with which revision and delivery date the order was entered.
- Room to grow. More orders do not immediately mean more people for entry work. Do watch the capacity. With Power Automate, one Process licence on a machine runs one desktop flow (a series of on-screen actions that the robot performs) at a time. With UiPath, the number of runtimes (licences to run automations) on a machine determines how many automations run there at the same time. Much more volume can therefore mean an extra licence.
Alternatives: not every saving needs a robot
| Approach | Strong in | Limitations |
|---|---|---|
| Simplify the process first, for example with a fixed order form | Low costs. Fewer exceptions, and every later automation becomes cheaper | Customers must cooperate. The manual work remains |
| Excel with Power Query (getting and transforming data in Excel) or a macro (a fixed series of Excel actions) | Low costs, quickly ready | An employee still starts and checks it. Depends on one file and its maker |
| Software robot (RPA) | Works with the existing screens, without help from the ERP supplier | Ongoing licence and machine. Maintenance after screen changes |
| Integration (API, a fixed entry point that lets software talk to other software) or electronic delivery by the customer | Little manual work per order, less sensitive to screen changes | Often higher build costs. Depends on the API of the ERP or of the customer |
| Change nothing | No investment | The manual work and the risk of errors come back every year |
You can read which technology fits your systems in RPA or API integration: which is the best choice?
When automation does not pay off
- The volume is too low. Below the limit from the sensitivity table, the time freed up does not pay for the ongoing costs.
- There are many exceptions that need judgement, and you cannot reduce them. Then most of the work stays manual, and the automation becomes more expensive.
- The process or the ERP changes soon. If you replace the ERP in eighteen months, the automation must pay for itself well within that time. Otherwise you pay again later.
- The work needs a judgement for every case, as with custom work that first goes through engineering. Then you save at most the lookup work, not the decision.
- There is a simpler solution. A standard import in the ERP, a customer who delivers electronically, or a step that is actually unnecessary.
- The time freed up has no destination. Then there is a cost item, but no return.
- Nobody becomes the owner. An automation without an owner can break at the first change.
You can read more signs in when it is better not to automate a process.
Decision framework
How to collect the figures
- Count the number of cases (n) over the last three months from the ERP or the mailbox.
- Measure the time per case (t) with a stopwatch over 20 cases, with two employees.
- Go through 50 real cases to estimate the share with exceptions (a). Also measure how long an exception takes.
- Ask your payroll administration for K.
- Take E and D from a quote in which the items are listed separately, with the assumptions included.
- Estimate how long the process and the systems will stay roughly the same.
Which payback period is good enough?
There is no fixed standard for this. Compare the payback period with the period in which the process and the systems are expected to stay the same. If it is close to that period or longer, the automation does not pay off. If your company uses a fixed rule for investments, apply it here too.
What weighs most
Volume, the share with exceptions and the destination of the time freed up. The technology only comes after that. A well-built automation on a process with too little volume stays loss-making.
When outside help makes sense
If you cannot estimate the exceptions well, if the costs E and D are still unknown, or if you are in doubt between a robot and an integration. A short analysis of real cases then gives better figures than an estimate around the table. You get a first impression of whether a process is suitable with the four questions on the services page: four short questions, without a tool or a calculation.
What to take away
The return depends less on the technology than on three figures from your own process: the volume, the share with exceptions and what happens with the time freed up. Calculate with the time actually freed up, put maintenance and licences on the cost side, and check how far your volume is above the lower limit. If it is only just above it, first improve the process or choose a simpler solution.