• Soroco Tops Everest Group’s PEAK Matrix® Assessment - Four Years in a Row
Read Now
Menu
Healthcare: Health Plan 

A Health Insurer Cut Provider Data Research Time by up to 70% by Giving Their Agents the Context Their SOPs Never Had

Consumer health customer case study healthcare illustration 1

The Situation

Managing physician data is one of the highest-stakes operational responsibilities for an health insurer. When a provider joins the network, changes their practice location, or terminates their relationship with the plan, that change has to propagate correctly across credentialing records, contracts, network directories, and claims systems. A mismatch anywhere in that chain creates problems that are expensive to unwind: claims paid at wrong rates, members routed to out-of-network physicians, credentialing compliance gaps, and physician trust eroded.
This health insurer had a large provider network and a dedicated operations team of 110 staff processing a continuous volume of changes across intake, scrubbing, and loading. The work was organised, staffed, and considered well-managed. And yet: throughput was constrained, accuracy was inconsistent, and the team was stretched.
They had tried automation before. Agents had been built and deployed. The results were inconsistent: agents worked on straightforward cases and struggled with anything outside the documented path. The team continued doing the complex work manually.

Industry

Healthcare: Health Plan 

Function

Provider Network Operations 

Team Size

113 Operations Staff 

Deployment

5 Agents · 90-Day implementation 

The Trigger

The question the operations director eventually asked was the right one:

“Are we building automation for the process as it was designed, or as it is actually executed?”

The team did not have a clear answer. The SOPs described the process as it was designed. Nobody had a complete picture of how it was actually executed: across all the case types, all the legacy system sequences, all the cross-system workarounds the team had developed over years of doing the work.

What the Operations Team Found

Scout observed how this team actually worked, capturing the full digital work sequences across every application, every system switch, every manual data transfer, and reconstructed a picture of execution that no SOP had ever described.
The headline finding arrived in the first week of analysis:
Finding What it meant for operations
76% of all effort sat inside a single step The Research stage, verifying a provider's identity and reconciling their records before any change is made, consumed the vast majority of all time observed across the Roster Manager role. The SOPs described it in a handful of bullet points. In reality, it was the entire workflow.
The team operated across three distinct workflows, not one Scout identified three substantively different execution paths across the five roles: a coordination role managing intake and research, a validation role performing high-volume data scrubbing, and two loading roles executing the final records update into the network database. Each required a different sequence of systems and handoffs. Only the simplest variant was documented anywhere.
A legacy network database was navigated by memory alone The core network database had no API access. Analysts navigated it across 25 distinct screens using sequences they had learned on the job. 489 navigation interactions were observed and mapped. Before this, that knowledge existed only in people’s heads. Inconsistent procedures across team members on how to navigate the system was one of the stated business challenges going in.
Physicians existed under different identifiers in different systems The same provider appeared under a credentialing number, a contract reference, a claims processing ID, and a case tracking number. Analysts knew which identifiers belonged together. No system linked them. Every cross-referencing decision was made by experienced staff from memory.
Manual data transfer was the de facto integration layer Hundreds of copy-paste events were observed, each one a data transfer between two systems with no technical integration. These were invisible to IT, undocumented in the SOPs, and responsible for a meaningful portion of the error risk in the workflow.
Intake was happening across two channels without standardisation Users spent 93% of their intake effort in Outlook and 7% in SharePoint. There was no standard. Different team members handled the same case type differently depending on how the request arrived.
Scrubbing work was invisible to documentation The validation role spent 50% of its effort scrubbing provider records in Excel, interacting with fields like Medicare Number, Degree, Birthdate, Name, and Gender, before uploading to the next system. This entire stage was undocumented at the field level. No SOP captured which columns mattered, in what order, or why.
The operations director’s reaction to the findings:
“What Scout captured about how our team actually works, the system sequences, the workarounds, the cross-referencing logic, none of that existed anywhere in our documentation. That’s what our previous automation was missing, and why this deployment succeeded where the earlier ones didn’t.”
Director, Provider Data Management 

What Changed

The team stopped designing agents from documentation. They designed from observed execution. This shifted the entire automation program. The question moved from “how do we automate the documented steps?” to “how do we build agents that can actually do what our most experienced analysts do?” Those are different questions with different answers. 

1 1

Routing by role and workflow, not by assumption

Every provider data change is now classified at intake before work begins. Agents receive the correct execution path, whether coordination, validation, or loading, from the start. The single biggest source of inconsistency in the old workflow is removed.

1

Routing by role and workflow, not by assumption

Every provider data change is now classified at intake before work begins. Agents receive the correct execution path, whether coordination, validation, or loading, from the start. The single biggest source of inconsistency in the old workflow is removed.

1 2

The legacy database, made accessible

The 25-screen navigation sequence that experienced analysts had learned over years of handling cases was reconstructed from the 489 navigation interactions Scout observed and codified into executable agent instructions. The network database that had no API and no documentation is now accessible to automation, following the same path an analyst would take.

2

The legacy database, made accessible

