Every company has employees who take the same table from one system and enter it into another every month, key incoming invoice details into a screen one by one, or copy the same data from the same website every morning. What these tasks have in common is that they require no judgment: the steps are the same every time, and the rule is clear. Robotic process automation (RPA) is a technology built for exactly this kind of work.
This article explains what RPA is, how it works, which tasks it is used for and where it reaches its limits. At the end, there is also a short checklist you can use when choosing your first automation process.
What is RPA?
RPA is a software robot that carries out, through the screens of applications, the rule-based and repetitive tasks that an employee performs on a computer. The "robot" is not a physical machine but a program running on a computer. It clicks, types, copies, opens files and fills in forms; in other words, it imitates what a person does with a keyboard and mouse.
Microsoft's Power Automate documentation summarizes this approach well: desktop flows are designed for anyone who performs simple or complex rule-based tasks at a workstation, and they work with everyday tools such as email and Excel as well as with modern and legacy applications. According to the documentation, these tools can also automate older applications such as terminal emulators, and they interact with the machine through elements in the application interface, images or screen coordinates.
This last point is what sets RPA apart from other integration methods. If there is no ready-made connection (API) between two systems, RPA can fill the gap by using the screen the way a person would.
How does RPA work?
An RPA process is usually built in three steps:
- The steps are defined. Which screen the employee doing the job clicks on, and what they type into which field, is written out step by step.
- The robot is designed. These steps are turned into a flow in the RPA tool, using ready-made actions or a screen recording. Microsoft's documentation describes this as drag-and-drop actions, or recording the flow and then running it.
- The robot is run and monitored. The flow is triggered manually, at a set time or by an event; its results and errors are logged.
Attended and unattended robots
Two concepts come up often in RPA:
- Attended robot: Runs in the employee's own session while the employee is at their computer. The employee starts the robot themselves when needed.
- Unattended robot: For tasks that need no human supervision. According to Microsoft's description, the tool signs in to the machine on its own, runs the flow, signs out when the job is done and reports the result. The machine's screen is kept locked during this time. The documentation also states an important prerequisite: for unattended flows, the machine must have no open user session.
This distinction matters for planning. An unattended robot needs a separate machine, a license and a session setup. An attended robot, by contrast, starts out as part of the employee's daily work.
RPA examples: which tasks are a good fit?
The examples below are typical cases of tasks whose steps are fixed and whose rules are clear:
- Finance and accounting: entering supplier invoice details into the ERP, preparing bank transactions for matching against accounting records, compiling period-end reports from different systems. Microsoft's documentation gives two of these examples directly: extracting information from supplier invoices and entering data into an ERP system.
- Purchasing and procurement: collecting order statuses from supplier portals, transferring dispatch note details into the system.
- Human resources: carrying out, in sequence, the steps for opening or closing accounts across multiple systems when someone joins or leaves.
- Customer service: taking the details of a request from the customer system and transferring them to the relevant record screen.
- Reporting: pulling data from websites and writing it to an Excel file. This is also one of the examples in Microsoft's documentation.
The common criterion is this: the task is repeated often, its input is regular, its rule can be written down and its result can be checked.
How widespread is RPA?
The March 2026 report by Eurostat, the statistical office of the European Union, measures technologies that use AI-based software to automate workflows or support decisions (the report's example: RPA with AI-based software) as a separate item. In 2025, 5.4% of EU enterprises with 10 or more employees used these technologies; the figure was 4.2% in 2024. Among large enterprises, the share is 24.4%.
This figure covers only AI-supported automation; it should not be read as the overall prevalence of classic rule-based robots. For the details of the figures and the sector breakdown, see the article AI-Powered RPA: The European Data.
The limits of RPA
RPA's strength is that it can use the screen; its weak point lies in the same place. If something changes on the screen, the robot can get confused. Microsoft's documentation on unattended flows gives a concrete example: the screen resolution of the remote desktop session in which the robot runs may differ from the screen on which the flow was designed. According to the documentation, this can cause the target element not to be found, or keyboard and mouse actions to interact with the wrong element.
Three practical conclusions follow from this:
- Screens that change often are not good candidates for RPA. In a system whose interface is updated every month, the maintenance burden grows.
- If an API exists, consider the API first. Working through the screen is not a replacement for a direct connection; it is a bridge to use when there is no connection.
- Work that requires judgment is not a job for RPA. Interpreting a document, assessing an exception or writing a reply to a customer is the territory of other tools. This distinction is covered in detail in the article RPA or AI Agent?.
A checklist for choosing your first RPA process
The first process determines how automation will be received in the organization. When choosing, ask these questions:
- Frequency: Is this task done every day or every week?
- Rules: Can the steps be written down, and are exceptions rare?
- Input: Does the data always arrive in the same format (the same screen, the same file layout)?
- Stability: Will the screens of the applications involved change in the near future?
- Measurement: Is it known how much time is spent on this task today?
- Ownership: When the robot stops, who will notice and who will step in?
A small but frequently repeated process for which all six questions can be answered clearly makes a better starting point than a large, complex one.
RPA delivers the best results when it is framed not as a technology that puts people out of work, but as a tool that frees people from repetitive screen work. Starting with the right process also paves the way for the steps that follow.
Where logistics experience helps in choosing a first process. Logistics operations are full of the work described above: dispatch notes keyed from one screen into another, order statuses collected from supplier portals, stock figures reconciled between systems. They also run on the habits behind questions 2, 5 and 6 of the checklist: written working rules, a measured baseline and a named owner at every hand-off. One of our consultants brings more than 30 years in operations, logistics and supply chain: at a technology distribution company of roughly one billion dollars in scale, he ran logistics, warehousing, technical service and administrative operations end to end, building and leading teams of 100+ people and delivering lasting gains in operational performance through KPI-driven programs. He has also managed nationwide warehouse and transport operations. An industrial engineer, he now brings that supply-chain discipline to SMEs through AI and automation. Meet our consultants.
#interimmanagement #forwarddeployedengineering