Teaching dispatchers to trust a scheduling model
WM moves thousands of routes a day. Leadership had a scheduling model ready to go and 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 for a fleet that never stops moving. Every hour of idle truck time, every avoidable backtrack, 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 useful. Meanwhile the data science team had a model that could plan a better day than a person could by hand.
So the brief I inherited was “add ML to dispatch.” I pushed back on that framing before design started, politely but firmly. A model dispatchers ignore produces exactly zero dollars of savings — and they had every reason to be skeptical, since 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
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 — and just as importantly, confident enough to throw it out? That reframe produced three bets, and every screen decision downstream 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 accept or dismiss.
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 itself in dispatcher language.
Design for the exception.
The happy path was already fine. The value was in the breakdown, the overrun, 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 planned and what was actually happening.
Recommendations render inline on 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 component time — 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 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 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 shadow mode first: it generated recommendations nobody saw, and we compared them to what dispatchers actually did. That gave the data team a calibration set and gave me a map of where human judgment consistently beat the model — which became my list of exception cases to design for.
Then three pilot markets, with the health metric deliberately set as 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 isn’t glamorous, but it’s where the trust actually got built.
Acceptance rate measures how well you cornered your user. 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 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-on work around finer deviation data and a faster refresh — a much better problem than the one we started with.