Peak hours break the rider experience and waste driver supply
In ride-hailing, the real-time matching model works brilliantly most of the time. But it falls apart at the edges: peak hours, events, airport runs, daily commutes, precisely when users need reliability the most.
The data told the story clearly: 20% of users with concrete travel plans were failing to get a driver allocated during high-demand windows. On the other side, 10% of users were cancelling rides due to schedule changes, leaving drivers idle after they'd already committed. And 5% of users were booking the exact same route every day, with no way to automate it.
The opportunity size was 4.3 million users. 7 out of 10 surveyed users said they'd be more likely to transact with a service that offered scheduling. The question wasn't whether to build it. It was how to build it without disrupting the real-time marketplace.
Working backwards, then designing for all three sides
I used Amazon's Working Backwards framework to validate the feature before touching a single wireframe. The goal was to answer the hardest question first: should we build this at all?
- Customer: Users who drop off during peak demand, users who cancel due to schedule changes, and daily route commuters
- Problem: No ability to plan ahead: riders are fully dependent on real-time supply, which is unreliable during peak hours
- Value proposition: Book ahead, get guaranteed allocation, peace of mind for your next activity
- Business impact: 17.5% booking rate uplift + $70M annualised revenue
Once the "Go" decision was validated, I designed the solution across all three sides of the marketplace:
Rider side: A new "Schedule" CTA on the home screen that opens a date-time selector. After scheduling, the home screen updates to show the upcoming booking with the adjusted fare. A new entry in the hamburger menu gives riders visibility into upcoming and past scheduled rides.
Driver side: Scheduled bookings arrive as a distinct yellow job card: an instant visual signal that this is a pre-booked ride, not a real-time request. This reduces confusion and sets the right expectation for pick-up timing. Key metrics: scheduled booking acceptance rate and driver cancellation rate.
Marketplace side: The matching algorithm prioritises idle drivers within the scheduled booking area, improving supply utilisation without pulling drivers away from real-time demand. Both riders and drivers retain the flexibility to accept or decline.
The most overlooked risk wasn't technical. It was behavioural. If scheduling becomes too frictionless, users might shift entirely from instant to scheduled bookings, cannibalising the real-time marketplace. This was defined as a guardrail metric: monitor the ratio of instant vs. scheduled bookings and flag if instant drops below a threshold.
A/B test first, then iterate toward prediction
The hypothesis was clear: allowing users to book future rides should increase booking rate and revenue while providing peace of mind. The experiment design was an A/B test where the treatment group had access to the scheduling feature and the control group used the existing flow.
Success metrics were layered: primary (booking rate uplift, NPS), secondary (schedule completion rate, driver acceptance rate), and guardrails (instant-to-scheduled ratio, cancellation patterns).
The roadmap was designed as three iterations, each run as an experiment:
- V1: Manual scheduling: Users set date, time, and route manually
- V2: Calendar sync: Auto-schedule rides from calendar events
- V3: Predictive scheduling: System suggests recurring rides based on booking history and drop-off patterns
A look inside the full case study
Here's a preview of what's covered in the complete breakdown:
Want the full breakdown?
Get the complete case study with wireframes, revenue analysis, execution playbook, and the three-phase iteration roadmap.
- Rider & driver wireframes
- Revenue impact model
- A/B test design
- Marketplace logic
- Iteration roadmap
Trusted by 50+ product managers