Background
Our marketplace connects shippers, who post cars needing transport, with carriers who provide the transport.
The problem
Like most young marketplaces, we had a chicken-and-egg problem. Carriers go where there are many loads, and shippers stay where carriers respond quickly. We had a lower listing volume, so carriers visited us more or less as a last resort.
That mostly hurt our ability to build momentum with new shippers. If a shipper didn't receive offers on their first few loads, they'd stop posting. To stop the leakage, we needed a way to match new postings with carrier capacity within minutes.
What we tried first
Before I moved into Product, I led the Support and Success teams, where we tried doing load matching by hand. I built a dashboard that listed the carriers who had recently moved loads on a given route. When a new shipper posted, we queried the locations and called the carriers from the list.
Calls worked poorly. Many went unanswered, and by the time we reached a carrier, the truck had often already left. So we switched to email, and saw our emails' open rate is far above the average for email campaigns.
That was the signal I took into Product. Carriers would not miss load opportunity emails. We just had to make something scalable.
What we built
I teamed up with our machine-learning team and proposed the data they could use for the automated carrier recommendation engine. We have carefully crafted the requirements, so we could deliver value, not noise. The risk was that carriers might unsubscribe from the emails, which would have limited our already scarce pool of carriers.
In short:
When a load is posted, the recommender identifies carriers who recently searched for or moved loads on that route.
It ranks them by… well, that's a secret sauce.
Then only a limited number of the top-ranked carriers get notified.
The key to the UX:
Nobody sets anything up. It works off the data from basic usage.
Self improving recommendations.
Impact
For shippers: each load reaches the carriers with the highest probability to take it, instead of waiting for carriers to look for it.
For carriers: they hear about loads fitting their criteria as they are posted.
For the business: better hit rate meant higher engagement, satisfaction and retention on both ends.
Strategically: being able to see how carriers react to job offers gave us real time data on the market dynamics.
After launch
Oops! While testing the recommender, we looked whether it recommended the correct carriers to each load individually, viewing it from the load's perspective. We didn't test what a single carrier receives across all loads. On day one, large carriers working routes across the country had their inboxes flooded. Thankfully, this was a quick fix.
Over time, we rolled out numerous optimizations until the improvements began to yield diminishing returns. We then deemed the performance satisfactory and switched gears to maintaining its quality.
What I learned
The recommender engine asked carriers for nothing. Their searches and past moves already described the loads they wanted, so the recommender could work from data we already had.
I’d look for this anywhere a product makes users describe what they want through their actions.
Next case study