RPA Implementation: From Process Choice to Bots That Keep Running

An RPA implementation comes down to six decisions: which process to automate, whether a screen-driving bot is the right tool for it, which platform and license to buy, how the automation handles the cases that break the rules, how you prove it works before the manual process is switched off, and who keeps it running when screens and inputs change. Building the bot itself is usually the smallest part of the job. Most of the effort goes into choosing the process and designing for exceptions.

The term has also widened. A lot of what gets called RPA in 2026 is a workflow tool calling APIs, with an LLM reading the documents a person used to read, and no screen-clicking robot anywhere. That is how we built the document automation we run for an oilfield services client, and it is the worked example below. If you are still deciding which processes across the business deserve automation at all, our post on business process automation covers that earlier step.

What RPA means in 2026

Classic robotic process automation is software that operates other software through its user interface. A bot logs in, clicks, types, copies values from one screen to another and reads what comes back, following fixed rules. The established platforms are UiPath, Automation Anywhere, SS&C Blue Prism and Microsoft Power Automate, whose bots are called desktop flows. They exist because plenty of business systems (older ERPs, terminal emulators, supplier and government portals) never got an API anyone could use.

Two developments have stretched the word. The RPA vendors now sell cloud workflows and API connectors next to their bots, so an "RPA project" can contain very little UI automation. And LLMs now read semi-structured documents, such as invoices, tickets and emails, well enough to handle work that used to need template-based OCR; our field-ticket workflow below is one example. They can drive screens too: Microsoft made computer use in Copilot Studio generally available in May 2026, so an agent can operate web and desktop apps on a user's behalf.

Treat the new labels with some suspicion. Gartner has warned about "agent washing", vendors rebranding RPA and chatbots as agents, and expects over 40% of agentic AI projects to be canceled by the end of 2027 because of rising costs, unclear business value or weak risk controls. A bot that does exactly the same thing every time is still the right answer for a lot of work, and it is far easier to audit.

Step 1: Pick a process that is worth automating

The first process sets expectations for everything after it, so choose it on evidence. Before anyone opens a bot designer, answer these for each candidate:

1. How many items arrive a month, and how long does each take by hand? At 60 items a day and 5 minutes each, that is 5 hours of someone's day. At 20 items a month, the bot's upkeep will cost more than the work it saves.
2. Can you write the rules down? If the person doing the job says "it depends" and can't say on what, the process has to be standardized before it can be automated.
3. How often do the screens and inputs change? A supplier portal that gets redesigned every quarter will keep a UI bot in permanent repair.
4. What does the input look like? Rows in a database or a CSV export are easy. Scanned PDFs and free-text emails need an extraction step, and that step needs its own checks.
5. What does a mistake cost? A late report and a duplicated payment are different risks and deserve different amounts of checking.
6. Who owns the process on the business side, and who will look at the items the automation can't handle?

If you can't write the process as a numbered list with its exceptions named, it isn't ready yet. When the systems involved keep event logs, process mining can show how the process actually runs, which is often different from how people describe it.

Step 2: Decide whether you need a bot at all

This choice does more to the long-term cost than any platform decision. There are five routes, and real projects usually combine two or three of them.

Our default order is API first, a workflow tool second, and a screen bot only for the system that leaves no other option. When you do have to work against pages or screens you don't control, keep that fragile part at one end of the pipeline. In the funeral-home migrations we run for FrontRunner, records are scraped from each funeral home's old website and pushed into FrontRunner through its API, so only the read side depends on someone else's page layout.

Step 3: Choose a platform and read the license model

These are the prices vendors listed on their own pages in October 2026:

Sources: Microsoft's Power Automate pricing page and UiPath's pricing page. Both change often, so check them before you budget.

The license is rarely the large number. One unattended Power Automate bot comes to $1,800 a year. The Windows machine it runs on, the build, and the hours spent repairing it after each screen change usually cost more.

How we would choose: a Microsoft 365 company with a handful of desktop tasks should start with Power Automate, because it fits the accounts and permissions they already manage. Systems with APIs plus documents to read suit a workflow tool with an LLM step. A central automation team facing dozens of legacy desktop applications is the customer UiPath and Automation Anywhere build for. We don't build on UiPath ourselves; that last point is based only on their published plans.

Step 4: Design for exceptions before the happy path

Every automated process meets items that don't fit. Sort them into three kinds and give each its own handling:

