Robotic Process Automation: What It Does, Where It Fits and Where It Fails

TL;DR

• A software bot can work through the same screens you do, clicking, typing and copying under fixed rules. That is robotic process automation.
• You get the payoff on stable, high-volume work with structured inputs and few exceptions.
• You will see it break when screens change, documents vary, the process is undocumented or nobody owns the bot.
• Give every bot its own credentials, narrow access, an audit log and a named owner.
• Pilot one process and judge it against your own baseline, not a vendor’s.

Picture a finance clerk copying the same fields from one screen into another, hundreds of times a week. Robotic process automation (RPA) hands that job to a software bot. The bot opens the same applications, clicks the same buttons and types the same values, following rules someone wrote down in advance. Done well, it clears repetitive queues and leaves your people free for work that needs judgment. Done badly, it becomes a fragile script that stops each time a vendor moves a button.

Look behind most RPA disappointments and you find a poor fit, not poor software. The bot was pointed at a process with shifting screens, messy documents or constant exceptions. After go-live, nobody looked after it. If you run finance, HR or operations for a team in Malaysia or elsewhere in Southeast Asia, the useful questions are narrow. Which process? What kind of inputs? Who owns the bot? How will you know it worked?

What does robotic process automation do?

RPA software performs rule-based tasks by operating applications the way a person does, through the screen, with keyboard and mouse actions scripted in advance. Wikipedia’s summary describes it as scripts that mimic human interaction with application user interfaces. You do not need a special integration from the application. If a person can do the task by logging in and clicking through a fixed path, you can teach a bot that path.

Typical jobs include copying data between systems, reconciling two lists, refreshing a routine report, updating a record after a status change and sending a templated notification. Each one shares a trait: a written rule decides every step.

The bot has no opinion. It follows the script exactly, including when your script is wrong. Because it works through existing screens, you can add it on top of systems you already run. Because it depends on those screens, it inherits every change your vendors make to them.

How do attended and unattended bots work?

An attended bot runs on a person’s own desktop and starts when that person triggers it. An unattended bot runs on a server or virtual machine and picks up work from a queue or a schedule with nobody present.

Attended bots suit work where you want a human in the loop. A service agent clicks a button, and the bot fills five screens with customer data while the agent keeps talking to the customer. The person still owns the outcome, and the bot removes the retyping.

Unattended bots suit back-office batches such as overnight reconciliation, bulk record updates and scheduled reports. They need their own machine, their own credentials and someone who watches the queue each morning. Nobody sees a failure at 2 a.m. unless you have set up an alert.

Is RPA the same as AI or intelligent automation?

No. RPA follows a script, while AI reads, classifies or predicts from data. The plain version: RPA does what it is told, step by step. AI forms a view about something it was not told in advance.

Robotic process automation and artificial intelligence are different tools that often work together. RPA follows a predefined workflow: it clicks, copies and types through application screens exactly as scripted. It cannot cope with a case the script does not cover. AI is data-driven: it reads, classifies or predicts, for example pulling fields from a scanned form or judging what a customer email is asking for. Intelligent automation combines the two: AI handles the step that needs interpretation and RPA carries out the steps that follow. A useful test is to ask whether you can write the task as fixed rules. If you can, RPA fits. If it needs judgment on unstructured input, AI belongs in front of the bot. SummitNext’s multilingual call centre engagement shows the AI side: AI handled routine questions and escalated complex cases to people. This division holds for most current tools, though vendors label their products differently.

That engagement was an AI deployment, not RPA. The multilingual call centre case study records inbound inquiries down 30% through clearer self-service and staff retention up 65%. The pattern carries over: the machine takes routine volume, and people take the cases that need judgment.

On paper, list the steps that follow fixed rules and the steps that need interpretation. The first list is RPA territory. The second needs AI, a person or both, and SummitNext’s AI services page covers the AI side.

Free consultation. Not sure how your processes divide between bots, AI and people? Book a free consultation with SummitNext and bring one process to talk through.

Which processes fit RPA?

Processes with stable rules, structured inputs, high volume and a low exception rate fit RPA best. All four conditions matter. Miss one and you have a weaker candidate.

