The sharing economy has introduced a new wave of online marketplace apps and business models, where consumers and sellers are matched across a unique differentiated set of product inventory. This contrasts with traditional e-commerce platforms, where inventory is standardized and sellers are few. Online multi-sided marketplaces range from Uber and Lyft in gig-economy transportation of people with unique routes to DoorDash and Postmates in restaurant delivery with unique orders, Instacart and GoPuff in grocery delivery with unique pick-up and drop-off locations, TaskRabbit and Amazon Mechanical Turk with unique ad-hoc jobs, Turo and Boatsetter for individual car and boat rentals, Airbnb with unique one-of-a-kind accommodations, and Rover for dog care.
Each of these businesses has successfully created a marketplace that matches customers with a wide variety of sellers offering differentiated products or services, rather than standardized items. This creates a more complex system than traditional retail as it presents a complex optimization problem where we must balance the multiple needs across a diverse set of users - times/dates, locations, qualifications / features / amenities, availability, regional regulations, and so forth. Additionally, the rules and functioning of the marketplace need to be considered carefully to prevent gaming and ensure a fair and transparent marketplace for all parties.
In this 8-part e-book, we will design a multi-sided online marketplace encompassing multiple domains, subsystems, and applications, with principles which can be applied to a wide variety of marketplace and gig-economy use cases from taxi services (e.g. Uber, Lyft), to restaurant delivery (e.g. DoorDash, Postmates), to third-party deliveries (e.g. Instacart, Shipt, Convoy). We’ll focus on a complex three-sided marketplace use-case involving three distinct sets of users: customers making purchases, third-party vendors, and gig-economy drivers. By the end we will have designed a global transportation platform with multi-sided marketplace where (i) consumers can shop through a variety of vendors (3rd-party merchants or taxi services), (ii) have their goods or themselves delivered quickly – as quick as same-hour, (iii) by gig-economy drivers, (iv) either scheduled-ahead or on-demand, (v) all without merchants or taxi companies managing any of the logistical complexity.
We must balance: speed, low-cost, and accurate-ETA’s for customers; consistent, highly-available taxi & delivery services for third-party merchants and taxi companies; and fairness, transparency, and consistency for gig-economy drivers. The platform will support a wide range of transport speeds starting as quick as same-hour with low latency APIs to optimize the checkout flow for maximum conversion. We will support multiple pick-up and drop-off locations, given products and customers will be distributed. Finally, we will support multiple mechanisms for gig-economy drivers to obtain work, either scheduling work ahead to guarantee sufficient working hours or working on-demand with maximal flexibility, obtaining work in real time.
- Part 1: Introduction, Requirements, Mobile and Web Applications
- Part 2: Backend Infrastructure and Service Architecture
- Part 3: Vendor Management and 3rd Party Customer Shopping & Checkout
- Part 4: Transport Supply & Demand Management and Forecasting with Machine Learning
- Part 5: Route Planning, ETAs, and Dynamic Pricing with Machine Learning
- Part 6: Driver Onboarding, Preferences, Standings, Rewards, and Payments
- Part 7: Driver-Route Targeting, Pushed On-Demand Routes, and Precomputed Eligibility
- Part 8: Gig-Economy Route Marketplace for Schedule-Ahead Routes with Deferred Route Matching
Part 8: Gig-Economy Route Marketplace for Schedule-Ahead Routes with Deferred Route Matching
Contents:
- Introduction
- Route Vending
- Route Details
- Forecasting Route Popularity
- Driver Route Request
- Driver Route Actions
- Deferred Route Matching
- Sorting Interested Drivers
- Mutual Exclusion and Eligibility Confirmation
- Assigning the Route
- Notifying the Driver
- Conclusion
Introduction
In Part 1, we envisioned a global transportation software platform enabling third-party vendors to rapidly transport goods to customers – or customers themselves – within an hour, covering requirements, web/mobile apps, and overall flows. In Part 2, we explored the backend infrastructure and service architecture. In Parts 3-8, we are going through the multitude of domains, subsystems, and services we will require. In Part 7, we started detailing the Route Marketplace domain; here in Part 8, we dive into the Driver Route Vending Service and the Driver Route Actions and Matching domain.
Route Vending
Drivers acquire new schedule-ahead routes to work through the Route Marketplace. In the Driver App routes page, drivers see a list of routes available to them to request which they have been deemed eligible for, filterable by order-type.
The Route Vending Service is responsible for providing drivers with the list of upcoming schedule-ahead routes which are available and they are eligible for.
Route Details
Each route lists transparent details on the route start-time, start location, and pay. The specific stops are not listed as the route path and stops may change between now and when the schedule-ahead multi-stop route starts as the route plan for the region is continuously optimized up until start time.
Forecasted Route Popularity
Drivers have a limited number of available routes they may request within a time horizon. Therefore, in the theme of creating a transparent marketplace, it’s important drivers can understand which routes are likely to be more sought after amongst drivers in the region. For example, a longer high-paying route during business hours may get much more driver interest than a shorter lower-paying route late at night. In addition to the route details mentioned above, drivers also see the forecasted driver-demand for the route based on similar route profiles from the past. This provides important visibility to drivers on which routes they want to request given they only have a limited number of routes they can request at a given time. All else equal between two available routes, drivers may prioritize requesting the routes which are less sought after and therefore will have a higher success rate in requesting.
Each route’s popularity is forecasted from a basic Machine Learning (ML) model which compares it against past routes with similar profiles – same day-of-week, time-of-day, order-type, region – to project how many drivers will likely be interested in the upcoming route. This model inference happens ahead-of-time, triggered when the route plan gets first generated or is later updated. The model is retrained offline monthly.
Driver Route Request
As drivers load the Driver App routes page they are presented a list of available schedule-ahead routes they are eligible for and may request. Drivers carefully select which routes are most appealing and they have the highest likelihood of getting, given each driver is limited in the number of routes they can request for a given time horizon. The list of schedule-ahead routes they are interested in is then submitted to the platform.
The remainder of this chapter is available by purchasing the e-book.