• Business exceptions: the data breaks a rule, such as an invoice above the approval limit or a missing PO number. Send the item to a person with the reason attached. Retrying won't help.
• System exceptions: a timeout, a portal that is down, a rate limit. Retry a limited number of times with a pause, then park the item and alert someone.
• Unexpected results: a screen element that isn't there, or an LLM response that doesn't parse. Stop that item, keep the evidence (the input, a screenshot or the raw model output) and alert.

A few rules save a lot of pain later. Every item should end in exactly one state: done, waiting for a person, or failed with a reason. Nothing should vanish quietly. Writes should be safe to repeat, so a retried run can't post the same invoice twice. Credentials belong in the platform's credential store or a vault, never in a config file or an exported workflow. And if the automation touches personal data, mask it in logs and screenshots.

What broke in our field-ticket automation

Our client provides snubbing, pumping, heating, hot-oil and nitrogen services in Canada, and every job produces a PDF field ticket. Turning those into invoice data meant someone reading each ticket for the customer, location, AFE/PO number, line items and operating, standby and transit hours. With an automation agency partner, we built an n8n workflow that runs every evening. It picks up the day's tickets, has an LLM extract the fields as JSON, files each PDF with its JSON in dated Google Drive folders, and emails the team a consolidated invoice report. It has run in production every day since September 2025 and handles about 100 documents a day.

When something broke, it was usually an LLM step. Our answer was to add alternative routes, so that a document still gets processed when the main extraction path fails. n8n has the building blocks for this: any node can retry on fail, and its On Error setting can send a failing item down a separate error output instead of stopping the run. A workflow can also name an error workflow, which starts from an Error Trigger node whenever an execution fails, so you hear about the failures nobody planned for.

The lesson we took from it: treat an LLM like any other unreliable dependency, the way you would treat a supplier portal that sometimes times out. Decide where a document goes when extraction fails before that happens in production, and make sure the route ends with a second attempt or a person, never with a log line nobody reads.

Step 5: Pilot on real data, in parallel

Run the automation next to the manual process before you switch anything off, and compare the outputs field by field. We tested extraction on real field tickets for a month before going live; the project took about two months from its July 2025 start to production in September.

Decide up front what you will measure and which result lets you switch over: the share of items that go through with no human touch, the exception rate, and how long the exception queue takes to clear. Sample inputs prepared for a demo hide the cases that matter. Use last month's real items, including the ugly ones.

Step 6: Budget for maintenance from day one

Something in every automation will change: a screen, an API version, a supplier's PDF layout, the model behind the LLM step. Monitoring has to catch silent failure as well as errors, because a run that processes zero items and reports success is the most expensive kind of bug. A daily summary email with item counts catches it for almost no effort.

Give each automation an owner and a response time. For the recurring data work we run for Method Procurement and FrontRunner, we commit to a 2-day SLA, and a bot your billing depends on deserves the same clarity. Our post on support SLAs goes through how to set one.

Expect the AI parts to change fastest. On an AI bookkeeping project for Jenesys AI, custom models we built were later overtaken by frontier models. For document extraction, that argues for starting with a general model and spending the effort on validation and fallback routes, which survive a model swap.

Frequently asked questions

How long does an RPA implementation take?

For a single well-chosen process, a few weeks to a couple of months. Our field-ticket automation took about two months, and half of that was testing on real documents. A program covering many processes takes longer, because infrastructure, governance and the maintenance queue grow with every bot.

How much does an RPA bot cost?

Licences start low: Power Automate's unattended Process plan is $150 per bot per month, and UiPath's Basic plan starts at $25 a month. Build time, the machine the bot runs on and ongoing repairs usually cost more than the license.

Should we use RPA or an API integration?

Use the API whenever the system has one. An API is a contract its vendor maintains, while a screen bot depends on a layout nobody promised to keep. RPA earns its place on the systems that offer no other way in.

Will AI agents replace RPA?

They take over the parts that rule-based bots handle badly: reading messy documents and coping with screens that vary. For stable, high-volume work, a fixed bot or an API call is faster, cheaper per run and easier to audit. For most document-heavy processes we would combine them: a workflow tool, API calls where they exist, an LLM for reading, and a person for the exceptions.

If you have a process in mind and want a second opinion on whether it needs a bot, an API integration or neither, our backend and integrations team is happy to look at it with you.