• Stable rules. Your decision logic changes rarely, and someone has written it down.
• Structured inputs. Your data arrives in fixed fields, spreadsheets or forms with a consistent layout.
• High volume. You have enough repetitions for the build effort to pay back. A task done twice a month seldom repays a bot.
• Low exception rate. Most of your cases follow the main path, and the bot passes the rare odd one to a person.

Finance, HR and customer operations produce plenty of candidates: matching payment records to invoices, updating employee records after an approved change, creating system accounts once a hire is confirmed. Before you commit, ask the people who do the work how often they hit a case that needs a phone call or a judgment. If the answer is “every few minutes”, your exception rate is too high for a first bot. For a longer list of candidate processes, see SummitNext’s article on which processes to automate before you scale.

Where does RPA fail?

RPA fails when the work is not stable or predictable: changing screens, unstructured documents, poorly documented processes, high exception rates and no owner for maintenance. Each has a different cause.

Changing screens. A bot locates fields on a screen. When a vendor updates the application, adds a field or redesigns a page, your script can stop or, worse, keep running against the wrong field. Wikipedia’s account of RPA criticism notes that these systems need continual technical support to handle system changes and cannot adapt to new conditions on their own.

Unstructured documents. A bot cannot read a free-form PDF, a photo of a receipt or a contract with a different layout every time. You need an extraction step in front of it. Once that step uses AI, you have intelligent automation, and the extraction now has its own error rate that somebody must watch.

Poorly documented processes. If three people do the same task three different ways, the bot encodes one of them and fails on the others. Automating a muddle produces a faster muddle. Writing the process down first is dull work, yet it often exposes steps you can delete without any software.

High exception rates. Every exception lands on one of your people. When exceptions dominate, your staff spend their day on the hardest cases and the bot’s saving shrinks to almost nothing.

No owner for maintenance. Bots fail quietly. Someone on your side has to watch the queue, repair the script after a system change and retire the bot when the process ends. An orphaned bot keeps running with an old password and old access, a security gap in waiting. For the wider picture of how automation reshapes outsourced operations, read SummitNext’s piece on how automation is redefining BPO operations.

What governance and security controls do bots need?

Treat every bot you deploy as a staff member with a system account: its own credentials, the narrowest access that does the job, a log of every action and a named owner who answers for it. A bot that touches personal data deserves the same care as a person who does.

A bot that touches personal data needs the same controls as a person who does. Give it its own named account, never a shared human login. Limit that account to the screens and records the task requires, store its credentials in a managed vault and log every action so an auditor can replay what it did. Assign one named owner who approves changes. The legal stakes in Malaysia have risen: the Personal Data Protection Amendment Act 2024 (Act A1727) brought processor obligations and cross-border transfer changes into force on 1 April 2025, with breach notification and data protection officer appointment following on 1 June 2025. Higher penalties now run up to RM1,000,000 and/or three years. If a provider runs a bot on your behalf, it is likely a processor, so the contract should say who holds the logs and who reports a breach. Check how these rules apply to your own data flows with legal counsel.

The phased dates come from a law firm summary of the Amendment Act. For how these duties play out in outsourced operations, see SummitNext’s article on data privacy and compliance in Malaysian BPO operations.

Keep credentials out of the script text, so a copy of your bot does not leak a password. Rotate them on a schedule and whenever the owner changes. Review access scope at fixed intervals, since a bot built for one task collects permissions as your people ask it to do more. Put script changes through the approval and testing you apply to any production change, and keep a fast way to switch the bot off.

How does RPA sit inside a BPO engagement?

Inside a BPO engagement, bots handle the rule-based steps and provider staff handle everything that needs judgment. Your process owner sets the rules both follow. The bot is one part of your delivery model, alongside people and a defined route for exceptions. A guide to how business process outsourcing works gives the wider frame, and a hybrid human and automation model for enterprise CX shows the same logic applied to customer support.

Put these questions to any provider before you sign: who builds the bots, who maintains them, where they run, who holds the credentials and what gets reported each month. Vague answers should worry you.

