Redesigning OPD Claims Processing from Agent Workarounds to a Scalable Claims Workflow

Claims processing problems rarely announce themselves as product problems.

On the surface, the issue looks operational:

Claims are taking time.
Agents are switching screens.
Documents are missing.
Duplicate requests are piling up.
Customers are waiting.
Processors are under pressure.

But when I worked on BFHL’s OPD Reimbursement Claims Processing project, the real product problem became clear only after going close to the users.

I went to the call center and sat with the claim processing agents.

That changed the entire framing.

This was not just a Salesforce workflow project. It was a redesign of how OPD reimbursement claims should be processed, prioritized, validated, documented, and moved toward assisted decisioning.

The situation

In 2022, BFHL’s OPD reimbursement claims were being processed through Salesforce.

Each claim came in as a Service Request, or SR. For practical purposes, every SR represented a claim that needed to be reviewed, validated, processed, and closed.

The claims came through multiple channels:

• email,
• app,
• portal.

The processing team had to handle claim details, documents, duplicate SRs, customer information, eligibility rules, claim validation, and closure decisions.

At the business level, the goal was clear:

Improve claim processor productivity, reduce manual effort, and create a more scalable OPD reimbursement processing model.

But the actual blockers were hidden inside the day-to-day agent workflow.

What was actually broken

The system existed. Claims existed. Agents were processing them.

But the workflow was not designed around how processors actually worked.

Agents were managing work outside the system

One of the clearest signs of workflow failure was that processors downloaded SR lists into Excel.

They used Excel to manage their work and then manually searched SR numbers inside Salesforce.

That meant the core claim-processing system was not functioning as a true work allocation engine.

The processor’s day started with:

download list → find SR → search manually → open case → process.

That created avoidable friction before the actual claim review even began.

Claim context was fragmented

Processors had to jump between multiple Salesforce screens to understand a single claim.

They moved across:

• SR details,
• customer details,
• search results,
• document views,
• older SRs,
• rule checks,
• decision screens.

This created cognitive load.

The processor was not only making a decision.
They were first assembling the information needed to make that decision.

That is a bad operating model.

The system should bring decision context to the processor.
The processor should not have to hunt for it.

Duplicate SRs were creating invisible waste

Customers could raise multiple SRs for the same claim through email, app, or portal.

From the customer’s perspective, this made sense. If they did not know what was happening, they tried again through another channel.

But for operations, this created duplicate work.

Duplicate SRs meant:

• same claim appearing more than once,
• documents scattered across requests,
• processors spending time identifying duplicates,
• risk of inconsistent handling,
• poor customer tracking,
• unnecessary queue load.

The duplicate problem was not minor. It was a meaningful source of operational waste.

Document handling was too manual

OPD reimbursement claims are document-heavy.

Processors had to review bills, prescriptions, supporting documents, and sometimes older claim documents to validate authenticity or continuity.

But document handling was not smooth.

Processors used external tools for basic operations.
JPEG preview issues forced conversion to PDF.
Documents received through email had to be uploaded manually.
Older SR documents had to be searched and compared manually.

This was a major source of time leakage.

A claims platform cannot scale if document work happens outside the claims workflow.

Rules were not embedded deeply enough

Eligibility checks, document completeness, benefit rules, policy rules, amount validation, and duplicate checks needed to be performed consistently.

But a large part of claim validation depended on manual review and processor effort.

That created risk:

• inconsistent decisions,
• longer processing time,
• rework,
• missed validations,
• lower scalability.

The long-term product direction had to move toward STP and rule-led assisted processing.

The product insight

The obvious framing would have been:

“Agents need a better Salesforce screen.”

But the real insight was bigger.

OPD processors did not just need screens. They needed a system-led claims cockpit.

A claims cockpit would do four things:

1. bring work to the processor,
2. bring claim context together,
3. reduce duplicate and document friction,
4. support rule-led decisioning.

The key product shift was:

Move from processor-driven work assembly to system-driven claim processing.

Instead of agents finding claims, finding context, finding documents, finding rules, and then making decisions, the system needed to organize the work, surface context, validate inputs, and guide the processor.

What I shaped

I led product discovery and solutioning for the OPD Reimbursement Claims Processing project.

I was supported by one of my reportees.

My work included:

• floor-level discovery with claim processors,
• stakeholder interviews,
• form analysis,
• product requirement specifications,
• user journeys,
• workflow design,
• solutioning across queue management, Customer 360, document management, duplicate handling, and STP.

The project was built on Salesforce, but the thinking went beyond Salesforce configuration.

The goal was to redesign the operating model.

Track 1: Queue management

The first problem to solve was work allocation.

Processors were using Excel because the system was not giving them a clean, actionable claim queue.

The product direction was to move toward:

• auto-allocation,
• prioritized SR queues,
• ready-to-process claim lists,
• round-robin assignment,
• SLA-driven prioritization,
• agent-specific work views,
• escalation visibility.

This changed the workflow from:

Agent downloads Excel and searches claims manually.

to:

System assigns and surfaces actionable claims.

That is a fundamental productivity improvement.

