Turning Bookings into Fulfilment Assurance

A booking confirmation does not always mean the service will happen.

That sounds obvious in hindsight, but it is one of the biggest gaps in healthcare service journeys. A customer books a lab test or a doctor appointment. The app shows that the request is placed. But behind that screen, the actual fulfilment still depends on provider confirmation, appointment availability, reminders, rescheduling, report generation, and manual follow-ups.

If any one of those steps fails, the customer does not see it as a backend issue.

They see it as broken trust.

That was the core problem behind BFHL’s Service Guarantee initiative.

After working on OPD Reimbursement Claims Processing, I led the Service Guarantee project in 2022. The goal was to make lab test bookings and doctor appointments more reliable by converting fragmented fulfilment follow-ups into a structured, trackable, communication-led operating model.

The situation

BFHL customers could book lab tests and doctor appointments through digital journeys.

But booking was only the first step.

For the service to actually be fulfilled, several things had to happen after the customer placed the request:

• the booking had to become visible to operations,
• the provider had to confirm,
• the customer had to be updated,
• rejection or no-response scenarios had to be handled,
• rescheduling had to be supported,
• reminders had to be sent,
• appointment completion had to be tracked,
• reports or closure status had to be followed up,
• escalations had to happen before the customer complained.

The challenge was that this journey had multiple actors:

• customer,
• provider,
• fulfilment agent,
• operations team,
• HRx,
• SFDC,
• app/web journey,
• WhatsApp/SMS/voice communication layer.

The product problem was not just creating a case in Salesforce.

The product problem was ensuring that BFHL could stand behind the service promise.

What was actually broken

The broken part was not appointment booking.

The broken part was everything that happened after booking.

Booking did not equal fulfilment

A booking request could be raised, but provider confirmation was still needed.

Until the provider accepted the appointment, the customer journey was uncertain.

The customer might think the appointment is progressing.
The provider might not have confirmed yet.
The agent might not know the case needs intervention.
The system might not have triggered the right communication.

That gap created anxiety and complaints.

Provider response was a critical dependency

Providers could respond in multiple ways:

• accept the appointment,
• reject the appointment,
• suggest another slot,
• not respond within the expected time.

Each scenario needed a different system response.

If the provider accepted, the customer needed confirmation.

If the provider rejected, the customer needed recovery options.

If the provider suggested a new slot, the customer needed rescheduling.

If the provider did not respond, the case needed escalation.

Without a structured workflow, provider response became a manual follow-up problem.

Customers lacked proactive visibility

Customers should not have to chase the system after booking.

They needed timely updates:

• request received,
• provider confirmation pending,
• appointment confirmed,
• appointment rejected,
• reschedule required,
• appointment reminder,
• post-appointment follow-up,
• report/status update.

Without this, customer care dependency increases.

A customer who does not know what is happening will call, complain, or lose trust.

Agents needed actionable queues

Fulfilment agents needed more than a case list.

They needed to know:

• which cases were new,
• which cases needed provider calling,
• which providers had not responded,
• which cases were rejected,
• which customers needed rescheduling,
• which appointments were confirmed,
• which appointments were completed,
• which cases could be closed.

A raw case list does not drive fulfilment.

An actionable queue does.

Operations needed TAT control

Service Guarantee was about accountability.

If provider confirmation is delayed, someone must know.
If the customer has not been updated, someone must act.
If an appointment is at risk, it must move into an escalation path.

Without TAT-based escalation, broken journeys remain invisible until the customer complains.

The product insight

The easy way to define the project would have been:

“Build SFDC case management for lab and doctor appointments.”

But that would have missed the real point.

The deeper product insight was:

Customers do not buy a booking. They trust BFHL to make the service happen.

That insight changed the product framing.

The project became less about appointment management and more about fulfilment assurance.

The design question became:

How do we make sure every lab test or doctor appointment request is tracked, confirmed, communicated, escalated, recovered, and closed through a controlled service workflow?

This is what made the project a Service Guarantee initiative, not just a case-management project.

What I shaped

I led the full Service Guarantee initiative as Lead Product Manager in 2022.

The project covered:

• lab test booking fulfilment,
• doctor appointment fulfilment,
• SFDC case management,
• HRx-SFDC integration,
• app-facing status visibility,
• provider confirmation workflow,
• customer communication automation,
• WhatsApp/SMS/voice-blast triggers,
• TAT-based escalation,
• booking recovery flows.

I worked with junior PMs to create the user stories, action plan, flows, integration requirements, communication triggers, and delivery requirements.

The complete Service Guarantee flow went live.

ProviderRx was evaluated as a separate provider-side track but was deprioritized. The core Service Guarantee flow did not depend on ProviderRx going live.

Track 1: Converting bookings into trackable cases

The first requirement was simple but foundational:

Every relevant booking needed to become an operationally trackable case.

If a lab test or doctor appointment existed only as a booking record but did not enter the fulfilment workflow, operations could not own it.

The system had to create SFDC cases from booking events and carry enough information for agents to act.

This included:

• customer details,
• appointment details,
• provider details,
• appointment date and time,
• service type,
• case status,
• fulfilment stage,
• action ownership.

This created the operating layer for Service Guarantee.

Track 2: HRx-SFDC integration

HRx and SFDC had to stay aligned.

HRx carried the booking journey.
SFDC carried the fulfilment case workflow.

If the two systems showed different states, agents and customers would lose trust.

The integration had to support:

• booking data flowing into SFDC,
• case status updates flowing back,
• app-facing status visibility,
• fulfilment-stage tracking,
• case closure logic.

This was important because the customer should not have to call support to know what is happening. The app itself needed to reflect the service state.

Track 3: Provider confirmation workflow

Provider confirmation was the most important operational moment in the journey.

