When RPA doesn't make sense – the most common mistakes in process robotization

The most common mistake is also the simplest: we pick a process that shouldn't exist in its current form and robotize it. The robot does it faster – but the problem is that the process shouldn't be running in the first place.

Classic example. Every day someone in finance exports an invoice list from system A, opens Excel, edits it by hand, saves it, imports into system B. Looks like a perfect RPA candidate – repeatable, regular, measurable. After analysis it turns out systems A and B handle exactly the same invoices, just in a different order. Nobody remembers why this is happening, but we've done it for five years. The better answer here isn't a robot, it's the question is this transfer needed at all.

Second example. Someone spends 30 minutes a day preparing a report for the board. Opens three systems, combines in Excel, formats. After deploying a robot, the report is ready in 5 minutes. Great. Six months later nobody reads it – the board has moved to a different dashboard. But the robot keeps generating the report every day, because nobody switched it off. Classic: we automated a process that quietly went out of use.

Lesson: before deploying a robot, ask whether the process needs to happen at all. Sometimes the best answer to a manual process is to remove it, not automate it.

A stable process changes once a year. An unstable one changes every few weeks. Robotizing such a process is an invitation to constant maintenance.

Classic example. A company deploys a robot to handle invoices. Everything works beautifully for two months. Then the main supplier changes the invoice layout. The robot breaks. Someone has to fix it – a few hours of work. Two months later another supplier changes their format. Robot breaks again. After six months the IT team spends more time patching the robot than they used to spend keying invoices in by hand.

Second example – processes waiting for change. The company plans to migrate from the old ERP to a new one in 12 months. Meanwhile it starts deploying a robot for a process that will disappear after the migration. 80 percent of the work goes to waste together with the migration.

Third example – SaaS apps with frequent UI updates. A robot built for a specific screen layout stops working after every major update. That isn't the robot's fault – it's a poor choice of process.

Lesson: if the process changes often, if systems keep updating their interfaces, or a migration is planned – RPA is a bad idea. Better to wait for things to stabilise or pick a different technology.

RPA is excellent when the process can be described as a clear sequence. The more places in the process where a judgement call is needed, the worse the fit for RPA.

A concrete example. A company wants to robotize holiday requests. At first glance: ideal – a form, a list of approvers, a calendar. But the details reveal that every request needs a judgement: is anyone else from the team off that week, does the customer have a key deadline that week, has the requester already taken a lot of time this quarter. These aren't rules – they're situational assessments. The robot will fail here.

A better solution: a workflow (Power Automate, monday.com, Jira) walks the request through approvers, but the decision is made by a person. The robot can handle the routine part – check the holiday balance, prepare the calendar conflict list, ping the next approver. But the decision itself stays with a human.

Second example. Classifying complaints. A customer writes: my product didn't arrive, please refund. Sounds simple. Until you discover the customer has already raised the same complaint five times, and twice the product did arrive – it was just hidden. RPA can't assess that. This is where AI belongs – to assess the content and history – plus RPA to execute the decision.

Lesson: if a process contains more than two human-judgement decisions, pure RPA isn't enough. That's where AI + RPA kicks in, covered in RPA vs AI – the differences companies keep getting wrong.

Without a named person responsible for the robots, robotization in a company fades within a year. By far the most common reason RPA projects stop working.

The scenario goes like this. The company deploys its first three robots. Everything works great. The external consultant wraps up the project, hands over the invoice, says thank you. There's nobody inside the company who feels responsible for keeping the robots alive. Everyone has their day job; the robot is an extra.

Three months later the first robot stops. The reason: the main supplier rearranged their portal. Nobody notices straight away – the robot ran overnight, the report went out in the morning, the data is probably current. A week later someone in the department spots that the data is stale. They try to find the robot's owner. There isn't one. The external consultant comes back, fixes it for a few hundred euros. Six weeks later the same thing happens.

After a year, three robots are dead, the company is paying licences, nobody uses any of it. Everyone is disillusioned with RPA: we tried, it doesn't work. But it wasn't RPA that failed – it was the approach to maintenance.

Lesson: a robot owner is as important as the robot. It doesn't have to be a separate role – it can be a responsibility in an existing team. But it has to be named, known to everyone, and have priority when something breaks.

RPA was born for a world where systems didn't have a normal way to talk to each other. Where systems do have an API, integration is the more natural choice, not a robot clicking around in a browser.

The most common case. The company wants sales data from Salesforce to show up automatically in monday.com. The consultant proposes an RPA robot that will log into both systems every day, pull data from one and type it into the other. It works. But: Salesforce has a fully mature API, monday.com too. API integration in Power Automate Cloud takes 1–2 days and runs for years without changes. The robot will need regular maintenance because both apps refresh their UI every few months.

Another case. The company wants order confirmation emails to land automatically in the CRM. The consultant suggests RPA. Yet both the CRM and the mail system have connectors in Power Automate Cloud. The connectors handle it in 2 hours.

Lesson: always check first whether the systems have APIs. If yes – integration is option one, RPA is the backup. RPA shines for systems without APIs: an old ERP, a government portal with no integration, an app whose vendor stopped developing it long ago. We cover this in RPA without APIs – how to automate legacy systems.

Many managers want the very first deployment to robotize a large, complex process. It comes from results pressure: if we're paying for a project, let it deliver a big effect right away. Unfortunately, that's not how RPA works.

Classic failure scenario. The company decides on its first deployment but aims straight at customer returns – a process that touches five systems, has 30 variants, and needs integration with accounting and warehouse. The consultant quotes 12 months of work. Eight months in, the robot still doesn't work, the budget is gone, the team is demoralised, the board's priorities shift. Project abandoned.

A better approach: first project – small, boring, measurable. Three months of work, one simple process. The robot runs, the team sees the effect, learns how to operate it. After the first success, the next projects go many times faster – the team already knows how to live with robots.

A second flavour of this mistake: jumping on a process nobody in the company really understands. The consultant doesn't know the details, the client doesn't know them either. The deployment becomes a series of surprises, each one costing extra weeks. Lesson: if you can't describe the process on one page, it isn't time for RPA yet.

Lesson: the first project is learning. What matters is simplicity, measurability, and a success in a sensible timeframe – not a spectacular effect.

RPA doesn't make sense where processes are bad, unstable, rare, judgement-heavy, or where systems have normal APIs. And it doesn't make sense where nobody in the company is willing to feel responsible for keeping the robots alive after deployment.

Six most common mistakes: robotizing a bad process, robotizing an unstable process, robotizing a judgement-heavy process, deploying without an owner, RPA where API fits, and too much ambition on day one.

These mistakes are predictable and avoidable. Just ask the zero-th question first: should this process exist at all. If yes – check stability, decisions, API availability. If all conditions are met and a robot owner is on board – you can move ahead.

If the early questions raise doubts – better to wait than to burn out. A practical take on picking the first processes is in RPA in business – which processes to automate.