When automation does not pay off

Automation often does not pay off when a process is rare and cheap to do manually, when it first needs changing, when nobody can supervise the result, or when the problem is its cause rather than its effect. You can make an initial calculation before pricing the build; a more accurate assessment should include errors, exceptions, risk, and maintenance cost.

This article is written by a company that sells automation. We write it deliberately, because a failed implementation costs us more than one order that was not placed.

A calculation on a sheet of paper

Three numbers and a decision:

1. Annual saving = number of executions per year × time saved in one execution × hourly cost of the person doing it.
2. Total first-year cost = build + maintenance × 12 + tool and model cost.
3. Divide the second by the first.

If the result is greater than one, you pay extra in the first year. That does not have to disqualify the investment — it may pay back in the second year — but you need to know it before, not after.

Example, assuming 250 working days: a process performed 5 times a day, saving 10 minutes per execution, at an hourly cost of 60 PLN. That is around 208 hours, or 12,500 PLN saved each year. Automation costing 6,000 PLN plus 500 PLN of monthly maintenance costs 12,000 PLN in the first year. The balance is almost on the edge of viability before you include the cost of tools, tests, and exception handling.

The same process performed once a week gives around 8.7 hours a year, or around 520 PLN at that rate. In that variant, automation will not repay itself through time savings, although costly errors or a compliance requirement may change the decision.

Eight situations in which it is better not to automate

1. The process is performed rarely

Something done once a month for half an hour amounts to 6 hours per year. With a low labour cost, time savings alone will probably not cover a bespoke build and maintenance.

The exception is when a mistake in that rare process is very costly. Then you automate to eliminate error rather than save time — and the calculation is different.

2. The process needs changing anyway

Automation fixes the process’s assumptions in place. If the flow is unnecessarily complicated, code may increase the cost of changing it later and hide the problem behind faster execution. After an audit, we sometimes recommend removing or merging steps first and only then reassessing automation.

3. The cause is the problem, not the effect

A classic example: customers ask the same question in large numbers, so a company wants automatic replies. First, check whether clear information on the website or in the process would reduce the number of questions more cheaply than building automated service.

Automating an effect instead of its cause gives you efficient handling of a problem that did not need to exist.

4. Half of cases are exceptions

Automation lives on repetition. If six out of ten cases need an individual decision, you will build a system that handles four and adds work to the other six — because someone must now also check that the system did not misclassify them.

There is no universal percentage threshold. Calculate the share of cases handled without correction, the time needed to check the rest, and the cost of a wrong routing. Sometimes narrow automation of a single step produces a better result than trying to cover an entire case.

5. Nobody can supervise the result

Automation is a production system. A file format can change, access can expire, and a provider can modify an interface. Without completeness checks, alerts, and an accountable person, an error can remain unnoticed until a user reports it.

We maintain our own monitored collectors designed for continuous operation. That practice also covers detecting interruptions, filling gaps, and responding to a changed source — not only building the first flow.

6. Nobody can describe the process

If a process exists only in one person’s head, an attempt to automate it will turn into reconstructing their knowledge by trial and error — at your expense. The first step is then documenting that knowledge: more of a second brain than automation.

7. Certainty, not saving, is required

Calculating a liability, making a transfer, or filing with an authority requires unambiguous rules, validation, and appropriate control. AI can help read a document or prepare a draft, but it should not approve a high-stakes outcome on its own without demonstrated quality and designed supervision.

8. The process will disappear before the investment pays back

A change of system, regulations, or business model can shorten an automation’s life. Compare the planned end date with a conservative payback period and include the cost of moving or closing the solution.

Three situations in which the calculation lies against you

To be fair in the other direction: automation can pay off more than the simple calculation suggests:

• When errors are costly. Time saved is one thing; eliminating a mistake that costs several thousand once a quarter is another.
• When the process is a bottleneck. If the pace of the whole company depends on it, the value of shortening it is greater than the cost of work hours.
• When work happens at peak time. Automation can reduce overtime or ad-hoc hiring. Calculate that benefit separately for the seasonal period.

What to do instead of automating

Four cheaper things worth checking first:

1. Remove a step. The best automation is the one you do not have to build.
2. Improve input data. Enforcing the right format at the input removes work throughout the rest of the journey.
3. Answer the question at its source. See point 3 above.
4. Change the order. Sometimes the whole loss is waiting, not work.

Price these four options next to automation so the decision is not limited in advance to one type of solution.

Frequently asked questions

How do we know how much time a process really takes?

Start with a short log: activity, time, and number of repetitions. Compare it with system logs and account for seasonality and corrections. We describe the method in an AI audit.

Will you tell us directly that it is not worth it?

Yes. An audit can recommend simplifying a process, improving data, or postponing an investment. The document should contain the calculation’s assumptions so they can be updated later.

Is it worth starting with something small even if the saving is modest?

Yes, if the objective is to check whether it works at all in your organisation. Then the first automation buys knowledge, not savings — which is why it makes sense for it to be inexpensive. That is the purpose of a first automated process.

---

If you want to know which processes in your company will pass this calculation and which will not, we can do it in an AI audit — with a list of things we do not recommend and the reasoning. Or simply describe the process and we will answer honestly.