The ride that exists, but doesn’t
When “12 captains nearby” doesn’t mean you can actually get a ride. I investigated the gap between visible supply and successful fulfilment in ride-hailing, and designed a way to close it.
- Product
- Rapido
- Domain
- Mobility marketplace
- Role
- Self-initiated
- Focus
- Matching & pricing
7:15 PM
An employee leaves work and opens the app. It shows 12 captains nearby. She books. “Searching for captain…” Thirty seconds pass. Nothing. The number changes to 14 captains nearby. Another thirty seconds. Nothing. Then: “Add ₹20 for faster acceptance.” She does. Still nothing. The fare rises again. A captain finally accepts.
She gets home. The experience has already failed.
The marketplace communicates the presence of supply without communicating the probability that the supply will actually serve the customer.
The gap between perceived availability and actual availabilityWhy this is hard
Ride-hailing has a structural problem: demand is controlled by customers, but supply is controlled by independent captains. A platform can have thousands of captains online and still fail to fulfil a request.
Rapido states it has more than 3.4 million active captains across 100+ cities. Scale alone does not guarantee serviceability. A captain can be online, nearby, technically available, and still be unlikely to accept a particular request. It bites hardest at office closing hours, in rain, during metro disruptions and around major events.
What I could and could not claim
Public user discussions contain multiple reports of customers unable to get rides at displayed fares and being prompted to pay more. One 2025 report quoted the in-app message: “Captains aren’t accepting at ₹30. Try adding more.” There are further 2026 reports of rides completing only after additional payment.
That is a qualitative signal, not evidence of prevalence. I would not claim a percentage of Rapido rides have this problem without platform data. The honest position is that public reports make it worth investigating, and the first job is to quantify it.
Given access, I would validate through commuter interviews, captain interviews, ride-request observation, and cancellation, fare-versus-acceptance and time-of-day analysis.
Two definitions of the same word
What the platform counts
Available supply equals the number of nearby online captains.
What the customer experiences
Available supply equals the probability that I can successfully book a ride.
Why it matters
These are not the same metric. Optimising the first can leave the second untouched.
So I reframed the question. Not “how many captains are nearby?” Not even “how many are realistically serviceable?” but: what is the probability this customer gets a ride within the promised time and price?
The hypothesis
If the platform predicts the probability of successful fulfilment instead of exposing raw captain counts, and matches on acceptance probability, it can cut search time and cancellations while improving trust and captain utilisation.
Matching on the right thing
A captain does not optimise for number of rides. They optimise for earnings per hour, low dead kilometres, a desirable destination and easy pickup. So “online” does not mean “willing to serve”. A proximity-first algorithm picks the nearest captain. That is often the wrong one.
Acceptance probability, against distances of 0.5 km, 1.2 km and 1.8 km respectively. Proximity-first picks Captain A. The objective is not to find the nearest captain, it is to find the most likely successful match, subject to an acceptable arrival time.
The score would draw on captain signals such as historical acceptance rate, earnings per hour, preferred destinations and shift duration; request signals such as pickup distance, destination, traffic and fare; and marketplace signals such as current supply, predicted demand, local events and weather. The exact formula would be validated experimentally rather than hard-coded.
Where price belongs
If captains keep rejecting a ride, the easiest answer is to raise the fare. But the customer sees ₹120, then no captain, then ₹140, then no captain, then ₹165, then acceptance. They learn that the platform will not serve them unless they keep paying. That buys short-term fulfilment with long-term price trust.
- Better matchingTry captains with higher acceptance probability first. Costs nothing.
- Expand the radiusSearch additional eligible supply before touching economics.
- Reposition supplyOffer nearby captains a reason to move toward the demand zone.
- Captain-side incentiveA targeted incentive, where it is economically justified.
- Transparent customer pricingRaise the fare only when necessary, and say plainly why.
Price should be an intervention, not the default solution.
How it fits together
The engine sits between the request and the match, and the intervention ladder runs cheapest-first.
What the customer would actually see
Instead of “12 captains nearby”, show serviceability.
High availability
Pickup in about 3 minutes. ₹130.
Moderate availability
Pickup in about 5 to 7 minutes. ₹130.
Low availability
Pickup may take 8 to 12 minutes at ₹130, or about 3 to 5 minutes at ₹150.
And for people whose time is worth more than ₹20, a Reliable Ride tier: a higher probability of acceptance at a stated price. Customers are not only buying transport. They are buying predictability.
The metric
The North Star is successful ride fulfilment rate: the share of requests that end in a completed ride within the promised time and accepted price. That is stronger than acceptance rate, captains online or average fare, because it is the customer’s actual outcome.
Alongside it I would introduce false availability rate: the share of requests where the platform indicates sufficient supply and then fails to deliver within the promised window. That measures the trust gap directly.
Guardrails matter as much: customer price inflation, captain income volatility, unfair matching and safety incidents.
How I would test it
Replace the count
“12 captains nearby” against “high availability, pickup in 3 to 5 minutes”. Measures conversion, abandonment and repeat usage.
Acceptance-aware matching
Nearest captain against highest predicted match probability. Guardrail: captain earnings per hour must not deteriorate.
Smart intervention
Immediate fare rise against the full ladder. Tests whether price is actually the best lever.
Reliable Ride
Not “do customers like it?” but “will time-sensitive customers pay for reliability?”
Shipping it
I would not build the whole system at once. Phase one predicts fulfilment probability from existing data. Phase two uses the score in matching. Phase three changes customer-facing messaging. Phase four adds targeted captain incentives. Phase five tests Reliable Ride.
Rollout starts at 5% in selected zones of one city, watching fulfilment, arrival times, price, captain earnings and cancellations. Then 25% across peak-hour zones, 50% with the customer-facing availability messaging, and 100% only once guardrails hold. The first segment is peak-hour time-sensitive commuters in dense urban zones.
What could go wrong
- The prediction is wrong. If the app promises high availability and nobody accepts, trust gets worse, not better. Conservative predictions and confidence intervals.
- The model favours the same captains. Fairness and utilisation constraints.
- Captain earnings fall. Monitor earnings per hour and dead kilometres as a hard guardrail.
- Pricing feels exploitative. Transparency, and every other lever tried first.
- Captains game the signals. Watch for abnormal behaviour and retrain periodically.
What I would not build
A new booking interface, a chatbot, a loyalty programme, unlimited surge, or a new payment system. None of them touches the marketplace failure at the centre of this, and each would consume the team that should be fixing it.
The insight underneath
This started as “why aren’t captains accepting my ride?” The deeper problem is that ride-hailing platforms do not sell access to nearby vehicles. They sell predictable transport. Supply visibility is not service availability. Availability is not willingness. Acceptance is not fulfilment. A low fare is not a good experience.
Don’t tell users how much supply exists. Tell them how reliably the marketplace can serve them.
The product principle this case study is really about