Why scripts and RPA stall on portal work

Claim status is the clearest case. CAQH estimates that moving claim status transactions from manual to electronic saves about 17 minutes per medical claim and 14 minutes per dental claim, and puts the annual industry opportunity at roughly 3.7 billion dollars (CAQH CORE Claim Status Transaction Report, 2023).

Seventeen minutes is the number to hold onto. It is not a rounding error, and it recurs on every claim, which is why this work keeps attracting automation attempts.

A script encodes the page. It knows which button to press because someone looked at the page and wrote down which button to press.

That works until the portal changes, which portals do without notice and without a changelog. The script does not report that the page moved. It reports that it could not find something, or worse, it presses the thing now sitting in that position. The person who wrote it has usually moved teams.

Scripts also do not survive the second portal. Each new site is a new project, so the cost of coverage grows with every portal you add, and the team that owns the workflow cannot change it without the person who owns the code.

RPA is usually defined as software robots handling repetitive, rule-based tasks such as data entry across systems (UiPath). That definition is accurate, and it contains the limitation.

Rule-based means the rules have to be written. Web automation in this category generally requires explicit technical setup per site (UiPath), so onboarding a portal is a build, and changing a workflow is a change request.

The result is familiar to anyone who has run an RPA programme. It is genuinely effective on the two or three highest-volume workflows that justified the implementation cost, and it never reaches the long tail of smaller queues, which is where most of the hours actually sit.

Software can now operate a page the way a person does, by looking at it rather than by being told its structure in advance. OpenAI describes running these workflows in an isolated browser and treating page content as untrusted input (OpenAI computer-use guidance, 2024).

The honest framing from that same work is worth repeating: results are promising on focused web tasks, not magic across every site. Anyone claiming otherwise is selling something. But "focused web task" describes portal work almost exactly. Sign in, filter, open each item, read three fields, record them. That is the job.

The practical difference is who can set it up. If a task is described in plain language rather than built, the person who understands the workflow can change it without filing a ticket, and the long tail stops being uneconomic.

Ask what happens when the portal changes, because it will.

- A script fails, or acts on the wrong element, and says nothing useful. - An RPA flow fails and needs the team that built it. - The version worth having notices it cannot complete the step, stops, and tells you which portal and which step, so somebody can look.

That last behaviour is the whole thing. Automation that reports success it did not achieve is worse than automation that stops, because the cost surfaces weeks later as an unpaid claim and nobody can tell which run dropped it.

None of this makes scripts or RPA wrong.

A script is the right answer for a stable internal page that one team owns. RPA is the right answer for a high-volume, rule-based process across systems you control, where the implementation cost amortises.

Portal work is neither. The site belongs to someone else, it has no API and never will, it changes without telling you, and the volume is spread across a long tail of queues rather than concentrated in one. That combination is what defeats both approaches, and it is the specific case worth solving differently.

Three questions, in this order.

Who can change a task? If the answer is an engineer, the long tail stays manual regardless of the technology.

What happens on the hundredth item? Sessions expire, portals challenge unfamiliar activity, and multi-factor arrives at unpredictable points. Behaviour at item one tells you nothing.

What does a run produce? A per-item record, or a total. If it is a total, exceptions hide inside it, and you will find them later at a worse price.

Start with the queue that is largest and least interesting, run it against a week of real work, and read the exception list rather than the success count.