What are your solutions to reduce the car cancellation rate on the Uber waiting page?

Uber is a market place, let’s try to understand the cancellations from both riders and drivers perspectives and then find an optimal solution. 

In general, cancellation is a poor experience from both riders and drivers. Let’s First understand the cancellation metric -

1. # of cabs booked successfully but cancelled after that by either drivers or riders.

Assumptions - 

1. Scope - Only tier I and tier II cities

2. Time period - Daily

Probable Cancellation Reasons - Recently, cab cancellations have increased significantly, and this is happening due to multiple reasons. Let’s list down a few of them -

1. Due to more demand for cabs during a certain time period of a day, less number of cabs are available.

2. Higher wait time for the ride

3. Pick-up location is at a longer distance from the current location of the driver 

4. Higher price for the ride, user might compare the price at competitor’s platform causing cancelling the cab

5. Lower price for the ride, driver might not accept due to lower total earning

6. Drivers & riders altercations on pick-up locations could cause a cancellation - low ratings by both could be used as a proxy to measure this

7. A few pick-up locations in certain areas can lead to cancellations (narrow roads etc.) 

8. More traffic/congestions in cities (especially tech parks) can lead to more cancellations

9. Strict traffic rules, no parking zones, traffic challans can lead to cancellations

10. Less number of cab hubs due to crowded city areas, drivers might cancel if the hub is far from the pick up location.

11. Easy to cancel the cab by just a click upfront available.

Solution Strategy (Prioritised) - Given the presence of multiple solution strategies and the uncertainty regarding which will be most effective, we should initiate this process with a series of experiments to evaluate their potential.

1. Analyse data based on the drivers & riders ratings, whether this is frequent with specific groups of drivers and riders.

2. Incentivising the drivers properly, implementing surge pricing. However, we should implement this via an A/B test experiment, since it should not harm the riders sentiment as well. (Define test and control groups for the same)

3. Move the cancellation button towards the bottom, again this should also be implemented via an A/B test. (Define test and control groups for the same)

4. Implementing a "guaranteed arrival time" feature.

Success metrics measurement -

1. For Solution Strategy 1, it is essential to identify the specific groups and take appropriate actions.

2. Implement Surge Pricing in Phases: Introduce surge pricing gradually in regions where cancellation rates have decreased (higher number of successful bookings) align with drivers availability.

3. Feature Implementation: Assess the impact of cancellation rate reductions by moving the button to the bottom (post 1 scroll).

4. Similar analyses can be done for solution 4 as well.

1. Sizing: Though this step is not relevant for case question, but a good PM should always start with the first step:

• Size the problem and ensure this is the right problem that needs to solved, now. Why does this need to be solved now? What is the $ opportunity cost of not solving this?

2. Understand the problem in bit more depth: 

• Cancellation profile: Rider Vs Driver driven. 
• Geography profile: is this issue happening more in cities or suburbs?
• Trip & Map Profile: happening for what kind of trips? coming back from work OR during weekend late nights OR going into work OR going to Airport etc -- understand the profile of the trip. Would assume this happens a lot during surge, when there is ride competition. Would also assume most often this is happening due to two reasons 1. short trip and 2. direction is not popular
• Rider Profile: Happening more with working professionals, students, weekend revelers, Higher Vs Lower LTV customers, does it mean the same thing if happens for deeply engaged Vs new Vs newly re-activated user -- differing loss in value to platform if the transaction fails based on customer segment
• Driver Profile: Similar to riders, examine if happening with new Vs deeply engaged Vs newly re-activated drivers
• Time Profile: assuming this happens more during peak hours. any more insight on time is available?

• Weekday work warrior Dave
• Outgoing weekend chilled out dude Amit
• Tinder dating warrior Samantha 

• Live 100 miles outside uber zone, fast buck Chowdhary
• Passionate about community and driver ratings Xiao

Also for this excercise, let's pick Driver initiated cancellations (assuming this is the more acute part of problem)

