Some systems will never get an API. A robot that drives the screen is the honest answer, and we build them the way you would build any production system: own identity, state checks between steps, monitoring, and a named owner.
Where RPA sits
Robotic process automation uses software robots to operate applications through their user interface, the way a person would. It is the bridge for legacy systems that expose no API, with the robot reading screens, keying data and moving files on a schedule or on demand.
The robots usually work. What fails is everything around them, and it fails in the same four ways almost every time.
It borrows someone's credentials because that was quickest. Now audit trails attribute the robot's actions to a person, the automation dies whenever they change their password, and it inherits every permission they happen to have. A robot needs its own named service account, scoped to exactly what the process requires.
The most damaging RPA failure is not a crash, it is a robot that carries on after an unexpected popup and keys a supplier code into a date field. Robots must verify they are on the expected screen before every action rather than assuming the click landed where they aimed.
RPA is sold as set-and-forget and is nothing of the kind. Interfaces change, and every change is a potential break. A programme with thirty robots and no maintenance owner will have a dozen quietly broken within eighteen months. We quote maintenance as a line item because pretending otherwise is dishonest.
Someone built a robot to drive a screen that sits on top of a documented endpoint, because getting API access needed a conversation with a vendor and the robot did not. Two years of fragility to avoid a two-week procurement. We check for an interface first, every time, under integration services.
Recording the clicks is a day's work. These are the parts that decide whether the robot is still running next year.
A robot that finds a field by its pixel position breaks the moment anyone changes a margin. Where the application exposes stable identifiers we anchor to those; where it does not, we anchor to nearby text or structural relationships that a cosmetic change will not disturb. It is not always possible, and when it is not we say so and price the fragility rather than hiding it.
Robots also run a self-check on start: is this the expected application, at the expected version, on the expected screen. A failed check halts cleanly instead of improvising.
Named service account, least privilege, credentials in a vault and injected at runtime, session recording for audit. Every action is attributable to the robot. Our security team reviews the account scope before go-live.
Items are queued with a status, so a failure retries one item rather than restarting a batch of four hundred. Exceptions land in a review queue with the screenshot attached.
A robot moves a PDF; it does not understand one. Pairing with document processing gives it structured fields with confidence scores to key in.
Success rate, items processed, exception rate and time since last successful run, on a dashboard with alerting to a named owner. A silent robot is not a working robot.
Answer for one specific process. The verdict updates live, and it will happily tell you not to use RPA.
Does the target system have a usable API you could get access to?
Is the process rule-based, with no real judgement calls?
Does the input arrive as scans, PDFs or images?
Does that interface get redesigned more than once a year?
Does it run often enough to be worth automating?
Can a wrong action be reversed easily?
Verdict
Not disqualified, but not obviously worth it either. Measure the actual handling time and exception rate first. Half the processes that look like RPA candidates turn out to be low volume or too varied once someone counts.
Flags to design around
Five steps, following the same delivery shape as the rest of the AI and automation practice.
We look for an API first, and we ask what it would take to get access to one. RPA is chosen when there genuinely is no programmable interface, or when obtaining it would cost more than the automation returns. Saying no here saves clients more money than anything else we do on these engagements.
Every screen, field and keystroke, plus what the operator does when something unexpected appears. The exception handling that lives only in an experienced operator's head is the part that breaks robots, and extracting it is most of the discovery work.
A named service account with least privilege, credentials in a vault and injected at runtime, sessions recorded. This is usually the step that needs an internal approval, so we raise it in week one rather than the week before go-live.
The robot verifies it is where it expects to be before every action. Work is queued per item so a failure retries one record rather than a batch, and anything unexpected halts with a screenshot rather than improvising.
Run dashboards, failure alerts to a named owner, and an agreed maintenance cadence written into the engagement. Then full handover: source, configuration and IP assigned to you on final approval.
We build on all three. The choice is driven by robot count, governance requirements and what your team can realistically operate.
The most complete platform for a real programme. Orchestrator gives you central scheduling, queues, credential management, versioning and audit across many robots, which is exactly what a thirty-robot estate needs and what homegrown tooling never quite delivers.
The cost is licensing, and it scales with robot count. It earns its place once governance across a fleet matters more than the per-robot bill.
Best for
Fleets of ten or more robots with audit requirements
Watch out for
Licence cost growing faster than the value per robot
The same process, run two ways. The difference is not where the robot lives, it is who is present when something unexpected happens.
Runs on the operator's machine · triggered by them · 09:14
Attended robots are faster to deploy and far more forgiving, because a person is standing there. They suit work that is bursty, exception-heavy, or where the operator's judgement is genuinely part of the process. The ceiling is that throughput is still bounded by that person's day.
Four honest failure modes and what we do about each. No vendor claims that RPA is maintenance-free.
Four cases where no API existed and none was coming. Profiles are anonymised.
A finance team logged into six banking portals every morning to download statements. None offered a feed on the account tier held. An unattended robot with its own credentials collects and files them before anyone arrives, and the reconciliation workflow picks up from there.
Banking and insuranceGovernment and compliance portals rarely expose interfaces and change on their own schedule. A robot keys prepared submissions and captures the acknowledgement receipt as evidence, with anything unexpected halting for a person rather than being retried blindly.
Logistics engagementsA manufacturer's ERP had an API for most modules and not for the one that mattered. Rather than a migration, a robot bridges that single module while the rest of the process runs through proper integrations. Deliberately temporary, and documented as such.
Manufacturing engagementsA healthcare provider's billing team checked claim status across several insurer portals by hand. An attended robot runs the checks in a batch and surfaces only the claims whose status changed, which is the small fraction worth a person's attention.
Healthcare engagementsRPA wins exactly one row, and it is the row that matters when there is no other way in.
| Criterion | API integration | RPA robot | AI agent driving a UI |
|---|---|---|---|
| Needs the system to cooperate | Yes, an endpoint must exist | No, only a screen | No, only a screen |
| Speed per item | Milliseconds | Seconds, bounded by the UI | Slower again, plus model latency |
| Determinism | Total | High until the interface changes | Variable by design |
| Maintenance burden | Low, versioned contracts | Real and ongoing, must be budgeted | Lower on layout change, higher on cost |
| Auditability | Request logs | Session recording and item queues | Run traces, harder to reason about |
| Ready for unattended volume today | Yes | Yes | Not yet, in our assessment |
Model-driven interface control is improving fast and we test it continuously. For anything running unattended at volume against a system of record, we still ship a deterministic robot — the same reasoning we apply when choosing between a workflow and an AI agent.
Robots are almost never the whole system. These are the neighbouring parts of the AI and automation practice.
The orchestrator that calls the robot as one step among many, and handles everything the robot should not.
Reading the invoice the robot then keys. Confidence scoring decides what a person still sees.
Measuring which process deserves a robot before anyone records a single click.
Robot identity, access review, session recording and the control mapping an auditor will ask for.
Where the data a robot collects becomes something worth forecasting from.
The operations-leader framing, for sizing a programme rather than designing one robot.
Robots need somewhere reliable to run, which our cloud team provisions, and programme-level sequencing is an advisory question our IT consulting team handles. To talk through one process, send us the details or start with the help centre.
The ten that come up in almost every first conversation about robotic process automation.
We will check whether one genuinely exists first, and if it does not, tell you what a robot would cost to build and to keep running. Reply in under 3 minutes.
