Turning a Provider Portal into a Partner Operating Center

Provider portals often become dumping grounds.

A place where partners can log in, download a report, raise a ticket, and maybe check a few transactions. They exist, but they do not change behaviour. Partners still call the RM. They still message on WhatsApp. They still ask support teams for transaction details, settlement status, appointment updates, report uploads, and issue resolution.

That was the real product problem behind Partner Center.

The earlier Provider Portal was not enough for the scale and direction of HealthPay. BFHL needed something broader: a partner-facing operating platform where labs, hospitals, diagnostic partners, and HealthPay merchants could manage their day-to-day work without depending on internal teams for every basic action.

The product was completely revamped and renamed Partner Center.

The rename was not because the scope moved beyond providers. It was because the product itself was being reimagined — from a portal into a working system for partners.

The situation

By the time I moved into Partner Center, HealthPay had already started building strong transaction, settlement, and partner workflows.

But partners were still dependent on BFHL teams for many routine needs.

A lab partner needed to know:

• which appointments were assigned,
• which appointments needed action,
• whether reports were uploaded,
• whether settlements were processed,
• whether transaction data was available,
• whether a support issue was open.

A HealthPay merchant needed:

• order visibility,
• settlement visibility,
• QR-level transaction filters,
• downloadable reports,
• payment status,
• customer mobile visibility,
• issue resolution.

A hospital partner needed:

• lead visibility,
• lead actions,
• claim assistance,
• status updates,
• future appointment and settlement workflows.

Internal teams also had their own pain.

RMs and support teams were spending time answering repetitive queries that should have been self-serve. Operations teams needed partner adoption visibility. Business teams needed to know whether partners were actually using the platform or still relying on manual support.

The product opportunity was clear:

Build one partner-facing platform that reduces dependency, improves visibility, and gives partners enough control to manage their own operational workflows.

What was actually broken

The problem was not that partners lacked a login.

The problem was that the partner experience was fragmented.

Partners lacked self-serve visibility

For basic information like orders, settlements, appointments, QR transactions, and reports, partners often needed to reach out to BFHL teams.

This created friction because partners could not independently answer simple operational questions:

• Has this transaction settled?
• Which QR generated this payment?
• Can I download the data?
• Which appointment is pending?
• Has the report been uploaded?
• Which lead needs action?
• What happened to my support query?

When partners cannot answer these questions themselves, the platform becomes invisible and the RM becomes the product.

RM and support dependency was too high

If every operational question required a call, message, or escalation, the system was not scaling.

RMs were pulled into routine support.
Support teams handled repetitive requests.
Partners developed habits around WhatsApp and direct calls instead of using product workflows.

That meant Partner Center had to change not only functionality, but behaviour.

Different partner types had different workflows

A lab, a hospital, and a HealthPay merchant do not work the same way.

A lab cares about appointments, sample collection, report upload, and lab settlements.
A hospital cares about leads, claim assistance, and future appointment/payout flows.
A HealthPay merchant cares about QR transactions, orders, settlements, downloads, and payment visibility.

A generic provider portal would not solve all of this.

The product had to be modular but unified.

Access control needed to reflect real partner hierarchies

Partners were not single users.

A large diagnostic chain could have head-office users, center-level users, finance users, operations users, and staff members across locations.

In real usage, shared logins appeared because the platform did not yet fully match partner hierarchy and access needs.

This was a product signal.

The system needed stronger access control, user hierarchy, superuser roles, center-level visibility, and adoption tracking.

Field payment workflows were different from ideal product journeys

In the phlebo and lab context, actual field behaviour was practical and messy.

Payments were happening through QR codes and payment links.
Payment confirmation and reconciliation were often coordinated centrally.
POS machines were not the dominant field mechanism.
Cash and UPI were still part of the operating reality.

So the product could not be designed for a clean digital-only assumption.

It needed to support QR-level visibility, payment links, center-wise QR usage, and reporting that matched how partners actually operated.

The product insight

The obvious product answer would have been:

“Improve the provider portal.”

But that would have been too small.

The deeper insight was:

Partners did not need another portal. They needed an operating center.