• Gamification: Reward drivers if they complete a streak of 10 un-cancelled bookings
• Hide destination from Driver, until ride is picked up
• Penalize cancellations post ride booking -- e.g. every second driver initiated cancel will cost the driver $3 etc
• Increase "hold time" of booking so that algorithm can create a higher confidence match

 5. Prioritization: First two solutions above are high reach and impact and will deserve priority

First of all, I'd like to start by defining what is Uber. 
I'm assuming this time we are talking about Uber ride-hailing service and not other services such as Uber Eats. The interviewer says yes.

Then I'm going to define the Uber ecosystem. And assume the geography is India.
Uber is an on-demand ride-hailing service, where a rider can request a cab and that request is sent to all the available drivers nearby. This request is sent to the drivers based on some matching algorithm, driver can accept or reject the request. If the driver rejects the request then the request is diverted to the next driver based on the score from the matching algorithm.

Confirm with the interviewer if the understanding is correct. They agree to it and move on. 

There are a few clarifying questions I'd like to ask following this. First is the waiting page, there are two scenarios

• The user has requested a cab and that request goes to the driver and then the driver accepts or rejects the request, 

The user has been allotted a cab and on this screen, the user would see the driver's location, along with the estimated time of arrival and waiting time

• The third scenario, unlikely, the booking was canceled due to a server issue which is at the backend