Accountability needs an explicit split. SummitNext structures its Employer of Record service the same way: it owns the HR responsibilities of payroll, compliance and benefits, and you keep operational management of the employee. A sensible split for your bots mirrors that. The provider can run the process and keep the bot healthy, and you keep authority over how the work is done and what counts as correct.

Location matters in some cases. SummitNext staff can work at your premises rather than only remotely. That helps where an application is reachable only inside your network, or where you want the people who handle bot exceptions seated beside the process owner.

How do you run an RPA pilot?

Pick one process, document it, run the bot alongside your people for a fixed period and judge the result against your own baseline. Keep your pilot small. The aim is evidence about fit, not coverage.

• Choose. Select a process that passes the four fit conditions and has a named owner on your side.
• Document. Write down every step and every exception type you can find, with the people who do the work.
• Baseline. Record volume, handling time, error rate and rework from your own recent data before the bot starts.
• Build narrow. Automate the main path only. Route everything else to a person on purpose.
• Run in parallel. Let the bot and your people work the same cases for the agreed period, then compare.
• Decide in advance. Write the rule for scale, fix or stop before the pilot begins, to stop the result being argued afterwards.

A provider with no minimum headcount makes small pilots practical. SummitNext has no minimum headcount requirement, so an engagement can begin with a single hire, for instance one person who works the exceptions while the pilot runs. That is a staffing model, not a promise about any tool.

How do you measure whether a bot worked?

Compare the same measures before and after on your own process data, and count the maintenance work the bot creates. Do not borrow percentage gains from vendor brochures: they describe somebody else’s process, not yours.

Useful measures:

• Handling time per case, including the time people spend on exceptions
• Error and rework rate on the automated path
• Exception rate, tracked weekly
• Turnaround time and the age of the oldest item in the queue
• Failed runs and bot downtime
• Hours spent repairing and updating the bot
• What your team did with the time it got back

The last two lines are the ones most reviews skip. A bot that saves you ten hours and costs eight in repairs has not helped. Set your review date in advance. For ideas on tracking outsourced performance with analytics, see how analytics track BPO performance.

Frequently asked questions

What is robotic process automation in simple terms?

RPA is software that does repetitive computer tasks for you by working through the same screens a person uses. It clicks, types and copies according to fixed rules written in advance. It suits predictable, high-volume work and has no judgment of its own, so exceptions go to a person.

Can RPA read PDFs and scanned invoices?

Not by itself. A bot follows fixed steps and cannot interpret a free-form document. You need an extraction step, often AI-based, to read the document first and hand structured fields to the bot. That extraction has its own error rate, so exceptions still need a person to review them.

How long does an RPA pilot take?

It depends on the process, and no honest universal figure exists. Scope sets the timeline: how many steps, how many exception types, how many systems and how quickly your team can document the work. Choose one process, agree a fixed run period before you start and review against your baseline.

Is RPA safe for processes that handle personal data?

It can be, with controls. Give each bot its own account, restrict access to what the task needs, keep credentials in a vault, log every action and name an owner. In Malaysia, the amended Personal Data Protection Act adds processor and breach notification duties, so confirm obligations with counsel.

Can a smaller company use RPA through an outsourcing partner?

Yes. A pilot can be small, and SummitNext has no minimum headcount requirement, so an engagement can start with a single hire. Volume still decides the value: a process with few repetitions rarely repays a bot, however small the engagement. Test fit on one process first.

How much does an RPA project cost?

Cost depends on the process, the number of systems involved, the tooling and the maintenance you plan for, so no responsible single figure can be quoted here. For costing against your own process, contact SummitNext with the process and its volumes.

Conclusion

RPA works for you when the task is stable, structured, frequent and rarely exceptional. It disappoints when your screens shift, your documents vary or nobody owns the bot. Treat each bot like a staff member with a narrow system account and a log. Start with one documented process. Judge the pilot on your own numbers, including the hours you spend maintaining it.

If you are weighing RPA, AI or a larger outsourcing arrangement for work in Malaysia and the wider region, speak with SummitNext’s team and bring the process you have in mind. A free consultation is the quickest way to test whether it fits.