A portal is where users go to see information.
An operating center is where users go to run their work.

That distinction shaped the product direction.

Partner Center needed to become the place where partners could:

• view HealthPay orders,
• track settlements,
• manage lab appointments,
• accept or decline appointments,
• upload reports,
• raise support tickets,
• manage hospital leads,
• access claim assistance,
• use QR/payment workflows,
• download reports,
• work within access-controlled hierarchies,
• eventually access unified ledger and reconciliation views.

This moved the product from passive visibility to active partner operations.

What I shaped

I led the Partner Center revamp in 2023 under HealthPay.

I owned the full Partner Center scope across HealthPay, Labs/Lab Connect, Hospitals, Help & Support, Analytics, Access Control, roadmap, user stories, stakeholder alignment, GTM/adoption, dashboarding, and delivery.

Maaz Modak and Abhishek Behera supported me as PMs.

The work was structured into multiple product tracks.

Track 1: HealthPay Orders and Settlements

The HealthPay track gave partners visibility into their financial transactions.

This was foundational because payment trust depends on transparency.

Partners needed to answer basic questions without calling BFHL:

• What transactions happened?
• Which orders are settled?
• Which are unsettled?
• What was the payment mode?
• Which QR was used?
• Can I search by order ID?
• Can I download the data?
• Can I view settlement details?

The platform enabled HealthPay Orders and Settlements to go live.

The experience included:

• orders view,
• settlements view,
• transaction detail view,
• configurable columns,
• settlement-to-transaction drilldown,
• QR filters,
• store filters,
• settlement status filters,
• payment mode filters,
• order search,
• data download/export.

This changed the partner experience from asking BFHL for payment data to accessing transaction and settlement visibility directly.

Track 2: Lab Appointment Management

Labs needed Partner Center for operational fulfilment, not only financial reporting.

Lab Appointment Management went live with capabilities that allowed lab partners to act on appointment workflows.

The platform supported:

• appointment visibility,
• appointment notifications,
• accept/decline appointment,
• report upload,
• appointment-level operational actions,
• future enhancements around rescheduling, filters, and settlement journeys.

This mattered because lab operations are time-sensitive.

A lab appointment is not just a record. It requires action: accept it, prepare for it, complete the service, upload the report, and close the loop.

Partner Center helped move those actions closer to the partner.

Track 3: Partner Report Upload

Report upload was a critical capability for lab workflows.

Without partner-side report upload, BFHL remained dependent on manual coordination. Reports could be delayed, missed, or chased through operational channels.

By enabling report upload inside Partner Center, the platform gave partners a clearer path to complete the service journey.

This was important for customer experience as well.

For a customer, the lab journey does not end when the sample is collected. It ends when the report is available.

Partner Center helped bring that final step into the product workflow.

Track 4: Help & Support SR Creation

Support was one of the most important horizontal tracks.

Partners needed a structured way to raise queries instead of depending on WhatsApp, calls, or RM escalation.

Help & Support SR creation went live.

This created a more controlled support model:

• partner raises query,
• query becomes trackable,
• status can be monitored,
• support dependency becomes measurable,
• repeated issues can be analyzed,
• partner frustration reduces.

This was a key move from informal support to productized support.

The goal was not only faster resolution.
The goal was better ownership and visibility.

Track 5: Hospital Lead Management and Claim Assistance

Hospitals had a different partner journey.

They needed visibility into leads and support for claim-related assistance workflows.

Partner Center enabled:

• hospital lead management,
• lead visibility,
• lead actions,
• claim assistance.

This extended the platform beyond payment and lab workflows into hospital-facing business operations.

It also reinforced the idea that Partner Center was not a single-feature portal. It was a multi-cohort partner platform.

Track 6: Access Control and Partner Hierarchy

One of the more important product realities was that partners had different internal users.

A diagnostic chain could not be treated the same way as a single-center provider.

The platform needed:

• access control,
• superuser roles,
• user hierarchy,
• center-level access,
• business-specific permissions,
• partner-level visibility,
• internal adoption tracking.

This was not just an admin feature.

It was a scale feature.