• What's the average wait time of the user here after they are allotted a cab, the average wait time of the user has increased or decreased, what's the trend?
• Cancellation on the waiting screen is user-triggered or driver-triggered? What's the breakup and how has that trend been?
• If the majority of cancellations are triggered by the driver, what's happening here, what is the behavior?
  • Is it across some drivers or all drivers?
  • Is it across geography or generic phenomena?
  • Which cab category sees the maximum number of driver cancellations?
  • What was the original time that was shown to the driver when they accepted the booking?
  • What was the time remaining when the cancellation was triggered?
  • Are maximum cancellations happening when the driver accepts the ride in the first few seconds or are they happening when a driver has started and then had to cancel or the driver reached the destination and is near (rider's pickup point) and then cancellation is triggered?
• How is the retention for the riders whose rides were canceled, are they making another set of bookings or they are going away with the competition? This will help me understand the impact of the problem, basically how big is the problem.
• Are the cancellations happening in the peak hours or lean hours?

• Maximum driver cancellations happen in the first minute after accepting a booking
• For users who face cancellations, we observe low retention
• Driver cancellation is a more common phenomenon than customer cancellations and hence it makes sense to prioritize driver-related issues here.
• The cancellation is happening across peak hours mostly
• This is happening for all the drivers across all the geography

• The motivators need to be played around with, motivators are basically the user's pickup point, net earnings from the ride, destination of the rider, and time to reach the pickup point. See what motivators work best here, can plan a few A/B tests around the same.
• The traffic conditions are not allowing drivers to reach a particular destination and hence they cancel the ride
• The driver is not willing to go to a particular destination and hence they are canceling
• The matching algorithm can incorporate a few signals or variables or introduce additional variables during peak time to optimize for cancellations. This can also be an A/B test scenario.
• One aspect could be penalize drivers after they have done x amount of cancellations
• Limit cancellation and give only x no. of cancellations to a driver per week
• Incentivize driver that don't cancel beyond x no. of times

Product description:
Uber is basically a service which allows people to commute & essentially, following the booking of a ride, there is a significant occurrence of cancellations on the Uber page, particularly when displaying the estimated waiting time on Maps
 

Clarification questions:

1. Is this occurrence affecting all user types, including new and returning users? Let's assume it does, for our discussion's sake. Both new & returning users could potentially experience this issue but I'll choose to focus on returning users and it appears to be more prevalent among returning users & new users generally have a clearer understanding of the service, leading to more accurate suggestions & activation is done recently 

Interviewer: Your call, you can pick any or both

2. Given that Uber has ample resources, can we assume that resource and financial constraints are not significant factors contributing to this problem?

Interviewer: Yes

3. Are we observing the same issue on both Android and iOS platforms? Assuming it is a widespread problem that occurs globally and regionally.

Interviewer: Yes
 

4. Assumption: Considering that cancellations are happening on the waiting page, can we assume  that these cancellations are initiated by riders most of the time rather than drivers?

Interviewer: Your call 



Objective: 

Categorizing the user set based on AAAERRR (Awareness, Acquisition, Activation, etc.). In this case, it doesn't seem to be primarily an issue related to Awareness, Acquisition, or Activation, especially since we are discussing returning users. For the current situation, I am focusing on improving user engagement as the primary objective, as addressing this aspect could potentially resolve the issue and, consequently, improve revenue in the long run.

Top User Groups:

Individuals

1. Individuals commuting to and from educational institutions (e.g., college or school).
2. Individuals commuting to and from their workplace or meetings.
3. Individuals needing transportation to healthcare facilities, classes, and similar destinations.
4. Individuals making bookings on behalf of others.

Corporates

1. Corporate users utilizing a company account for commuting to their office or attending meetings.

User Journey:

1. Launch the Uber App.
2. Enable GPS (if not already active).
3. Automatically detect the user's current address.
4. Input the desired destination.
5. Confirm and book the ride.
6. Access the map screen displaying the estimated time of arrival for the driver.
7.  Monitor the distance of the driver from the user's location, as some apps may provide this information while others may not.
8. Communicate with the driver to confirm their arrival status.
9. Check the real-time movement of the driver on the map if they have confirmed their intention to pick up the rider.
10. Consider canceling the ride in case the driver declines, the estimated arrival time is excessive, or the driver remains stationary.
 

Pain Points:

1. Extended wait times displayed on the map for the driver's arrival.
2. Unintended driver inactivity (lack of movement).
3. Driver refusal to proceed with the pickup.
4. Customers discovering quicker ETA options from rival ride-sharing services.
5. Observing faster and more active movement of other types of cab types within the same app.
 

Solutions:

1. In instances where a customer contemplates canceling due to extended waiting times, we should display an estimated time for the next available cab of the same type. This would involve conveying a message to the user to discourage immediate cancellation, by engaging with this info

2. When a driver remains stationary, and a customer considers canceling, we could implement a feature that shows the driver's pickup success rate as a percentage. For example, "This driver typically successfully picks up 95% of rides on the first attempt and is on time 95% of the time." This information could help customers understand if the driver is likely facing traffic or technical issues, thereby encouraging them to delay cancellation by engaging with this information.

3. When a driver declines to pick up through chat or call, we can analyze the conversation and identify keywords such as "cancel." We can then promptly assign a new driver while retaining the same Order ID. This backend process ensures a smoother transition to a new driver.

4. If none of the aforementioned reasons apply, and a customer is considering cancellation, we can inquire about the reason for cancellation. If the customer mentions finding a faster ride with a competitor, we can switch the cab to an alternative type of cab with the shortest estimated time of arrival. Although this approach may reduce cancellations, it may impact profit margins.

5. We can establish partnerships with grocery delivery apps, task management apps, and gaming apps to offer users alternative activities during extended wait times. For instance, if the waiting time exceeds 10-15 minutes, we can suggest adding groceries via Uber or engaging in in-app activities. This integration would require collaboration with these external apps such as Zepto, Swiggy, Online cricket, etc

Prioritisation:

Summarizing the features based on RICE prioritization:

| Feature | Reach | Impact | Effort | Priority |

|---------|-------|--------|--------|----------|

| 1       | High  | High   | Medium | P0       |

| 2       | Medium| Medium | Medium | P1       |

| 3       | High  | High   | Medium | P0       |

| 4       | High  | High   | High   | P2       |

| 5       | High  | High   | High   | P2       |

Priority Legend:
P0: High Priority
P1: Medium Priority
P2: Low Priority

Please note that these priorities are based on the RICE framework, with the reach, impact, confidence and effort factors considered.

Metrics:
 

Can anyone pls review this? Would be great if I can have your inputs