Rapido Captain Rejection

Most ride-hailing apps tell you they are searching for a driver.

Rapido tells you how many drivers have already rejected you.

At first glance, this feels like a strange product decision. Why would a company expose something that potentially creates friction and highlights a negative experience?

The answer becomes interesting when you look at it through the lens of product psychology.

This is not just a status update. It is a behavioural design mechanism.

Transparency as a Product Feature

Traditionally, ride-hailing platforms hide most of the matching process.

Users see a loading screen, a spinner and a message saying that nearby drivers are being contacted.

The process feels like a black box.

Rapido changes this by exposing information that users were never previously aware of.

"66 out of 193 captains rejected your ride request."

Suddenly, the user gains visibility into what is happening behind the scenes.

This creates a feeling of transparency.

Even though the information itself is not necessarily positive, it gives users context. The app is no longer failing silently. Instead, it is explaining why finding a ride is taking time.

That subtle shift matters.

The Kano Model Perspective

This feature immediately reminded me of the Kano Model, a framework I first came across while reading The Lean Product Playbook.

The Kano Model explains how user expectations evolve over time.

Features generally fall into three categories:

• Delighters.
• Performance Needs.
• Must Have Needs.

Delighters are unexpected features that users never asked for but genuinely appreciate when they see them.

Performance Needs are features users actively use to evaluate a product.

Must Have Needs are basic expectations that users assume will always exist.

The interesting part is that features rarely stay in one category forever.

Over time, user expectations evolve.

Delighters become Performance Needs.

Performance Needs eventually become Must Have Needs.

Why This Feature Starts as a Delighter

The captain rejection counter feels like insider information.

Most users never expected to see how many drivers declined their request.

That is precisely why the feature stands out.

It creates a sense of transparency and gives users access to information that was previously hidden.

Users suddenly gain a deeper understanding of how the marketplace operates.

Instead of thinking:

"The app is not finding a driver."

They begin thinking:

"Drivers are choosing not to accept my ride."

The distinction is subtle but important.

The responsibility shifts from the platform to the marketplace dynamics.

Behaviour Shift Happens Next

The real value of this feature is not the transparency itself.

The real value is the behaviour change it creates.

Once users repeatedly see rejection counts, they begin to understand the relationship between demand, supply and pricing.

A ride with a high rejection count signals scarcity.

Users start learning that waiting longer may not necessarily improve their chances.

They may choose to:

• Wait longer.
• Increase the fare.
• Add a tip.
• Accept surge pricing.

The platform never explicitly tells users what to do.

The information itself influences behaviour.

This is a much more powerful design approach than directly asking users to pay more.

From Behaviour Shift to Pricing Acceptance

Over time, users begin associating high rejection counts with difficult-to-fulfil rides.

This changes how they perceive pricing.

Instead of viewing surge pricing as an arbitrary increase, they begin to see it as a market response.

The rejection counter provides context.

That context makes higher prices feel more reasonable.

The journey looks something like this:

Transparency → Behaviour Shift → Pricing Acceptance

This is where the feature starts moving from a Delighter into a Performance Need.

Users begin relying on the signal to make decisions.

The information becomes part of their mental model of how ride-hailing works.

The Risk of Removing It

Once users become accustomed to this level of transparency, removing it becomes difficult.

The Kano Model predicts exactly this outcome.

What started as a pleasant surprise eventually becomes an expectation.

If Rapido were to remove the rejection counter tomorrow, many users would feel that information was being hidden from them.

The absence of the feature would create frustration even though users managed perfectly well without it in the past.

This is one of the most fascinating aspects of product design.

Features do not simply create value.

They reshape expectations.

What Product Managers Can Learn

• Transparency can be a powerful behavioural design tool.
• Users often trust products more when they understand the underlying process.
• Small informational features can influence decision-making without explicit nudges.
• Delighters eventually become expectations if users find them valuable.
• Great product design often changes behaviour rather than forcing it.

Final Thought

Most people see the captain rejection counter as a status update.

I see it as a behavioural design mechanism disguised as transparency.

The feature teaches users how the marketplace works, changes how they think about supply and demand, and gradually influences how they respond to pricing.

That is what makes it interesting.

The rejection count is not the product.

The behaviour change it creates is.