Background
A car-hauling truck may carry several cars at once, often for different customers. To fill a truck, dispatchers look at online marketplaces. In short, a dispatcher must:
Make sure the trip, once complete, will be on a profit.
Fill all spots on the truck. Each mile passed with an empty spot is money left on the table.
Avoid long detours for pickup and delivery stops.
Avoid idle waiting at busy locations or arrivals outside working hours.
The problem
If you think successful trip planning requires experience and is not always guaranteed, you'd be right.
Most dispatchers plan trips in a spreadsheet, keeping a browser tab open for each marketplace and mentally tracking the stop order. As a result, the planning happens outside our system, which is a missed opportunity for us to tap on their data.
Knowing where and when carriers had free space could let us match their capacity with the loads supplied by the shippers on our marketplace.
We did many interviews and shadowing sessions to study how a dispatcher prepares a trip. We discovered that each dispatcher had developed a different system specific to their habits. Changing habits is hard, so we needed to give them a compelling reason to alter their methods.
What we built
Route optimization. Dispatchers could automatically arrange all pickup and drop-off stops added to a trip in the most efficient configuration, maximizing profit per mile.
Capacity timeline. We made it very clear where a truck is underutilized or overbooked.
Alerts for the gaps. Optional email notifications for when a new load fitting an empty spot is posted to the market.
Fit check before booking a load. Dispatchers could add a load they found elsewhere as a draft and see if the new total distance, time, and earnings add to the profitability.
Impact
For dispatchers: a trip is planned in one place instead of a spreadsheet, a row of browser tabs, and their memory.
For shippers: a new load can reach dispatchers whose trucks have free space on that route.
For the business: carriers had a reason to add their own loads to our system. This was healthy for our data pool and usage-based billing.
Strategically: we learned where carriers had free space, and when, which is what a marketplace needs to match supply with demand.
To know whether the planner helped, not just whether it was used, we tracked whether reordering changed the order of stops, the average number of empty spots per completed trip, and how often gap alerts were opened and clicked.
After launch
Adoption was slow at first. The first version required quite a few steps before the system could give anything useful back to the user.
We have built a better way to set the trip’s origin and destination, which let us integrate with Google's new (at the time) Routes API, eliminate the friction points and significantly reduce the time-to-value.
What would I do differently next time
All I can share is that I eventually realized creating a trip was not the end goal. It was an accounting unit, which meant different things depending on the context, and on its own could have been a much simpler feature.
Next case study