RPA in your company – which processes to give a software robot first and how to check it pays off

RPA (robotic process automation) is a program that performs the same clicks and entries on a computer as an employee: it logs into a system, copies data, fills in a form. The robot does not think; it repeats recorded steps. So before you choose a process, test it with the questions below.

If the answer to any of the first three questions is “no”, the process is not a good first candidate. The last two questions do not rule a process out, but they tell you whether a robot is the right tool.

In mid-sized companies, a few types of work come up again and again that suit a robot well. They are not spectacular, but their effect is easy to measure. Take a hypothetical trading company with 90 employees, where three people in order processing retype online shop orders into an old warehouse program every day. That is a textbook example of a first robot.

Below are the types of process most often worth starting with. Each of them runs across several programs that do not exchange data by themselves.

Until recently, entering purchase invoices by hand was the most common first RPA project. Since 1 February 2026, every company has received invoices through KSeF, the government platform through which invoices between businesses pass. Since 1 April 2026, most companies have also issued invoices there. An invoice arrives as structured data: the tax ID (NIP), amounts and line items are in separate fields.

For domestic invoices, what you need is a connection between your accounting software and KSeF, rather than a robot clicking on a screen. A robot, or AI reading documents, is still useful for foreign invoices, receipts and documents that are not invoices. If someone in your company is still retyping domestic invoices by hand, first check what your accounting software can do.

Some processes seem ideal until you look at the details. It is worth spotting them before you order a robot, because fixing things afterwards costs more than the robot itself. These are the most common situations:

A robot works on what it sees on the screen. When a software vendor moves a button or renames a field, the robot may stop. So when choosing a process, check how often the programs the robot will work in change.

Paradoxically, the most stable are often old desktop programs whose appearance has not changed for years. The least stable are web applications that the vendor updates every few weeks, often without warning. For these, ask the vendor about an API or a ready-made integration first.

For the first robot, then, choose a process in programs that have not changed their appearance in recent months and are not due to be replaced. Leave the harder cases until the company has gained experience in maintaining robots.

The simplest calculation has three components: how many hours a year the process takes, what share of that work the robot will take over and what an hour of work costs. The table below shows three hypothetical processes, assuming 250 working days and a cost of PLN 80 an hour including overheads. We assume the robot takes over 70% of the work, with exceptions left to people.

Compare the value with the annual cost of the robot: the licence, the computer it runs on, the build cost spread over time and ongoing support. The licence for an unattended robot in Power Automate alone is USD 150 a month, or USD 1,800 a year. With process C, little is left for the rest, unless the same robot also handles other tasks. With process B, the calculation is clearly favourable.

Remember that time freed up becomes a saving only once you know what you will use it for. Write this down before you start, for example: “order processing will handle 30% more orders without a new hire”. Plug in your own data and you will get a figure against which to compare every offer.

Mistakes with the first robot are rarely technical. Most often they stem from how the company chooses the process and who is then responsible for it. These are the ones that come up most often:

The first robot is also a learning exercise for the company: how to describe processes, how to test and who responds to failures. That is why the plan should be short and have a clear checkpoint. The steps look similar regardless of the tool: