Portal work as a managed service offering

A lot of the work that matters to your clients sits behind a login with no feed to subscribe to. In healthcare, the AMA found that 95 percent of physicians say prior authorization delays care, and 26 percent say it has caused a serious adverse event, largely through portal-heavy workflows. In finance, IFOL reports that 63 percent of teams spend more than ten hours a week on invoice processing and 66 percent still key invoices by hand, often into supplier portals.

The pattern is the same across regional MSPs: work stuck behind logins, forms and downloads. The goal is to turn those steps into named runs on a schedule, each leaving a record of what happened.

Start with one or two high-volume, low-ambiguity tasks in a single portal. The good candidates happen at least daily, follow the same steps every time, and hurt when they are missed.

They usually live in carrier or payer portals (claim status checks, EOB downloads), supplier portals (invoice and statement pulls), or client VMS and ATS portals (timecard approvals, candidate status moves). Concretely:

• Insurance account manager. Log into the carrier portal, pull loss runs for policies renewing in 60 days, save the PDFs to the shared drive, note it in the AMS.
• Medical biller. Check status on claims over 30 days old, download new EOBs, mark escalations.
• AP clerk. Log into each supplier portal weekly, download statements, reconcile open invoices.

Write each one down the way you would train a new hire. That plain-language description is what drives the run.

Clean up access first. It makes the work sturdier and it is the part clients ask about.

• Central vault. Portal usernames and passwords in one place, with role-based access and audit logging.
• Least privilege. Accounts with only the permissions the task needs, never full admin.
• Per-client accounts. No shared MSP login spanning clients. One account per client, per portal.
• Rotation. A fixed schedule, and a record of which runs need updating when a password changes.
• Multi-factor. Prefer app or token methods you can coordinate with the client, and document any remembered-device enrollment.
• Log retention. Keep run logs and screenshots for a fixed window to support audits, and limit access to the team serving that client.

Put these practices in the offering itself, so a client can see exactly how their access is handled.

A runbook has four parts, and the fourth is the one teams skip.

The trigger. One sentence. "Every weekday at 6 a.m. Eastern." "When a new invoice file lands in SFTP."

The path. Short actions in plain language: go to the portal, log in with the client's billing account, open Claims then Search, filter for claims older than 30 days, open each result, download the remittance PDF, capture status and last update date. Avoid describing the page structure. When the portal changes, that detail is exactly what breaks.

Inputs and outputs. Inputs are what the run needs to start: client, portal, credentials in the vault, date range. Outputs are what you promised to deliver: a spreadsheet of claim IDs and statuses, a folder of PDFs, a run log with start time, finish time and per-item outcomes.

Success and exception rules. Success is not the absence of an error message. Success is that login worked, the target page loaded, every item in scope was processed, and the output counts match. An exception is a failed login, a page that did not appear, a broken download, or an unexpected message. Write what happens next: capture a screenshot and the page, notify the assigned engineer within fifteen minutes, and notify the client contact if a deadline is at risk.

That last section is what makes portal work a service rather than a black box you hope worked.

Setting up a run should look like filling in a form, not writing code. For a weekly statement pull:

1. Name it. "Weekly supplier statements, Client A." 2. Describe the task. Go to the supplier portal login page, sign in with the stored credentials, open Statements, download the newest statement, save it to the Client A statements folder, and log what was downloaded. 3. Attach credentials from the vault. 4. Set the schedule. Every Monday at 8 a.m. 5. Define outputs. File path, download timestamp, number of statements. 6. Set exception behavior. On any login or download problem, mark the run an exception, keep the screenshot, notify the AP lead.

Repeat the pattern per portal. With Rindler the description is the whole setup: you write the task the way you would explain it to a new hire, and it runs on the sites your clients log into.

Track by client and by portal: the exception rate, mean time to detect, and mean time to repair. Detection time is the one that matters most to a client, because it is the gap between something going wrong and anyone knowing.

Set alerts on the runs where lateness is expensive rather than on everything: prior authorization runs, end-of-month invoice and statement pulls, timecard approvals for large staffing clients. Tie each alert to an action. On a single exception, review the log and the screenshot and decide whether to rerun or revise the runbook. On repeated exceptions, schedule a portal review and tell the client what changed.

For each run, retain the client and portal name, start and end timestamps, the outcome per item processed, the status and its reason, and links to the artifacts. That is what lets you answer "did you submit that prior authorization last Tuesday" without digging through the portal by hand.

Once a few runs are boring, turn them into an offering. The common shapes are per portal per month, per task per month, per run in bundles, or tiered service levels that vary the number of portals and the response time on exceptions.

When you write the service terms, commit to the things you control. Response time on exceptions and the coverage window for runs are both defensible. Stay away from promising success rates you cannot prove. Promise visibility instead: every run has a record, and every exception is visible and acted on.

Present it to clients in those terms. You take over the repetitive portal work they still do by hand; they get a report of what ran, what completed, and what needs action. Sample reports showing runs per day, exceptions and resolutions, and files downloaded make it land as finished work rather than as another tool to learn.

Add one new portal or task per cycle, reuse the security and monitoring patterns, and keep every run backed by a runbook.

Some portals are harder: legacy hospital and carrier systems, government sites with unpredictable downtime, client VMS portals with multi-step approvals. Treat those as higher risk. Monitor them more tightly, put extra detail in the logs, and be conservative about what you commit to. If a portal repeatedly refuses to cooperate, document that plainly and adjust the scope rather than carrying a run you quietly know is unreliable.