If access control is weak, partners share logins. If partners share logins, adoption data becomes unreliable. If adoption data is unreliable, GTM and usage strategy become guesswork.

Access control made the platform more enterprise-ready.

Track 7: Analytics, Dashboarding, and Adoption

Partner Adoption was the primary success metric.

That meant the product had to be measured not only by features delivered, but by whether partners actually used them.

The platform needed visibility into:

• users created,
• active users,
• transacting partners,
• partner activation,
• feature usage,
• HealthPay transactions,
• appointment usage,
• settlement views,
• support usage,
• adoption by partner cohort.

This allowed internal teams to move from “we launched the portal” to “partners are actually using the platform.”

That difference is critical.

A product is not successful because it is live.
It is successful when it changes behaviour.

How the workflow changed

Before Partner Center, many workflows looked like this:

Partner needs information → calls RM or support → internal team checks system → data shared manually → follow-up continues on WhatsApp/email/calls.

After Partner Center, the target workflow became:

Partner logs in → views transactions/settlements/appointments/leads → takes action → downloads data → raises support query if needed → tracks status through product workflow.

This shifted the center of gravity.

The old model made BFHL teams the interface.
The new model made the platform the interface.

What made this hard

Partner Center was complex because it was not one product for one user type.

It had multiple partner segments, each with different jobs to be done.

HealthPay partners needed financial visibility

Orders, settlements, QR filters, downloads, and transaction details had to work reliably.

Labs needed operational workflows

Appointments, accept/decline actions, notifications, report uploads, and future reschedule workflows mattered.

Hospitals needed lead and assistance flows

Lead visibility, claim assistance, and future hospital appointment/payout workflows had to be supported.

Internal teams needed adoption control

Partner usage, active users, access hierarchy, and support dependency needed to be visible.

The roadmap had to balance live needs and future platform vision

Immediate needs included transactions, settlements, appointments, report uploads, support, and access control.

Future direction included:

• unified ledger,
• reconciliation aggregation,
• on-demand settlement,
• live notifications,
• agreements and commercials visibility,
• advanced analytics,
• closed-loop product visibility.

This required careful prioritization.

The challenge was to build enough value for adoption now while keeping the architecture and roadmap open for a broader partner operating platform.

What was achieved

Partner Center delivered multiple live capabilities under my ownership:

• HealthPay Orders and Settlements,
• Lab Appointment Management,
• partner report upload,
• Help & Support SR creation,
• Hospital Lead Management,
• Claim Assistance,
• Access Control,
• Analytics and dashboarding,
• adoption and GTM tracking.

The primary metric was Partner Adoption.

The project reduced RM and support dependency, improved partner trust and retention, and supported HealthPay GMV and transaction adoption.

Exact before/after adoption numbers are not available, so I would avoid claiming a specific percentage improvement.

The credible impact statement is:

Partner Center created a unified self-serve platform for BFHL partners, reducing operational dependency on RMs/support teams and improving partner trust, visibility, and adoption across HealthPay, Labs, Hospitals, and support workflows.

Why this mattered for BFHL

Partner Center mattered because partner experience directly affects business scalability.

If partners depend on RMs for every transaction, settlement, appointment, or support query, the business cannot scale efficiently.

If partners have self-serve access, the operating model changes.

Partner Center helped BFHL move toward:

• lower support dependency,
• higher partner transparency,
• better transaction visibility,
• stronger lab fulfilment workflows,
• more structured hospital lead handling,
• measurable adoption,
• future-ready partner platform architecture.

It also connected with the broader HealthPay vision.

HealthPay was not only a payment product. It needed partner trust, partner adoption, transaction confidence, and settlement visibility. Partner Center became the interface for that trust.

What this says about my product approach

Partner Center reflects one of my strongest product patterns:

I look for where operational dependency is hiding, then build product systems that convert dependency into self-service.

The easy answer would have been to improve UI screens.
The better answer was to redesign partner operations.

The product was not only about what partners could see. It was about what partners could do without asking BFHL.

That is the real difference between a portal and a platform.

A portal displays information.
A platform changes the operating model.

Partner Center was built to change the operating model.