RPA in business – which processes to automate with robots first

Before you pick a specific process, it's worth going through four questions. The same four every experienced robotization team asks itself, though rarely out loud.

Question one: can the process be described step by step, so a new person could execute it from the instructions. If not – it's not an RPA candidate, because a robot can't handle it depends. If yes – you can move on.

Question two: how often is the process executed. Daily, several times a week, once a week, once a month. The more often – the better, because time accumulates faster. A process done once a month for 30 minutes is a weak candidate, no matter how annoying.

Question three: how many people in the company run the same or a very similar process. If five people in a department do the same thing every day – the value multiplies by five. Processes done by many people with the same script are the fastest-returning projects.

Question four: how many judgement calls does the process contain. None or very few – ideal. If the process stops every other step on let me think – a robot won't help. Where a human has to assess, decide, evaluate – the process isn't a fit for pure RPA.

From the experience of RPA deployments, a recurring shortlist emerges of processes that make good first projects. They aren't spectacular, but they deliver measurable results within weeks.

Entering supplier invoices. Every day, dozens to hundreds of invoices come in and someone enters them manually into the accounting system. The classic first project, because the process is repeatable, the rules are clear (number, date, tax ID, amount), and the value is measured in hours per day.

Daily reports. Every morning someone pulls data from three systems, combines it in Excel, formats it and sends it out. 60–90 minutes a day, every day. A robot does it in 5 minutes, every day, without fail. Value – several hours of work a week.

Checking statuses in portals. Shipping, logistics, government cases – everywhere someone has to click every day just to check whether something changed. The robot logs in, pulls the status, updates the system, and only flags actual changes.

Onboarding tickets and cases. A customer reports an issue via a form, someone opens it in three systems, attaches documents, generates a number, replies. The robot creates the case in 30 seconds, the human focuses on solving it, not opening it.

Data transfers between systems. Export from CRM, import into ERP. Export from the shop, import into the warehouse. Export from monday.com, import into accounting. Anywhere there's no integration, the robot stands in for one.

Some processes look like ideal candidates until you go in deeper. It's worth recognising them early – it saves the company months of frustration.

Processes built on emails written by humans. Looks attractive – emails come in every day, somebody handles them, why not bring in a robot. The catch is that people write emails 50 different ways. A robot won't understand the content. This is a job for AI + RPA, not RPA alone.

Processes with documents in many formats. Invoices in four layouts are RPA. Invoices in 30 layouts are already AI + OCR + RPA. Same kind of problem, two completely different deployment scales.

Processes that need a judgement call. Approving a holiday request depending on the team's situation. Replying to a customer's question depending on the relationship history. Classifying a document based on context. In all of these pure RPA falls over, because every decision means the robot stops and waits.

Processes scheduled to disappear in a reorganization. Sometimes a process exists only because nobody had time to simplify it. If in six months the systems will be integrated and the process disappears – there's no point deploying a robot just for that window. Better to suffer manually for six months.

The simplest calculation: how much time the process consumes over a year, what the rate of the person doing it is, what the robot will cost.

Example one. Process: 60 minutes a day, one person, 250 working days. Total 250 hours a year. Loaded hourly cost around 20 EUR. Value of time recovered: 5,000 EUR a year. Cost of deploying a robot for that process: 4,000–7,000 EUR one-off plus a small annual maintenance. Payback: 12–14 months. Starts to make sense, but isn't thrilling.

Example two. Process: 120 minutes a day, three people, 250 days. Total 1,500 hours a year. Time value: 30,000 EUR. Deployment cost: 6,000–10,000 EUR. Payback: 3–4 months. Now there's real value.

Example three. Process: 30 minutes a day, one person, 250 days. Total 125 hours a year. Value: 2,500 EUR. Deployment cost: 3,000–4,500 EUR. Payback: 14–18 months. Borderline – probably not a pilot.

Rule of thumb: the first project should pay back within 4–8 months. Shorter is unlikely for a first deployment, longer means the process isn't really pilot material. After the first success, later projects can have a longer payback period because the team knows what it's doing.

Often ignored during selection, but often decisive: how many and what kind of systems the robot works on. The more systems – the higher the chance one of them will update, change its UI, restart.

Processes on Microsoft 365 are usually the most stable in practice. Outlook, SharePoint, Teams, Excel change slowly and predictably. A robot on that stack can run for years without changes.

Processes on modern SaaS apps tend to be harder. SaaS vendors refresh the UI every few weeks, sometimes without warning. The robot breaks because the Save button suddenly has a different label. Better to look for an API there and integrate, leaving RPA for the rest.

Processes on old Windows systems are paradoxically often the most stable. An old ERP looks exactly the same as 10 years ago. Once the robot learns it, it runs forever without changes. That's why RPA shines where systems are old and there's no plan to replace them. More on that in RPA without APIs – how to automate legacy systems.

Practical conclusion: for the first project, pick a process running on stable systems. Ideally ones whose UI hasn't changed in months. After the first success and the team has learnt the ropes, you can take on harder, less stable processes.

Trap one: picking the most annoying process. The board has its favourite they'd like to eliminate. Often a good candidate psychologically, but a weak one technically. Usually too rare, too variable, or judgement-heavy.

Trap two: picking the most spectacular process. We want a robot that will do something never done before. But a pilot should be boring, small, measurable – not spectacular. Spectacular projects come second or third.

Trap three: picking a one-person process. Someone has run this for years and does it from memory. Robotizing such a process first requires extracting it from that person's head, which is often harder than the deployment itself.

Trap four: picking a process slated for change. Someone runs it every day, but in a year the ERP is being replaced and the process disappears. The pilot goes fine, the robot runs, and then the company eats the consequence – a deployment to throw away.

Trap five: no owner. The team deploys the robot, but nobody in the company feels responsible for keeping it alive. After a few months the robot stops, nobody knows why, nobody has time. Without an owner, RPA doesn't crash – it just fades.

Picking the first RPA process decides whether robotization takes hold in the company. A good pilot is a boring pilot – repeatable, measurable, on stable systems, without judgement calls.

Four questions help you choose: can the process be described, how often does it run, how many people do it, how many decisions it needs. If the answers look good, the next step is a simple value-of-time calculation.

The ideal first project pays back within 4–8 months. The best first-time candidates are invoice entry, daily reports, status checking, opening cases, and transferring data between systems with no integration.

Avoid processes that need understanding emails, documents in many formats, or judgement calls – that's the territory of RPA + AI together, not pure RPA. More in RPA vs AI – the differences companies keep getting wrong.