When portal work outgrows the team doing it

The obvious fix is to connect the systems directly. For this category of work, that option usually does not exist. The portal has no API and never will, because the party that runs it has no commercial reason to build one. That is true of a great many payer portals, state systems, supplier sites and legacy vendor consoles.

So the work stays manual, and the team absorbs it.

Software can now operate a website the way a person does. Anthropic describes this as "moving the cursor, clicking, and inputting information the way a person does" for tasks that run dozens or hundreds of steps (Anthropic, 2024). The browser itself becomes the surface the work happens on, which means a site with no data feed is no longer out of reach.

That matters most where volume is highest, because the cost of manual portal work scales linearly with the number of items in the queue and nothing about hiring changes that curve.

The useful version of this is not a project. An operator describes the task the way they would train a new hire: sign in here, filter to last week, open each item, record the status and the date, flag anything unpaid.

That description is the whole setup. The first pass on a new site is where the work is learned. After that, the same task runs on demand or on a schedule without being rebuilt.

The distinction worth holding onto is who does that work. If describing a task requires an engineer, the queue still moves at engineering speed, and the person who actually understands the workflow is stuck filing tickets to change it.

At low volume, signing in is a detail. At high volume it is the whole problem.

Portals expire sessions aggressively, challenge unfamiliar activity, and enforce multi-factor checks at unpredictable points. Anything that treats sign-in as a one-time step will work for a week and then fail quietly in the middle of a run.

What holds up under volume:

• sessions that persist across a job rather than being re-established per item
• multi-factor challenges handled as a normal, expected event
• credentials held under your own security rules, not pasted into a chat window
• a session that expires mid-run being reported as an exception, not skipped

Skyvern is one of several tools that support persistent sessions and chained workflows in the same live browser (Skyvern, 2024). The capability is becoming table stakes. How it behaves on the hundredth item of a run is what separates the options.

Automation that reports success it did not achieve is worse than automation that stops.

If a run says it checked 400 claims and it actually checked 380, the twenty it missed do not surface as an error. They surface weeks later as an unpaid claim, and by then nobody can tell which run dropped them. The team loses more time reconciling the automation than the automation saved.

So the requirement is not only that the work gets done. It is that you can prove it went through, item by item, and that anything which did not complete is named with the portal and the step it stopped on.

Both OpenAI and Anthropic advise keeping a person in the loop for high-impact actions and treating page content as untrusted input (OpenAI computer-use guidance, 2024). That advice scales down to ordinary back-office work: decide which tasks run unattended, which need review before submission, and require a run record for every job either way.

For the manager, the shift is from doing the work to reviewing it. That needs three things and not much else.

Decide what runs unattended. Reading and recording is low risk. Submitting a form, releasing a payment or changing a plan is not. Draw that line explicitly rather than discovering it.

Require a record per item. Not a summary. The queue is the unit of work, so the record has to be too, or exceptions hide inside a green total.

Watch the exceptions, not the successes. A healthy run is boring. The signal is the list of items that stopped, and whether that list is shrinking.

Two questions decide whether this is deployable in a regulated environment, and both are worth settling before the first run rather than after the hundredth.

Where do credentials live, and who can read them? They should be encrypted, held under your rules, and never visible in a transcript or a prompt.

What is written down, and for how long? Regulated work needs an audit trail that outlives the run, and teams handling health or financial data need to know which region processes it.

Neither question is exotic. Both get skipped when a pilot is small and become expensive when it is not.

Pick the queue that is largest and least interesting. Not the hardest workflow, and not the one with the most judgment in it. The best first candidate is high-volume, low-variance, and currently owned by someone whose time is worth more than the task.

Describe it once. Run it on a week of real work. Then read the exception list rather than the success count, because that list is the only honest measure of whether it is ready to carry the queue.