When does RPA make no sense? The seven most common mistakes in process robotisation

RPA, or robotic process automation, is a program that clicks through applications just as a person would. It logs in to a system, copies data from one window and pastes it into another, downloads files and fills in forms. It requires no changes to the systems themselves, which is why it is sometimes the only way to automate old programs.

That same feature is its weakness. A robot relies on the screen always looking the same. Any change to a button, field or page layout can stop it. A good candidate for robotisation therefore meets all the conditions in the list below.

Take a hypothetical company where the accountant exports a list of documents from one system every day, corrects it in Excel and imports it into another. It looks like an ideal job for a robot. On closer analysis, however, it turns out that both systems hold the same data, just sorted differently, and the transfer served a report that nobody needs any more.

The second typical case is reports. Every morning, a robot compiles a summary from three systems, while the management board has been using a different results dashboard for six months. The robot works flawlessly; it is just that nobody reads what it produces.

So the first question is always the same: does this process need to exist? Often the best answer to manual work is to eliminate it, not to automate it.

A robot is an investment in stability. If the process or the systems change every few weeks, every change means fixes and downtime. After a few months, the team may spend more time repairing the robot than it previously spent on the manual work.

Purchase invoices are a good example. For years, robots retyped data from PDFs sent by email into the accounting system. Since 1 February 2026, every company has received invoices through KSeF, the government’s National e-Invoicing System, and since 1 April most companies have also issued them there. So invoices now arrive as structured data. Until the end of 2026, companies whose invoiced sales do not exceed PLN 10,000 a month including VAT may still issue invoices outside KSeF, but this is a transitional exception. A robot for retyping domestic invoices therefore no longer makes sense – what remains are foreign invoices, receipts and documents that are not invoices.

The same principles apply to the situations in the list below. In each of them, it is better to wait until things settle or choose a different solution.

A robot is good at carrying out a sequence of steps, but it does not make decisions that cannot be written down as a rule. A holiday request looks like a simple form. When approving it, however, a manager considers whether other people in the team are on leave, whether an important customer deadline is coming up and whether cover can be arranged.

In a process like this, a robot can do the routine part: check the remaining days, show calendar clashes and pass the request on. The decision stays with a person, and an ordinary approval workflow in Power Automate, monday.com or an HR system is enough to handle the request.

The same goes for complaints. Judging whether a customer is right requires reading their message and checking the history. Here, a combination of artificial intelligence that prepares a proposal and an employee who makes the decision works better – and a robot at most carries out what has already been decided.

A robot costs money not only to build but also for as long as it runs: licences, fixes and checking the results. For a process carried out once a month, the savings rarely cover these costs. Before you order a robot, calculate the annual saving with a simple formula.

The annual saving is the number of repetitions per year × the time for one run in hours × the cost of an hour’s work. Take a report prepared once a month, taking 2 hours, at a cost of PLN 100 an hour. That comes to 12 × 2 × PLN 100, or PLN 2,400 a year.

If the cost of building, licensing and maintaining the robot for a year is higher, robotisation does not pay. In that case, it is better to simplify the report itself or prepare an Excel template that cuts down the manual work.

Many modern systems have an API, an official interface through which programs exchange data without clicking through screens. For popular applications such as CRM systems, monday.com or Microsoft 365, Power Automate has ready-made connectors. A connection through such an interface does not depend on how the screen looks, so it usually breaks less often than a robot.

Take a company that wants new sales opportunities from its CRM to go into monday.com. A robot would have to log in to both systems every day and retype the data. A ready-made connector does the same thing directly, without depending on the login screen or page layouts.

Connecting systems also requires maintenance, because vendors change their interfaces over time. Even so, for systems that have them, it is usually the first choice. Robots remain the solution for old programs without interfaces, government portals and applications that their vendor no longer develops.

This is one of the most common reasons why robots that work stop working. The scenario is always similar. The contractor finishes the project, three robots are running, and nobody in the company feels responsible for them.

A few weeks later, a supplier changes the look of its portal and the robot stops overnight. Nobody notices, and the morning report looks normal – it just contains yesterday’s data. A week later, someone realises, but does not know whom to report the problem to. After a few such incidents, the robots are idle, the licences are still being paid for and the company is convinced that RPA does not work.

The person responsible does not need a dedicated full-time role. They do, however, need to be named, known to everyone and have time to react when a robot stops. They should also receive an automatic notification of every robot error.

For their first implementation, companies often choose a large process to show results quickly. For example, returns handling, which touches five systems and has dozens of variants. The project drags on, the budget runs out and the management board loses patience before the robot starts working.

The first project should be small, boring and easy to measure: one process, one or two systems, a few weeks of work. The team then learns how to live with a robot, and subsequent implementations go more smoothly.

A good readiness test: can the person who does the process today describe it step by step on one page, including the exceptions? If they cannot, it is not yet time for a robot.

The table below brings together the warning signs from the whole article. If the answer to any of the questions is uncertain, clarify it with the contractor before signing the contract.