Turning portal work into a repeatable playbook

One painful workflow, not everything you do. Write the goal as a single sentence: "Check claim status for yesterday's submissions in each major payer portal and export the results to billing."

Then write down three things. What kicks it off: a time of day, a file arriving, a queue crossing a threshold. Which portals are involved, by name, so there is no ambiguity later. What you need at the end: for claim status, that is the claim number, payer, patient, date of service, status and any denial reason.

Keeping the goal narrow is what makes every later decision about branches and exceptions tractable.

Shadow one real run and write down every screen, click and field, in order. For a payer claim status check that is: open the portal, sign in, open Claims, open Claim status, set the date range to yesterday, filter to submitted or pending, search, export the CSV.

Capture two things people always leave out. The occasional screens, like "accept updated terms" or "confirm your contact email," which appear rarely enough to be forgotten and often enough to break a run. And any data you rekey from your own system into the portal, because that is where transcription errors enter.

Write it the way you would explain it to a new hire sitting beside you.

The output needs to be specific, not "check the portal." Name the columns. For claim status: claim ID, payer, patient, date of service, status, status date, denial code, denial description, amount billed, amount paid.

Writing the column list down once does two useful things. It tells any tool exactly what a finished run looks like, and it gives you something to compare against when you spot-check. A run that produced a file with the wrong columns has not succeeded, however cleanly it exited.

Most tools treat "the steps ran" as success even when the business outcome did not happen. Be stricter than that.

Success, for a claim status run, means the dashboard replaced the login page, the search returned rows for the date you asked for, the export file exists with a header and at least one data row, and the count is in the range you would expect from your own billing system. That last check is the one that catches a silent filter change.

Exception means login failed, the portal reported no claims for the period, the export produced no file, or the site was in maintenance. Each of those is a different thing and should be named differently, because "no claims found yesterday" might be perfectly normal on a Monday and alarming on a Thursday.

The rule to hold to: success means the business goal was met, an exception means it was not, and the run has to say which.

Portal work is full of "if this, then that," and the branches are where undocumented knowledge lives.

Start with the main path: log in, navigate to claims, search, export. Then add what actually happens:

• Login trouble. If the sign-in does not complete, raise an exception and stop rather than retrying, because repeated attempts are how accounts get locked.
• No results. Record "no claims found" as an exception with that specific reason and move to the next portal rather than treating it as a completed run.
• Interstitials. If a new terms page appears, accept it once, then continue.

Write each stage as its own block with its own branches. Login, navigation, search, export, validation. Once they are separate, you can reuse them for the next portal instead of starting over.

You are probably doing nearly the same work in three places. Keep one playbook for the overall task with portal-specific sections for the screens and quirks of each site.

The structure that holds up: a common inputs section (the date range, the expected claim IDs from your system), one section per portal for its particular steps, and a shared output section every portal has to satisfy. Same columns, same success checks, and a per-portal count of what was processed.

That shared shape is what makes the results usable downstream. Three portals producing three differently-shaped files means somebody reconciles them by hand, which is the work you were trying to remove.

You should not have to log into a portal to find out whether the automation worked.

Per run, capture the run identifier, start and finish times, which portals were visited, how many records were processed at each, whether it ended in success or exception, and the short reason if it was an exception. Keep the output files for audit, and screenshots where you need visual evidence.

The standard worth holding every tool to is the same one Rindler is built around: a run either completes and leaves proof, or it clearly reports that it did not and names what stopped it. A "completed" label with nothing behind it is not proof, and it is the thing that lets a broken run go unnoticed for a fortnight.

Once the playbook is written, it is what automation runs. Start small and widen deliberately.

Pilot one portal for a single day's volume. Spot-check the output rows against what your staff would have produced. Where the automation went a different way, that is usually a missing branch rather than a defect, so add it to the playbook. Once the first portal is boring, add the second, then raise the volume.

Then treat the playbook like any other standard operating procedure: revisit it when the portal changes its layout, and keep it current rather than letting it drift into folklore.

What should I document first?

The business goal, in one sentence, plus the portals involved and the data you need at the end. Everything else hangs off that.

How detailed should the steps be?

More detailed than feels necessary. If a person clicks a tab, picks from a dropdown or fills a field, write it down. The test is whether a new hire could follow it without guessing.

How do I know the automation really did the work?

Require outputs, not status labels. The file with the right columns and a plausible row count, plus a run record saying whether the goal was met or an exception was hit. Do not accept "completed" on its own.

What happens when the portal layout changes?

Update the playbook the way you would update an SOP: fix the navigation steps, confirm the success checks still make sense, and run a few cases before trusting it at volume again.

Can I start without an engineer?

Yes. Everything through defining the steps, success checks, branches and outputs is operations work, and the people who do the task daily are the ones who know the branches.