Healthcare: Health Plan
The Situation
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:
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.
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.
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.
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.
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.
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.
Manual data transfers replaced
Each copy-paste event observed during Research was mapped to a specific data dependency between two systems. Thosedependencies became structured agent steps, replacing the undocumented manual workarounds the team had been using as their integration layer.
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.
50-70%
Projected effort reduction acrossthe full workflow
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 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.
