Claims intake automation, the part that actually saves the 30 minutes

Why the savings live in the claim center, not the inbox

Walk a CSR through a single FNOL on the floor of any mid-market carrier and the time breakdown is consistent. The customer-facing intake step (filling out a portal form, leaving a voicemail, sending an email) takes the customer maybe two minutes. The CSR side is where the cost is. The CSR opens Guidewire ClaimCenter, navigates to New Claim, finds the policy, and starts typing. Policy number, loss date, loss time, loss location, damage description, three contact fields, an estimated loss amount, line-of-business specifics, photos. Then they email a manager who opens an adjuster workload spreadsheet, picks the right adjuster based on geography and capacity, replies to the CSR, who then emails the customer and the adjuster. The 30 minutes per claim is in that block.

IDP and OCR shave a few minutes off the very front by extracting fields from the FNOL form. They do not type those fields into ClaimCenter. They produce a JSON payload and hand it back to the CSR, who still has to log in, click through the screens, and put the values in. The reason the savings stay locked is that the data has to land inside a Windows desktop application that does not expose a clean API for claim creation, and that is where the interesting engineering question lives.

The seven steps a real run executes

Toggle below to see the same workflow run by a human and run by Mediar. Same systems, same fields, same assignment rule. Different wall-clock time and a very different staffing model during a catastrophe spike.

The mechanism: drive the claim system the way a screen reader does

The unusual part of how Mediar runs intake is that the agent does not look at pixels. It reads the live accessibility tree that Windows exposes for every desktop application. That tree is the same data structure a screen reader consumes when it announces a button or a form field to a user with low vision. Field labels (Policy Number, Loss Date, Loss Description), button names (New Claim, Save, Submit), table rows, and tab states are all named, structured nodes inside the tree.

Driving ClaimCenter through that tree means we type into a field called PolicyNumber, not into the rectangle at coordinates (842, 318). When ClaimCenter ships a quarterly UI refresh and the field moves a hundred pixels, the field is still called PolicyNumber, and the workflow keeps running. The same approach handles Duck Creek Claims, customized Salesforce claim screens, and the green-screen mainframe systems still in production at a few mid-market carriers, because the accessibility layer lives at the OS level, not the app level.

This is the property RPA Center of Excellence leads care about. The bot does not need to be re-mapped after a ClaimCenter point release. The maintenance ticket queue stops growing. That is the underlying reason a Mediar workflow ships in days while a UiPath rollout against the same screen tends to ship in months.

What Mediar covers, named explicitly

The systems and the inputs that show up most often on a real intake project.

The Florida P&C carrier benchmark

Concrete numbers, drawn from the customer write-up at mediar.ai/solutions/insurance. A regional Florida-based P&C carrier with 383,000 active policies, growing 43 percent year over year, 50,000 claims per year, a claims team of 15 CSRs and 5 managers. Their baseline was 30 minutes per claim of pure data entry, plus a five hour wait between customer submission and CSR pickup during busy periods. Total time from FNOL to adjuster notification: 8 hours, end of day.

After deploying Mediar against their Guidewire instance: 9:00 am the customer submits, 9:02 am the agent has populated the claim, 9:03 am the adjuster is assigned and notified. Three minutes wall-clock instead of eight hours. Per-claim intake dropped from 30 minutes to 2 minutes, which is the figure most ops leaders care about because it is the number that drives the labor model.

The pricing math for a 50K-claims carrier

Mediar charges $0.75 per minute of runtime, no per-seat license, no separate orchestrator. A 500-claim-per-week workflow at 1 minute per claim of agent runtime is about 2,000 minutes per month, or roughly $1,500 a month at the headline rate. The customer side of the math: the same workflow saves 75 hours of CSR labor per week, which at a typical fully loaded CSR cost lands near $12,000 per month. That is the 8x monthly ROI figure on the public insurance solution page, and it does not include the overtime and temp-staffing savings during a catastrophe spike, which tend to be larger than the steady-state number for a Florida carrier.

The $10,000 turn-key program fee converts to prepaid credits with a bonus, so for teams that want a flat one-line PO instead of per-minute billing the program is effectively prepaid usage. Compared to a UiPath or Automation Anywhere ClaimCenter rollout, the typical mid market quote is six figures of license plus six figures of implementation, plus a maintenance line item that grows every time ClaimCenter ships a UI refresh.

What this approach does not do

The agent is a typist, not an underwriter. It does not introduce a parallel adjuster routing engine, it does not adjudicate coverage, and it does not decide settlement amounts. The auditable assignment rule lives in your existing ClaimCenter or Duck Creek configuration, or in a small SQL view your team owns. The agent reads the live workload, geography, and specialization fields that rule needs, then takes the action your rule already prescribes.

For carriers without a desktop claim center at all, the right shape is different. A fully cloud-native carrier on a SaaS claim platform with a real REST API should integrate there directly. The accessibility-tree approach is the answer specifically when the claims data has to land inside a Windows desktop application, which is still where most mid-market and regional carriers run.