Until the provider confirmed, the service was not guaranteed.

The workflow had to handle multiple provider outcomes.

If provider accepted

The case moved toward appointment confirmation and the customer was updated.

If provider rejected

The system triggered a recovery path, including customer communication and reschedule/callback options.

If provider suggested a new slot

The customer needed to be contacted or routed into a reschedule flow.

If provider did not respond

The case needed automated nudges, voice-blast escalation, and manual agent intervention.

This turned provider response into a structured workflow instead of a manual follow-up activity.

Track 4: Agent queues and operational work buckets

Agents needed cases organized by action.

The system needed to help them answer:

What should I work on right now?

The fulfilment queues included states such as:

• new cases,
• new cases requiring calling,
• cases being processed by agent,
• provider requires calling,
• declined by provider,
• waiting for customer rescheduling,
• no response from provider,
• confirmed by provider,
• confirmed by both customer and provider,
• appointment completed,
• case closed.

This transformed agent work from manual tracking to state-based fulfilment operations.

The product goal was to make the next action obvious.

Track 5: Customer communication automation

Service Guarantee needed proactive communication.

The customer should not be left guessing.

Communication automation went live through:

• WhatsApp,
• SMS,
• voice blast.

The communication journey covered moments such as:

• booking request received,
• provider confirmation,
• appointment rejection,
• reschedule requirement,
• reminders before appointment,
• post-appointment follow-up,
• report/status closure.

This reduced customer uncertainty and helped prevent avoidable complaints.

The communication layer was not just a notification feature. It was part of the service promise.

Track 6: App-facing status visibility

One of the most important customer-facing capabilities was status visibility.

Customers needed to see where their request stood.

The app-facing status experience helped communicate whether the appointment was initiated, pending confirmation, confirmed, completed, or closed.

This mattered because transparency reduces anxiety.

Even if a case is still pending, the customer experience is better when the system clearly shows the status instead of forcing the customer to call support.

Track 7: TAT-based escalation

A guarantee is meaningless without time control.

The system needed defined TATs and escalation triggers.

If provider response did not come within the expected window, the system had to move the case into an escalation path.

This included:

• automated reminders,
• voice blast,
• agent queue movement,
• manual calling,
• unresolved case tracking,
• escalation visibility.

The goal was to catch fulfilment failures before they became customer complaints.

Track 8: Recovery flows

Real-world service journeys are rarely perfect.

Providers reject.
Customers miss calls.
Slots become unavailable.
Appointments need to be rescheduled.
Cases require manual intervention.

So the product needed recovery flows, not only happy paths.

Recovery scenarios included:

• provider rejection,
• provider no-response,
• alternate slot suggestion,
• customer rescheduling,
• cancellation,
• callback request,
• manual fulfilment support.

This was a key product principle:

A service workflow is only as strong as its exception handling.

How the workflow changed

Before Service Guarantee, the journey looked closer to this:

Customer books service → provider confirmation happens manually → agent follows up if needed → customer receives inconsistent updates → unresolved cases become complaints.

After Service Guarantee, the workflow moved toward:

Customer books service → SFDC case created → provider confirmation tracked → customer updated automatically → no-response cases escalated → agent works from action queues → appointment completion tracked → case closed with better visibility.

The biggest change was ownership.

The old model relied on people remembering to follow up.
The new model made the system responsible for surfacing what needed follow-up.

What made this hard

This project was hard because it sat between product, operations, provider behaviour, and customer trust.

Multiple actors had to stay aligned

Customers, providers, agents, HRx, SFDC, app/web, and communication systems all had to reflect the correct journey.

Provider behaviour was unpredictable

Providers could accept, reject, reschedule, delay, or not respond. The product had to handle all of these outcomes.

Communication timing mattered

Too little communication created anxiety.
Too much communication created noise.
Wrong communication created confusion.

Fulfilment could not be measured by case creation

A case being created did not mean the service happened.

That is why Fulfilment Rate became the primary success metric.

The workflow needed operational discipline

TATs, queues, escalation, and case closure had to be defined clearly. Otherwise, the system would simply digitize the old manual process.

What was achieved

The complete Service Guarantee flow went live.

The delivered scope included:

• lab test fulfilment flow,
• doctor appointment fulfilment flow,
• SFDC case-management workflow,
• HRx-SFDC integration,
• app-facing status visibility,
• provider confirmation workflow,
• WhatsApp communication,
• SMS communication,
• voice-blast automation,
• TAT/SLA-based escalation,
• booking recovery flows.

The primary metric was Fulfilment Rate.

Other secondary metrics included:

• provider confirmation TAT,
• appointment completion,
• customer complaints,
• provider response,
• SLA adherence,
• reschedule/rejection handling.

Exact before/after numbers are not available, so the honest impact statement is:

Customer complaints reduced significantly after rollout.

The business objectives were:

• improve customer trust,
• improve provider accountability,
• reduce broken fulfilment journeys,
• create a more reliable service experience.

Why this mattered for BFHL

Service Guarantee strengthened BFHL’s healthcare service promise.

A health platform cannot build trust only by allowing customers to book services. It must also take responsibility for fulfilment.

This project helped BFHL move from:

booking-led healthcare access

to:

fulfilment-led healthcare assurance.

That shift matters because customers remember whether the service happened smoothly, not whether the backend case was created successfully.

What this says about my product approach

This project reflects my belief that product management is not only about screens and features.

Sometimes the real product is the operating model.

In Service Guarantee, the most important work was not designing one page or one button. It was defining how a booking becomes a promise, how that promise is tracked, how providers are held accountable, how customers are kept informed, how agents know what to do, and how failures are recovered.

The product principle was:

Do not stop at request creation. Design until the customer outcome is actually fulfilled.

That principle shaped the entire Service Guarantee project.