Teaching dispatchers to trust a scheduling model
WM’s dispatchers moves thousands of routes a day. Engineers had a scheduling model ready to go, but a dispatch tool nobody enjoyed opening. My job was the layer in between, and the adoption problem quietly hiding inside it.
Lead project designer, end-to-end
1 designer, 1 PM, 6 engineers
18 months (phased rollout)
All internal ops tools (Resource center, GANTT, driver assist)
Annual cost reduction in the pilot year.
Recommendation override rate across three pilot markets.
Rollout scope once the pilot cleared its adoption gate.
An idle truck is the most expensive thing at a logistics company.
WM dispatchers plan and re-plan routes all day long for a fleet that never stops moving. Every hour of idle truck time, every avoidable backtrack, and every route that blows its window is fuel, labor, and a missed commitment, each only multiplied across markets.
The tool they did all that in was a decade behind: slow, visually flat, and so unstructured that a new dispatcher needed weeks of shadowing before they were confident or useful. Meanwhile, the data science team had a hot new model that could plan a day faster than any person could by hand.
So the brief I inherited was “add ML to dispatch.” I worked to refine that framing before design started, politely but firmly. An annoying model that dispatchers ignore produces exactly zero dollars of savings, and they had every reason to be skeptical; they were the ones getting paged when a route failed.
The engineering risk was latency. The design risk was trust. Only one of those was on anybody’s roadmap.
The pre-redesign Resource Center in all its 1999 glory.
Recommend, don’t decide.
I reframed the project around one question: what would make an experienced dispatcher confident enough to accept a machine’s plan? Maybe just as importantly, what would make them confident enough to throw it out? That reframe produced three bets, and every screen decision made later traces back to one of them.
The model advises. The dispatcher commits.
No silent auto-scheduling, ever. Recommendations show up as proposals inside the dispatcher’s existing picture of the day, one click from acceptance or dismissal.
Show the tradeoff, not the score.
“87% confidence” means nothing to someone routing trucks. “Saves 40 minutes, pushes two stops past noon” means everything. I made the model explain its suggestions in dispatcher language.
Design for the exception.
The happy path was already fine. The value was in the breakdown, the overrun, and the special-case pickup. So the interface leads with deviation and treats steady state as the quiet default.
One timeline as the shared source of truth.
The Gantt timeline became the spine of the whole product. Planning in Resource Center and live-tracking in Gantt had always been two separate mental models; putting them on one horizontal time axis meant a dispatcher never had to translate between what they had planned and what was actually happening on the routes.
Recommendations render right over that timeline instead of hiding in a side panel, with the reason and the tradeoff attached. A ticket breakdown modal splits any block into its actual time components (travel, service, wait) so a dispatcher can audit the model’s logic on the specific route in front of them rather than taking it on blind faith.
Live deviation signals travel back the other way: when a route runs long, that data returns to Resource Center as an allocation prompt, closing the loop between plan, reality and re-plan. Every pattern came out of the internal design system, which is honestly the only reason a suite this size was even remotely shippable by one designer.
This is a simplified version of the GANTT tool that you can interact with.
To test out the functionality, you can do the following;
Click on the pulsing ‘Route Optimization’ icon to deploy the overlay with suggested changes to improve route efficiency, and either approve or dismiss them
Click on individual tickets to see granular details of their duration, including the pulsing currently active ticket (and how far ahead or behind a driver is versus planned timing)
Drag the pulsing site from the top ‘Sites Bar’ into the table to see its routes populate as new rows
The rollout plan was part of the design.
We shipped the model in a hidden learning mode first; it generated recommendations nobody saw, and we compared them to what dispatchers actually did in the moment. That gave the data team a calibration set and gave me a map of where human judgment consistently beat the model, which became my priority list of exception cases to design for.
We then ran the model in three pilot markets, with the metric we focused on being override rate rather than acceptance rate. Acceptance can be gamed by making dismissal annoying; override tells you whether the recommendation was any good. Overrides fell from 41% to 12% over the pilot as I tightened up the explanation layer.
I ran the change management alongside it - walkthroughs with dispatch supervisors, a feedback path that went straight to the model team, and release notes written in dispatcher language instead of sprint language. That part was definitely time-consuming, but it’s where the trust actually got built.
Acceptance rate measures how well you cornered your user to hit a button. Override rate measures whether the recommendation deserved a yes.
$3.2M in year one, and a better problem for year two.
The redesigned dispatch system delivered over $3.2 million in cost reduction in its pilot year, driven by recovered truck hours, saved fuel, and far fewer manual re-plans. It went from three markets to national rollout, and became the internal reference for how ML features got introduced into operational tools.
What it exposed was the next constraint, which is my favorite kind of result: dispatchers now trusted the recommendations enough to want more granular ones, and the data pipeline’s latency became the bottleneck. I scoped the follow-up work around finer deviation data and a faster refresh, which was a much easier problem to solve for than the one we started with. At least for me. The data engineers might beg to differ.