Insurance operations
Twelve carriers, twelve portals, one claims queue.
Brokers and self-insured employers live inside carrier portals. Each insurer has its own login, its own status vocabulary, and its own document upload flow, and none of them will build an API for a book of business this size.
Checking whether anything moved
-
Sign in to each carrier
Broker credentials, often with MFA, sometimes with a separate sub-account per client division. Session lifetimes vary from an hour to a month.
-
Walk the claim list
Open each open claim. Read the status. Check whether a reserve changed, a payment was issued, or a document was requested.
-
Answer what was asked for
A carrier requests a document in the portal. Someone has to find the request, retrieve the file and attach it, often days later, because nobody saw the request.
-
Update the system of record
Retype the status into the broker management system. This is the step that quietly costs the most hours.
Poll every carrier, flag what needs a human
- Scheduled status polling across all carriers, unattended.
- Document request detection: flag a new request the day it appears, not the week someone logs in.
- Structured extraction: pull the claim’s status, dates and amounts out of the page as fields, not screenshots, so your system can read them.
- Assertions before any write: attaching a file to a claim is a real action, so it runs only after steps that prove the portal is showing the claim you think it is.
- Webhook delivery of each run’s result into your system of record.
The real win is latency: a carrier asks for a document on Tuesday and you know on Tuesday, not whenever someone next remembers to look.
What makes this case distinctive
Status vocabulary is not standardised
One carrier’s “in review” is another’s “pending adjudication”. Runs extract the literal string and you map it once per carrier. We recommend extracting rather than normalising, so a carrier quietly changing wording becomes visible instead of being silently absorbed.
Documents are the slow part of every claim
In practice the delay is rarely the insurer. It is the round trip between a document being requested and someone noticing. Detecting the request automatically removes most of that latency.
Read-only is the right starting line
Status polling and document detection carry essentially no risk, and that is where a deployment starts. Attaching a file to a claim is a real action with real consequences, so it comes second, behind assertions that confirm the portal is showing the claim you intend, and even then it is a step we write with you, not a feature you configure.
The honest failure mode
Carrier portals are among the most aggressively session-limited we encounter, some expire in under an hour and re-prompt for MFA. Those will need frequent re-capture. We will tell you which of your carriers behave this way during the pilot.
Point it at your two noisiest carriers.
Status polling only. You’ll see the latency drop in a week.