Track 2: Customer 360 / One View

The strongest product intervention was Customer 360.

Processors needed one place to see the claim context.

The one-view model brought together:

• customer details,
• SR history,
• current claim details,
• uploaded documents,
• older SR documents,
• claim status,
• decision funnel,
• priority indicators,
• audit trail,
• relevant operational fields.

This was designed to reduce screen switching and cognitive load.

The processor’s job should be to evaluate the claim, not assemble the workspace.

Customer 360 changed the experience from:

move across screens to understand the claim

to:

open one view and begin decisioning with context.

Track 3: Duplicate SR handling

Duplicate SRs were a classic example of customer behaviour creating backend complexity.

Customers raised the same claim through different channels because they lacked confidence or visibility.

The product needed to identify and control duplicate requests.

The solution direction included:

• duplicate SR identification,
• source-level duplicate prevention,
• duplicate merge capability,
• duplicate audit trail,
• document comparison across SRs,
• visibility into duplicate creation and merge history.

This helped reduce duplicate effort and improved claim continuity.

The key product principle was:

The system should recognize claim continuity even when the customer interacts through multiple channels.

Track 4: Document Management System

Document handling had to become part of the claims workflow.

The DMS direction included:

• central document storage,
• SR-wise document mapping,
• customer-wise document mapping,
• document preview,
• full-size view,
• zoom,
• rotate,
• OCR for selected segments,
• image preprocessing for blurred documents,
• document comparison,
• duplicate document suggestion.

This reduced dependency on external tools and manual conversion.

It also improved claim validation because processors could access document context more easily.

A reimbursement claim is only as strong as the documents supporting it. So document management was not a support feature. It was a core claim-processing capability.

Track 5: STP and Rule Engine

The long-term product direction was to move toward Straight Through Processing.

The STP scope included:

• eligibility checks,
• document completeness,
• amount validation,
• policy rules,
• benefit rules,
• duplicate checks,
• related rule validations.

The product vision was:

zero data-entry approval, where the agent primarily checks and approves system-supported decisions.

STP went live.

The full zero-data-entry approval state was envisioned during the project and achieved later, after I had moved out of the project.

That distinction is important.

I would describe it as:

I defined the zero-data-entry approval direction and helped build the rule-led foundation. The capability matured and was achieved after I had moved out of the project.

That is accurate and still strong.

How the workflow changed

Before the project, the claim processor’s experience looked like this:

download SR list → search claim manually → open SR → switch screens → check customer details → find documents → compare older SRs → validate rules manually → decide → close or move forward.

After the product redesign, the workflow moved toward:

system-assigned queue → open claim context in Customer 360 → review documents in structured DMS → identify duplicate history → validate rule outputs → process decision with better audit and control.

The change was not just faster processing.

It was a better way of working.

The processor moved from being an information gatherer to being a decision maker.

What made this hard

This project was hard because the problem was hidden inside everyday workarounds.

If I had only spoken to stakeholders, the answer might have been a generic Salesforce enhancement.

The real product insights came from watching claim processors work.

The system was not the only source of truth

Agents relied on Excel, documents, older SRs, and manual knowledge.

The workflow crossed multiple channels

Claims came through email, app, and portal, creating duplicate and document-handling complexity.

Productivity depended on small frictions

A few minutes lost in searching, switching screens, converting files, or checking duplicates became significant at scale.

Automation had to be introduced carefully

Claims processing required rule confidence, auditability, and human validation.

The future state had to be staged

The project could not jump directly to full automation. It needed queue management, one-view context, DMS, duplicate handling, and rule engine foundations first.

What was achieved

The project improved OPD claim-processing productivity.

Before-state productivity was:

75 claims per day per processor.

After the project:

130 claims per day per processor.

The program projected and achieved a 30% efficiency improvement.

STP went live.

The platform moved toward a zero-data-entry approval model, which was achieved later after I moved out of the project.

The project also created a stronger processing foundation through:

• system-led queues,
• Customer 360,
• document management,
• duplicate handling,
• rule-based validation,
• STP direction,
• better processor context,
• improved operational control.

Why this mattered for BFHL

OPD reimbursement claims are high-volume, operationally sensitive, and customer-facing.

Slow claim processing affects customer trust.
Manual workflows increase cost.
Fragmented context increases error risk.
Duplicate SRs create invisible workload.
Poor document handling slows decisions.
Weak rule validation reduces scalability.

This project helped BFHL build a more scalable claim-processing operating model.

It converted a manual, workaround-heavy process into a more structured, system-led workflow.

What this says about my product approach

This project is one of the clearest examples of how I use design thinking in operational products.

I did not start with a feature request.

I sat with the users.
I watched the work.
I identified the workarounds.
I mapped the friction.
I separated surface symptoms from root causes.
Then I translated those insights into product capabilities.

The important product principle was:

When users build workarounds outside the system, the workaround is the product requirement.

Excel lists, manual searches, external document tools, duplicate checks, and screen switching were not random behaviours. They were evidence of where the product was failing.

The product job was to absorb those workarounds into the system.