The 25-screen navigation sequence that experienced analysts had learned over years of handling cases was reconstructed from the 489 navigation interactions Scout observed and codified into executable agent instructions. The network database that had no API and no documentation is now accessible to automation, following the same path an analyst would take.

1 3

Provider identity resolved using context

The cross-referencing logic that analysts performed from memory, knowing that a credentialing number and a contract reference and a claims ID all referred to the same provider, was derived from the co-occurrence patterns observed in the workflow data. When those identifiers consistently appeared together in the same session, the relationship was captured. Agents now apply that logic systematically, replacing the manual reconciliation step that was the single largest time cost in Research.

3

Provider identity resolved using context

The cross-referencing logic that analysts performed from memory, knowing that a credentialing number and a contract reference and a claims ID all referred to the same provider, was derived from the co-occurrence patterns observed in the workflow data. When those identifiers consistently appeared together in the same session, the relationship was captured. Agents now apply that logic systematically, replacing the manual reconciliation step that was the single largest time cost in Research.

1 4

Intake standardised

A single intake channel is established. Agents handle intake consistently regardless of how requests previously arrived, removing a source of variation that had caused different handling of the same case type.

4

Intake standardised

A single intake channel is established. Agents handle intake consistently regardless of how requests previously arrived, removing a source of variation that had caused different handling of the same case type.

1 5

Scrubbing made explicit

The Excel-based scrubbing logic, which fields to validate, in what sequence, at what level of granularity, was derived from observed behaviour across the validation role and codified as structured agent steps. The undocumented field-level knowledge that previously lived only with experienced analysts is now part of the agent's execution context.

5

Scrubbing made explicit

The Excel-based scrubbing logic, which fields to validate, in what sequence, at what level of granularity, was derived from observed behaviour across the validation role and codified as structured agent steps. The undocumented field-level knowledge that previously lived only with experienced analysts is now part of the agent's execution context.

1 6

Manual data transfers replaced

Each copy-paste event observed during Research was mapped to a specific data dependency between two systems. Those dependencies became structured agent steps, replacing the undocumented manual workarounds the team had been using as their integration layer.

6

Manual data transfers replaced

Each copy-paste event observed during Research was mapped to a specific data dependency between two systems. Those dependencies became structured agent steps, replacing the undocumented manual workarounds the team had been using as their integration layer.

1 7

Calibrated, not just launched

A 52-day calibration phase ran alongside deployment. Operations staff reviewed agent recommendations and flagged overrides. The confidence threshold, the point below which an agent escalates to a human rather than acting, was set from this data, not from assumptions. On day one, the acceptance rate was 58%. After calibration: 89%.

7

Calibrated, not just launched

A 52-day calibration phase ran alongside deployment. Operations staff reviewed agent recommendations and flagged overrides. The confidence threshold, the point below which an agent escalates to a human rather than acting, was set from this data, not from assumptions. On day one, the acceptance rate was 58%. After calibration: 89%.

The Impact

The Research and loading stages that had consumed the majority of all workflow effort now run in a fraction of the time.

63%

Reduction in Research cycle time, the stage that accounted for 76% of all workflow effort

50-70%

Projected effort reduction across
the full workflow

3 months --> 4 weeks

Time to complete agent
blueprint discovery

89%

Agent recommendation acceptance rate following calibration, reflecting not just technical accuracy but how closely the agents mirror how the team actually works

Provider data throughput increased significantly without adding headcount

Cases that previously queued because Research was the bottleneck now process faster. The team handles higher volumes with the same staff.

Accuracy improved on the cases most prone to error

Physician identity is now resolved systematically using the observed cross-referencing logic rather than individual analyst memory. Cases that previously produced different outcomes depending on who handled them now produce consistent 
results.

The legacy system, now accessible to agents

The network database that previously could only be navigated by experienced staff is now accessible to agents. New staff onboard faster, with agents handling the system navigation that previously required years of accumulated muscle memory.

Institutional knowledge has been captured

The variant paths, the cross-referencing logic, the legacy navigation sequences: all of it now exists in the agent system, not only in the heads of the analysts who developed it. That knowledge is preserved when experienced staff leave.

The previous automation program’s failure is
now understood

Agents were built for the process as documented. The documented process covered one of twelve variants. Rebuilding from observed execution is why this deployment succeeded where the previous attempt did not.

Why This Matters Beyond One Team

Provider data accuracy is a financial and compliance exposure, not just an operational metric. Errors in physician records affect claims adjudication, member access to in-network care, credentialing compliance, and the accuracy of network directories that members and regulators rely on. At the scale of a large health insurer, the cost of inaccuracy compounds quickly.
Most health insurers that have tried to automate provider data operations have had the same experience this team did: agents that work in demos and struggle on real cases. The root cause is almost always the context the agent was given, and almost always fixable once the actual work is observed.
The agents that work are the ones built from how experienced analysts actually execute the work, rather than from how the process was designed to work. That distinction, between the documented process and the lived process, is where most enterprise automation programs find their limits.  

See Scout in action.
Schedule your demo now!

Get in Touch
Request demo