I spent 6 hours waiting for my Uber. This was avoidable. Here’s how.

A few months ago, some friends and I left a music festival in the Vegas desert at 2 AM to get a ride back to our hotel. We left 30 minutes before the last performance to beat the crowds to an Uber, hoping to snag a car before the networks jammed and the prices surged. As we exited the venue, we joined the small trickle of people who had the same idea as us — the early bird gets the Uber.

As it turns out, the early birds were wrong. We were not matched with an Uber for another 90 minutes and were finally seated in our Uber at 8 AM! During this painful wait, we watched hundreds of people who left after us get into hundreds of Ubers, while our car waited in the traffic that was the outcome of a venue unprepared to handle such an influx of pickups.

I believe that the underlying issue of our night-long wait was that Uber matchmaking algorithms are not suited for high-volume pick-up venues, a problem that exists in any situation involving large numbers of requests in concentrated amounts of time such as airports, rallies, sports stadiums and concerts. And I believe a few matchmaking improvements to special-case venues could dramatically improve the overall user experience of ridesharing.

Today, Uber’s matchmaking algorithm is optimized for a dispersed set of passengers located over a large area. The objective of this algorithm is to match a passenger with the closest available driver to the user, at the time of the request, based on the availability of drivers on the streets.

When this real-time matchmaking is applied to venues, it performs inconsistently. In certain situations, such as my experience in Vegas, it can penalize the user who requests a ride before the market has stabilized and then locks the user into the sub-optimal match, while giving subsequent users the benefit of a closer vehicle.

Image for post
Image for post

To illustrate, when Al is the first to request a car in a sparse market, he is matched with a vehicle that is 30 minutes away. When Kim requests a vehicle some time later, the demand has brought more cars out on the streets and she matches with one 15 minutes away. By the time Sana is calling an Uber, she is able to find a vehicle minutes away. Additionally, now the congestion around the venue sets Al’s vehicle out by much longer than the original estimate.

Conventional taxis cabs do not experience this problem for venue pick-ups because they practice different principles of matchmaking -

  1. First-in-first-out (FIFO): The first passenger to queue up gets the first available taxi-cab. If there are none available at the request time, the FIFO principle still holds as the supply catches up to demand, so that early comers still have an advantage.
  2. Demand anticipation: Cab drivers have tribal knowledge of demand spikes at venues, and will therefore anticipate the need at stadiums, concerts and airports, and be present to service it. This knowledge might come from familiarity of ongoing events or passengers sharing information during drop-offs.
  3. Queuing systems: Cab drivers will self-regulate into a queue outside hotels, airports, train stations (if they don’t, the other drivers will put the errant driver in place). This keeps the traffic flowing and due to FIFO rules for passengers, the stream of cabs driving into the queue will be offset by the stream of cabs driving off with passengers.

All three principles that work for cabs can easily be put to work and optimized for ride-sharing apps at venues.

For the purposes of this solution, I assume that venues have been preidentified manually (airports, train stations, hotels) or through machine learning models that process real-time drop-off and pick-up data to identify congregations of people (concerts, parades, rallies).

First and foremost, the most effective change to improve venue pickups would be to abandon driver-rider matching at ride request time. Instead, users would be given a number to represent their place-in-line along with a best-guess-time estimate of the closest vehicle for their position in the line.

Image for post
Image for post
Delaying rider-driver matching to implement FIFO

While riders would be given positions in the order they were received, the driver ranking would not be linear. Drivers would be prompted to start driving towards the venue, but since their travel time is subject to distance and traffic, their position in the queue would be determined when they were close to the venue. When the drivers arrive at the venue, the top of the riders’ queue would get their respective driver information. This way, the first drivers who get to the venue would leave with the first passengers who requested the ride.

The second optimization would be to move away from real-time matchmaking on the driver side of the equation. Today, drivers are not prompted to drive to a location unless they have been paired with a user requesting a ride. Obviously, with traditional Uber rides, the pick-up points are not predetermined so drivers have to wait till a ride is requested. However at venues, the pick-up point is known and reasonable estimates can be made to anticipate demand volume and times thanks to drop-off data.

For example, if there were 500 drop-offs at the Centurylink Stadium at 6 PM, it is known that ~500 pick-ups will be requested at the same location in 3 hours. This data can be used to direct drivers towards the location before the rides are requested (The few drivers who are unmatched when demand is overestimated would have to be reimbursed).

Another aspect of this demand anticipation would be to anticipate congestion and pick-up chaos. Therefore instead of mapping the driver to the Google Maps’ identified generic pick-up point, the drivers would be directed to a specific location at the venue and create a queue of waiting cars. This would align with our objective to institute the FIFO model of passenger pick-ups.

Image for post
Image for post
Anticipating ride demand and congestion

Finally, a surge in rides requested without a corresponding supply of drivers should be met with an UberPool-only regulation. While this might lead to some lost revenue and a few miffed users, it is in Uber’s interest to service as many customers as possible as quickly as possible. The user time saved in waiting for a car will offset the additional time lost in an UberPool.

A waiting rider is a lost rider.

Image for post
Image for post

Today Uber has access to the data and real-time modeling power to implement these suggestions and make experiences with high volume pick-ups a lot smoother. The number of transactions and the opportunity to capture the market from traditional cabs and public transport at venues makes this investment worthwhile.

Most importantly, I do not want another night in the Vegas desert waiting for my Uber.

Written by

Uber Product | ex-Microsoft | ex-Startup | Book Worm | Feminist | Bollywood connoisseur

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store