Let's say we already have a process that looks like a sensible automation candidate. There's enough repetitive work in it, we understand the problem, and we know a system could technically take over part of the load.

At this point it's very tempting to jump straight to simple math: the process takes people 200 hours a month, automation can absorb 70% of the work, so just price out 140 hours and compare that with the cost of the project.

I often start with an estimate like that myself. It's quick, and it gives you a sense of scale.

The trouble starts when we treat the recovered time as money that will actually leave the company's cost base. In practice, those are very often two different things.

So before I get to ROI, I prefer to ask a different question:

What will actually change in the economics of this process if we automate it?

A good candidate isn't automatically a good investment

The distinction sounds obvious, but in automation conversations it blurs all the time.

A process can be a great candidate operationally: manual, repetitive, time-consuming and technically automatable. That still tells us nothing about whether it's worth spending money on.

In one case we analyzed, we could technically have automated a large share of a document-analysis process. But once we ran the numbers on volume, the work that would remain with people, and the consequences of errors, we recommended against full automation. The system could be built. The business case didn't hold up.

And it's that second step that interests me here.

A good business case shouldn't just show that the system will do the work. It should show that after the rollout the company will genuinely be better off (financially, operationally, or both), and that the improvement is large enough relative to the cost and the risk.

200 recovered hours can be worth a lot. Or almost nothing

The most common shortcut looks like this:

hours recovered × hourly labor cost = savings.

Sometimes that math is entirely justified. If automation cuts outsourcing, overtime, or some other real expense, the benefit genuinely hits the bottom line.

Sometimes the value sits in the future. The company is growing, and without automation it would have to hire another person within months. The project doesn't reduce today's costs, but it heads off an expense that was very likely coming.

And then there's the situation I run into most often: people get time back, but the cost of the team doesn't change. That benefit can still be very real, if it lets the company handle more volume, close cases faster, or move people to higher-value work.

Except you still have to be able to actually use that freed-up capacity.

Imagine automation saves 20 minutes a day for thirty people. Over a month, that adds up to roughly 200 hours. In a spreadsheet, it looks like more than a full FTE.

In reality, you can't lay off 1.25 people. If those 20 minutes are scattered across the whole organization and don't translate into higher throughput or specific work getting done, the financial value can be far lower than the sum of hours suggests.

Which is why, on projects like this, I ask two questions:

What exactly will we do with the recovered time?

and:

Can we turn that recovered time into a specific business result?

If the answer is "we'll handle 20% more cases without growing the team", you have a concrete value mechanism. If the answer is "everyone will have a bit less on their plate", I'd be careful about booking the full value of those hours as savings.

One more thing: never count the same benefit twice. If the recovered time lets you avoid a new hire, that avoided cost is already the business result. I wouldn't add the value of those same hours on top of it.

The value of a project isn't just lower costs

With automation it's easy to focus purely on reducing work. In practice, the value can come from several places.

A real cost can disappear. A future cost can be avoided. Throughput can go up, generating additional margin. And the cost of errors, rework and delays can change.

I'd be especially careful with the third case. If automation lets you handle an extra PLN 1 million in sales, I wouldn't put PLN 1 million of benefit into the business case. What interests me is the additional margin that actually stays in the company thanks to the extra throughput.

It's a small difference in wording, and a very large one in the spreadsheet.

Don't compare today's process with an idealized tomorrow

The second common problem shows up when we compare the cost of the process today with the cost of the process "after automation".

I prefer to look at two possible futures over the same period.

The first is the future without the project. What happens to volume? Will the team have to grow? Will outsourcing increase? What will errors, rework and delays cost if the process stays as it is?

The second is the future after the rollout. Here you have to count not just what the system takes over, but also what stays with people: verification, exceptions, corrections, and the harder cases.

And then there's the technology itself.

Here I apply a simple rule: compare the full cost of the process in both scenarios, not the price of an IT project against the cost of people's work.

In practice, that means including the cost of getting to the solution and running it afterwards: implementation, integrations, your own team's time, the technology, and the work that still remains after automation. I wouldn't build a full multi-year TCO model at this stage, but leaving these items out can seriously flatter the result.

I look at errors the same way. The current process can produce mistakes too, so I'm not interested in "the cost of AI errors" on its own, only in how the cost of errors and rework changes between the no-project scenario and the post-rollout one.

Five line items that are enough for a first decision

At the start, you don't need a financial model with twenty tabs. Five questions usually suffice:

1. Without the project: what will the process look like in 12–24 months?
2. After the rollout: what genuinely disappears, and what stays with people and the system?
3. The difference: which cost goes away, which one do we avoid, what additional margin can we generate, and how does the cost of errors change?
4. The investment: what does it really cost to get there?
5. The decision threshold: how good does the result have to be for the company to consider the project worth it?

That last item matters more than it might seem. A positive result is not yet a good investment. The project has to be weighed against the risk, the payback period the company expects, and other uses for the same capital.

A simple example: PLN 60k of annual benefit. So what?

Say a company processes about 4,000 documents a month today and expects 6,000 within a year. The current team is already close to its limit.

Without automation, the company assumes that kind of growth will require one more person, at a fully loaded annual cost of about PLN 150k. It also assumes errors and rework will cost about PLN 30k a year at that volume.

With automation, the extra hire isn't needed, but other costs appear: about PLN 60k a year to run the solution, PLN 40k for external verification of the harder cases, while the cost of errors and rework drops to about PLN 20k.

The annual benefit, coming from the difference between the scenarios, is therefore about PLN 60k.

If the implementation costs PLN 120k, the simple payback period is about two years.

That's payback, not ROI.

Under the same simplification, the three-year ROI would be about 50%: over three years the project would generate PLN 180k of benefit, and after subtracting the PLN 120k initial investment, PLN 60k would remain, half the amount invested. For a larger, multi-year investment, back-of-the-envelope math like this obviously doesn't replace a proper financial analysis.

But the more important question is: is two years a good result for this company?

There's no universal answer.

If the company expects this type of project to pay back within 18 months at most, this one, as it stands, doesn't make the cut. At a PLN 120k investment, it would need about PLN 80k of annual benefit, not 60.

And this is where the business case starts helping you make the decision instead of merely justifying it.

We can ask: what would have to change to get from 60 to 80? A lower cost of exceptions? Higher volume? A larger share of cases handled without a human? Additional margin from the extra throughput?

If the biggest unknown is, say, the share of cases the system can handle on its own, you can invert the math and calculate the minimum required automation rate. Then run a pilot and check whether real data comes in above that bar.

To me, that's far more useful than declaring "we assume 80% automation".

A good decision doesn't always end in a rollout

After running the numbers, I usually see one of three situations.

The project holds up even under conservative assumptions and clears the required return threshold. Then it's worth moving forward.

The result hinges on one or two things we don't know yet. Then we don't need a full rollout, just a test designed specifically to measure those unknowns.

Or the project only looks good under very optimistic assumptions. Then it's better to shrink the scope, or not do it for now.

In conversations with companies, that is sometimes the most valuable outcome of the analysis: not finding a way to implement AI, but quickly reaching the conclusion that in this particular spot the investment doesn't hold up.

A good business case isn't there to justify the project. It's there to help decide whether the company should actually spend the money.

And if the answer is "yes", only then is it worth moving to the next question: what's the simplest solution that will deliver this result, and do we really need AI for it.