Robotic process automation for systems with no API

What this actually solves

There is a system at the centre of your operation that you cannot replace. It has been running for fifteen or twenty years, the whole business is built on it, it holds the history, and replacing it is a multi-year programme with a budget nobody wants to defend. It also has no API. There is no supported way for another piece of software to talk to it, so everything that goes in or out goes through a person at a keyboard.

That produces a very particular kind of cost. It is not creative work and it is not judgement — it is a large number of people spending a large share of their day keying the same fields into the same screens, reading from one system and typing into another. In claims processing, in back-office finance, in patient administration and in large service operations, that transcription layer is often the single largest line in the operating cost, and it is entirely mechanical.

RPA routes around the problem instead of solving it. A software robot operates the application exactly the way a person does: it identifies the field, enters the value, clicks the button, reads the confirmation. The legacy system is untouched and unaware. Nothing is migrated, nothing is re-platformed, no vendor has to cooperate. That is why the numbers work even at enterprise licensing costs — the alternative is a replacement programme measured in years.

The honest counterweight: the same property that makes it work is what makes it brittle. A bot has no understanding of what it is looking at. A small change to the interface that a human would adapt to without noticing can stop the bot entirely, and the real engineering in this discipline is not making the bot work once, it is deciding what it does on the day the screen is different.

What we do, and in what order

1. Discover the process as it actually runs. Often with process mining, which observes what people genuinely do on screen rather than what the procedure document says they do. The gap between the two is usually where the exceptions live, and the exceptions are the project. One to three weeks.
2. Build the business case before building anything. Which steps, how long each takes, how many times a day, and what the realistic outcome is. This is the deliverable that gets the programme approved, and occasionally the deliverable that correctly stops it. Three to five days.
3. Build the bot. Element identification, recorded and then hardened steps, and the sequencing decisions that matter — anything irreversible, such as submitting a transaction or sending anything outward, goes last, so a mid-run failure leaves the world in a recoverable state rather than half-changed. Two to six weeks.
4. Engineer the exception handling. The real work. What happens when the screen is different, when a field is empty that should not be, when the application is slow, when a record does not match, when the session drops. Every one of those needs a defined outcome — recover, skip and log to a queue for human review, or stop and escalate. Never continue and guess. One to three weeks.
5. Test against real production mess, then deploy to the orchestrator. Bots run under central control where they can be scheduled, monitored, queued and stopped. A single bot on someone's desktop is a prototype, not an operation. One to two weeks.
6. Close out compliance and audit. Named service accounts with scoped permissions, a per-bot record of what it does and what it may touch, logging that satisfies whoever reviews it, and a documented change process for the day the legacy system is updated. One week, extending with the regulatory burden.

Typical platforms: UiPath, Automation Anywhere, Blue Prism and Microsoft Power Automate Desktop. Where the target is a web application rather than a desktop one, Playwright or Puppeteer often do the same job with less fragility and no enterprise licence.

What moves the price

How many processes and how many systems. One process crossing two systems is a contained piece of work. Six processes crossing five systems is not six times the cost, it is more, because the interactions between them create their own failure modes and their own scheduling problems.

The compliance burden. In banking, insurance and healthcare, the bot itself may be a minority of the effort. Access approvals, audit evidence, segregation of duties, change control and sign-off cycles all consume calendar time that has nothing to do with engineering, and they are the reason the timeline runs to months rather than weeks.

How stable the target application is. A system that has not changed in five years and has no roadmap is a good candidate. One that is patched quarterly by a vendor you have no relationship with means ongoing maintenance is a permanent line item rather than an occasional one, and that should be reflected in the arrangement from the start.

What usually goes wrong

Browser automation gets sold as RPA, or the reverse. These are genuinely different disciplines with a factor-of-ten difference in cost, and mislabelling ruins the project from day one. A web application driven by Playwright does not need an enterprise licence, an orchestrator or a four-month programme. A green-screen terminal application does. Scoping the wrong one means either paying enterprise prices for a scripting job, or committing to a budget that cannot cover what the work actually requires.

The bot is declared finished because it works on a clean screen. It runs perfectly through fifty test records and goes live. Then a record has a field the developer never saw populated, or the application throws a modal dialogue that was not there during testing, and the bot either freezes or — far worse — keeps typing into whatever now has focus. The decision that matters is not whether the bot handles the standard case. It is what it does in every case it does not recognise, and the only acceptable answers are recover cleanly or stop and escalate.

Credentials get shared to make the bot work quickly. The offer is always made in good faith and always for speed: use this person's login, it already has the right access. It creates an audit trail that says a named employee performed thousands of actions they did not perform, it means that person's password change breaks production without warning, and it makes revoking the bot's access impossible without revoking theirs. Where you ask us for a colleague's credentials so a bot can act as them without that colleague knowing, that is where we stop.