Defining Tele-consultation for Medlife
By: Abhinav Krishna
Tags: User Research, Design, Healthcare, Product, A B Testing

Also, we segmented the task of booking a consultation and providing secondary information like age, sex and supporting documents to maximise the booking of consultations without the need for providing additional details. This forking of the task-flow allowed us to half the time in which a consultation is booked and to ensure better secondary information flow through successful priming.

Service Model

On the back end of things, we followed a model that maximised a customer’s chance of finding a doctor. We achieved this by floating the customer request to a pool of 10 doctors for a limited amount of time (5 minutes). The minute a request is accepted, it would expire on all other doctors.

Another advantage of this model was that to the customer, we would always present a time slot of an hour instead of a specific time. This meant that instead of having to find a doctor to make the call at the exact specific time, we had a whole hour to find a doctor and make him/her consult the customer.

With the pool of doctors we had and the number of doctors that were active during specific times of each day, we got the average doctor response time down to less than 5 minutes. This, coupled with a time slot of an hour meant that we hit the consultation match rate at 98%. This was a clear case of under-committing and over-delivering on the promise which always held the customer satisfaction SLAs high.

This model, as we discovered later also had certain business-level benefits, which shall be discussed in later parts of this case study.

Feedback

After a month of launching consultations, we started to collect and analyse qualitative feedback from the users. We segmented this into two types: users who have successfully booked a consultation and users who had dropped off in the process of booking a consultation.

For the users who had successfully booked a consultation, we accessed the consultation call and listened to the calls. For the users who dropped off in the process of booking a consultation, I called them within 24 hours of dropping off; with help of a customer service agent and probed them on their drop in the middle of booking a consultation.

Most quotes from the probe calls more or less fell into the following categories:

“I could not see doctors anywhere” “I wanted to consult a gynaecologist, but I did not know how to do it” “I didn’t understand where to go to the doctor” “Where are my medicines?” “I wanted to order medicines, but did not have a prescription” “I was just checking out the application” “I did it by mistake”

We observed that a significant proportion of users cited phrases that more or less meant either the first or second phrase from the aforementioned list. These phrases essentially boiled down to represent an expectation of the user to know more about his / her doctor before booking the consultation and to specify or book a doctor of a specific speciality.

Apart from these users, a majority of Medlife’s returning users confused our paid consultations with parallel free consultations that were pushed for users who had a need for medicines, but no legally valid prescriptions to place the order against. A quick solution was prototyped, tested and deployed for this.

A chunk of users were just explorers of the application who had no intention of booking a consultation.

User segmentation

At the same time, we refined the business strategy for the second run of teleconsultations and according to both the calls reviewed and an analysis of user types in the market, we segmented the user base into 4 segments:

Explorers Health-conscious seekers Chronic patients Doctor loyals

Insights

From the feedback obtained from reviewing calls and interviewing final stage dropouts, it was clear that users had an expectation of knowing their doctor or choosing their required speciality before booking a consultation. A part of this also matched the use cases obtained via the initial validation study.

Consultation V2

The service model conundrum

The new set of requirements meant that we had to flip back to a different service and hence business model. This model would be more doctor centric and that meant onboarding doctors the majority of the customers desired. This meant that the commission Medlife made from the transaction was minimal as the transaction going through primarily boiled down to the demand of a particular doctor. This also leads to a clear case of polarisation among the doctor base we would have, with 20% of the doctors having 80% of the bookings and the remaining 80% eventually dropping off the platform due to unsatisfactory numbers. We had observed this from an earlier pilot we had conducted of providing doctor appointment management in the Medlife consumer application.

Another problem in this model stemmed from the fact that most doctors worked on their own schedule. In the earlier pilot we floated to test in clinic doctor appointments, we noticed a significant lack of punctuality from the doctors’ side. This happened as a lot of doctors did not have personal assistants and often overbooked their calendars. A lot of doctors also accepted last minute special cases or surgeries, which meant that our time compliance SLAs went for a toss. This was one of the main reasons we shifted from handing out appointments at exact times to giving out one-hour long time slots for customers to visit a doctor. This significantly helped our SLAs and customer satisfaction, but the problem of a doctor going AWOL still remained. In addition to this, there was always the problem of the doctor slot non-availability, which we could not solve.

In contrast to that, our current service model ensured higher doctor punctuality as the request was essentially floated to a set of 10 doctors and whoever would accept the request first would get the consultation on a first come first serve basis. If none of the doctors accepted the consultation in 5 minutes, the request would be floated to a different set of 10 doctors. This meant that in an hourly timeslot that we give out to a customer, the request essentially goes to almost 120 doctors and this ensured higher compliance of time from the doctor’s side. This also removed the calendar problem from the equation as requests would only be floated to the doctors who are active at that point in time and are available to take a consultation at that particular point in time; without any scheduling needed.

In addition to being more customer-centric, this model also ensured higher satisfaction of both doctors and customers as doctors who logged in almost always received requests and customer SLAs were fulfilled with a staggering rate of 98%. The customer was always allotted a doctor in the timeslot that was booked.

Another advantage this model had was that of being more financially profitable to both the customer and Medlife. For this kind of a consultation, Medlife charged a standard fee of 150 rupees from the customer; irrespective of the doctor being assigned in the end. The commission we earned out of this would be constant. The new model would completely depend upon the price a doctor wanted to float for his / her consultation and the averages were around 500 rupees, as opposed to 150 rupees. The commission Medlife earned from the doctor centric model would also pale in comparison to the customer-centric one.

After much deliberation, we decided to pitch both the models against each other in the upcoming version of the product and let our users answer the question for us. This meant that the design had to accommodate and solve for the confusion that would occur in the minds of users when presented with more than one way to achieve the same task. After multiple iterations and constant testing with users, we came up with a design that clearly conveyed this fork to the users and helped them make an informed choice.

From the user research done after V1, we noticed that there were clearly some concerns about the credibility of doctors that would be assigned to a consultation from the older model. To work around this, we included a gallery of doctors and their credentials to accelerate user trust in the model.