For about 60 days, three freight operations teams have used MatchLog in early access. This note covers what we learned, which assumptions held, and which findings led us to revise the product before a broader launch.
To clarify what "early-access" means here: we are not presenting metrics from a controlled study. We worked alongside each team, integrated with their TMS, ran MatchLog beside their normal dispatch process, and spoke regularly about what helped and what did not. These are qualitative observations from our 3-customer early-access cohort. We are sharing them because they may matter to operations teams facing similar problems, not as validated benchmarks.
What We Expected to Find
Before the pilot, we believed the central issue was speed: dispatchers needed replacement carriers faster during disruptions. We expected search time compression to be the product's main value. A disruption occurs, MatchLog finds the best available carrier in two minutes rather than twenty, the dispatcher confirms, and the process is complete.
That assumption was partly correct. Still, it was a smaller part of the actual problem than we had anticipated.
What We Actually Found
Detection Was the Bigger Problem
Across all three pilot operations, the recurring gap was not "the dispatcher found the right carrier slowly." It was "the dispatcher did not realize a problem was developing until it had become critical." When a carrier finally called about a delay, the pickup window had already contracted from 90 minutes to 20 minutes. The urgency to match came from late detection, not the matching process itself.
With a 90-minute warning that a carrier is late, there is time to find a good replacement. With a 15-minute warning, any replacement may seem right because the good options are gone. Faster search only helps when enough lead time remains for the search to matter.
This led us to put far more emphasis on monitoring: identifying ETA drift from telemetry before the carrier calls and bringing the alert to the dispatcher before the window collapses. Monitoring was not our original product emphasis, but the pilot showed that it needed to be.
Dispatchers Distrusted Even Small Automated Actions
During the pilot, one product version automatically sent a "we're monitoring your ETA" notification to the carrier when MatchLog detected drift. It did not reassign the load, it only sent a communication. Two of the three teams asked us to disable it.
The response was consistent: carriers would assume any automated message came personally from the dispatcher. If its tone was off, or the carrier planned to call anyway, the message added noise and sometimes friction. Dispatchers wanted to manage carrier communication themselves, even when an automated trigger initiated the underlying event.
We anticipated resistance to automated carrier contact, but not to a message deliberately designed to be lightweight. That feedback shaped a product principle we now treat as firm: MatchLog does not communicate externally for a dispatcher without explicit action. Every outbound touch starts with a person. The system manages internal detection and matching logic, while the dispatcher retains the carrier relationship.
The "Known Reliable" Shortlist Created a Problem
Before the pilot, I had seen this pattern anecdotally during my time in logistics operations. The pilot made it unmistakable. Each team maintained a shortlist of 5 to 10 carriers contacted first for every disruption, whether or not they best suited the particular load. This was rational, not careless: under time pressure, calling someone trusted is faster and less risky than assessing unfamiliar options.
The downside is that the rest of the carrier panel withers. Carriers outside the shortlist receive less business, build less history, and become harder to assess confidently. The shortlist reinforces itself and grows shorter over time as business shifts toward the most familiar names.
MatchLog addresses this by scoring the full carrier panel for every disruption and presenting the best match, regardless of familiarity. During the pilot, we found cases where a carrier outside the usual shortlist ranked highest for lane familiarity and recent performance, and the dispatcher accepted the recommendation. Those choices delivered outcomes comparable to or better than familiar carriers on the same lanes.
Areas Still in Progress
The pilot revealed two unresolved gaps. First, our scoring logic currently treats every carrier cancellation the same. A carrier canceling a confirmed load 48 hours out causes less harm than one canceling at 4 AM day-of, and the score should capture that difference. It does not yet, which affects our ranking of carriers with mixed reliability profiles.
Second, multi-leg loads are not yet handled well. When a disruption involves a carrier midway through a relay run, the matching logic must account for downstream segments and constraints, not only the immediate open load. This is more difficult, and we are still working through its data model.
We will continue sharing what we learn as building continues. This post covers a 60-day period with three teams, and we are not saying dispatch operations for the industry are solved. We have confirmed that our target problem is real, that a detection-first approach fits better than our original speed-first hypothesis, and that dispatchers want control of external relationships even when internal logic is automated. Those three findings are enough reason to keep building.