How to develop RPA: seven steps, and when not to bother

The short version

• Check for an API before developing RPA, because an API call does not break when a screen is redesigned.
• RPA suits stable, frequent, rule-based work on structured digital input.
• List a process's exceptions before building a bot, because the exceptions take more design effort than the normal path.
• Every RPA bot needs a named owner, its own credentials and its own logs, because the applications it drives will change.
• Use an AI agent for steps that need judgement on varied input, and keep RPA or an API for the fixed steps.

How do you develop RPA?

You develop RPA in seven steps: check for an API, choose a process, define it, build the bot, test it on real cases, deploy it under its own account, and assign an owner. Robotic process automation is software that operates other software's interfaces the way a person would, following fixed rules.

The order matters more than the tool. A bot built before anyone has written down what happens when something goes wrong will work in the demo and stop on the first real exception.

What are the steps to develop an RPA bot?

1. Check for an API or built-in integration. If one exists, use it and stop here.
2. Choose a process that is stable, rule-based, frequent and digital.
3. Write the process definition, including every exception and who handles it.
4. Build in small, separately testable parts, with retries and clear stop conditions.
5. Test against real cases, including bad data and slow or unavailable systems.
6. Deploy with a dedicated account, least-privilege access, logs and alerts.
7. Assign an owner, monitor the bot, and budget for changes when the applications change.

Which processes are suitable for RPA?

A process suits RPA when it is rule-based, frequent, stable and works on structured digital input. If two competent people would make the same decision from the same screen, a bot can probably make it too. If they would argue about it, it is not a rules problem.

Test each candidate with four questions. Does it run often enough for the time saved to outweigh the upkeep? Will the screens and rules stay the same for the next year? Is the input typed or structured, rather than a scanned page or a free-text email? Can a wrong action be spotted and undone?

Start with something boring. Copying invoice fields from one system to another is a better first bot than anything involving approval judgement, because a failure is visible and the fix is cheap.

Fix a bad process before automating it. A bot runs a broken process faster, and it makes that process harder to change, because the steps now live in a script.

Should you use RPA or an API?

Use an API when one exists. An API is a published contract, so a redesigned screen does not affect it. RPA drives the interface, so a moved button, a renamed field or a new login step can stop the bot.

RPA earns its place where no API exists: a legacy desktop system, a supplier portal, or a product you cannot change. In those cases it is a sensible bridge. Treat it as a bridge, and revisit the decision when the system is replaced.

Which approach fits which task?

What should an RPA process definition include?

A process definition should list every step, system, input and exception, and say what should happen at each one. Without it, the developer guesses, and the guesses surface in production.

Watch the work rather than interviewing people about it. People describe the normal path and leave out what they do without thinking: the customer record with two addresses, the tab they keep open because the main screen cuts off a field, the colleague they ask when a total looks wrong.

Collect examples of the awkward cases. For each one, decide whether the bot should fix it, skip it and flag it, or stop. Then record the access each step needs, the volumes, the time limits and what a correct result looks like. That last item becomes your test plan.

How do you build an RPA bot that does not break?

You cannot build one that never breaks, but you can build one that fails safely and visibly. The aim is a bot that stops cleanly, says why, and can resume without doing anything twice.

Four habits do most of the work. Anchor to stable element identifiers rather than screen positions or image matches. Wait for a specific condition, such as a field appearing, rather than a fixed delay. Split the job into small reusable parts, keeping login, data reading and data entry apart. Pass work through a queue, so each case has a status and one failure does not end the run.

Make every action that changes something safe to repeat. If the bot crashes after submitting a payment but before recording that it did, a restart must check first rather than pay twice. Set a limit on retries, then send the case to a person with the reason attached. Never let a bot click through an error dialog it does not recognise.

How do you test an RPA bot before it goes live?

Test it against real cases in a non-production environment, then run it under supervision before it works alone. Testing only the normal path proves the demo, not the bot.

Use the exception list as the test plan. Feed the bot missing fields, odd formats, duplicates, a slow system, an expired password and an unexpected pop-up. Check the result in the target system, not just the bot's own success message.

Some applications have no faithful test environment. Where that is true, start with a person approving each case before it is submitted, and widen the bot's freedom as its record builds.

Who maintains an RPA bot after it goes live?

A named person or team must own each bot, because the applications it drives will change and nobody else will notice until work stops. Deployment is the start of the cost, not the end.

A vendor's own poll makes the same point. Pega's 2019 poll of 509 decision makers at businesses using RPA or RDA is headlined 'Most Businesses Find RPA Effective But Hard To Deploy and Maintain'. Read it with care: Pega sells RPA software, every respondent's company had at least $100 million in revenue, and the poll is several years old. The headline still fits the mechanism: a bot depends on screens its owner does not control.

Give each bot its own account rather than borrowing a staff login, so its actions appear separately in audit logs and its access can be limited. Keep credentials in a secrets vault. Log every case, and keep a written fallback so staff can do the work by hand when the bot is down.

Alert on volumes as well as errors. A bot that processes nothing and reports success looks healthy.

What does it cost to develop RPA?

The cost is the licence, plus the build, plus the upkeep. No single figure is fair, because the total depends on the process, the tool and how often the target systems change.

Licence prices are public but need checking. Microsoft lists a US price for its Power Automate Process plan, and says prices are shown for marketing purposes and the actual price appears at checkout. UiPath's pricing page shows a 'Starting at' price for its Basic plan. Treat either as an entry point, not a budget.

Engineering time is the variable to watch. The US Bureau of Labor Statistics gives a May 2025 median annual wage of $134,040 for the wider group of software developers, quality assurance analysts and testers. That is a US wage figure, not an RPA salary or a full employment cost. It still shows why a bot that needs frequent repair can cost more than the manual work it replaced.

Before approving a build, compare the hours saved each month with the hours of upkeep you expect. If the first number does not clearly beat the second, do not build it.

When should you use an AI agent instead of RPA?

Use an AI agent when the path through the work depends on reading or judgement, and RPA when the steps are fixed. RPA does exactly what it was told and stops when reality differs. An agent can interpret varied input and choose between steps, but it can also be confidently wrong.

The two combine well. A language model reads an unstructured email or document and returns structured fields, a validation step checks them, and RPA or an API enters the result. The fixed steps stay deterministic and testable, and the model works only where rules cannot.

Keep a person approving anything that moves money, changes important records or contacts a customer, at least until evaluation results justify removing them. Agents need that evaluation in a way bots do not. The same input can produce different output, so one passing run proves little.