Somewhere in your office, right now, someone is copying numbers from one system and pasting them into another. They do it every day. They have done it for years. Robotic process automation, usually shortened to RPA, exists for exactly that person.
RPA is software that mimics a human operating a computer. It opens applications, clicks buttons, reads values from the screen, types into fields, and moves to the next record. No API required, no rebuild of your old systems. The robot uses the same interface your staff uses, just faster and without typos.
I have watched teams in finance and operations spend two to four hours a day on this kind of rekeying. That is not a people problem. It is a process problem, and RPA is one honest way to attack it.
RPA Is Not Zapier
This confusion comes up in almost every conversation, so let me separate the two.
Tools like Zapier or Make connect applications through their APIs. When your form tool has an API and your spreadsheet has an API, the integration is clean, reliable, and cheap. If your systems are modern SaaS products, start there. I wrote about that approach in API Integrations: Making Your Business Tools Talk.
RPA is for the other world, which in Indonesia is a very large world. The core banking screen from 2009. The distributor portal that only works in a specific browser. The desktop accounting app with no export button. The government reporting site your admin logs into every Monday. None of these have APIs you can call, but all of them have screens a robot can operate.
So the rule of thumb is simple:
- System has an API? Use API integration. Cheaper, more stable.
- System only has a screen? RPA is your remaining option, short of replacing the system.
What Actually Qualifies for a Robot
Not every annoying task is a good RPA candidate. The best targets share four traits:
- Rule-based. The steps can be written down completely. "If the invoice amount matches the PO, approve; otherwise flag" is fine. "Use your judgment" is not.
- High volume. Fifty records a day justifies a robot. Five a week usually does not.
- Stable inputs. Same file format, same screens, same fields, month after month.
- Digital end to end. If the process starts with a stack of paper, you need scanning and data capture first, which is a different project.
Concrete examples I have seen work in Indonesian companies:
- Pulling daily settlement reports from three bank portals and consolidating them into one spreadsheet before 8 AM.
- Rekeying approved purchase orders from an ERP into a legacy warehouse system, around 200 records daily.
- Copying new employee data from an HR system into payroll, BPJS, and the attendance tool.
- Downloading marketplace order exports and loading them into desktop accounting software every night.
Each of these was costing between half and one full-time headcount. That is the math that makes robotic process automation pay for itself.
The Honest Downside: Robots Are Fragile
Here is what most RPA vendors will not lead with. Because the robot operates the screen, the robot breaks when the screen changes. A portal redesign, a moved button, an unexpected popup, a slow network day, any of these can stop the robot cold.
This has three practical consequences:
- Robots need supervision. Someone must get an alert when a run fails and know how to rerun it. Unattended does not mean unmanaged.
- Robots need maintenance budget. Plan for a few hours of fixes per robot per quarter. A robot with no maintenance owner is a robot that silently stops working in month four.
- Robots are a bridge, not a destination. If you control both systems, a proper integration or system replacement is the better long-term answer. RPA buys you years of relief on systems you cannot change, and that is genuinely valuable, but call it what it is.
I have seen a company run a robot for two years on a bank portal that never changed, flawlessly. I have also seen a robot break three times in one quarter because a marketplace kept updating its seller dashboard. The difference was not the RPA tool. It was the stability of the target system.
What It Costs for an Indonesian SME
Rough 2022 numbers, so you can sanity-check any proposal on your desk:
| Item | Typical range |
|---|---|
| Licensed platform (UiPath, Automation Anywhere), per robot per year | Rp 60 to 150 million |
| Microsoft Power Automate per-user plans | Rp 200 to 600 thousand per user per month |
| Open-source or scripted approach (build cost, one process) | Rp 15 to 50 million one-time |
| Maintenance and monitoring | 10 to 20 percent of build cost per year |
For most SMEs automating one or two processes, the big platforms are overkill. A scripted robot built with open-source tooling, plus a simple failure alert to WhatsApp or email, covers the need at a fraction of the license fee. The platforms earn their price when you are running ten or more robots and need central scheduling, audit logs, and credential management.
Payback is easy to model. If a process consumes three hours of staff time daily, that is roughly 65 hours a month. Against an admin salary of Rp 5 to 6 million, the robot recovers Rp 2 to 3 million of capacity monthly, plus the error reduction, which is often worth more than the hours.
Where to Start
Do not start by buying a platform. Start by finding the process.
- Ask each back-office team: "What do you do every single day that feels like being a photocopier?"
- Pick the one task with the highest volume and the most stable screens.
- Document every step, every rule, every exception. If you cannot write the rules down, stop; it is not an RPA candidate.
- Pilot one robot on that single process. Measure hours saved and failure rate for one month.
- Only then decide whether to scale, and with which tooling.
This sequencing matters because RPA works best inside a broader plan, not as a gadget. If you are mapping that bigger picture, the thinking in A Digital Transformation Roadmap for SMEs That Works is the frame I use.
The Takeaway
Robotic process automation is not intelligent, not elegant, and not a strategy. It is a patient, tireless clerk for the copy-paste work your systems force on your people. Used on stable, high-volume, rule-based tasks, it returns real hours and removes real errors. Used on messy, judgment-heavy, ever-changing tasks, it becomes a maintenance headache with a license fee.
Find the most boring job in your office. If you can write its rules on one page and it happens fifty times a day, you have found your first robot. If you want a second pair of eyes on whether a process qualifies, or on a vendor quote that looks suspiciously round, that is a conversation I am happy to have.