One Truck, Many Problems
I spent years dispatching before moving into product. The event I recall most clearly was not a dramatic breakdown. It was the routine one: a carrier 90 minutes late for a morning pickup while carrying three downstream commitments that no one on the board had fully recognized as connected.
When the truck finally checked in late, the lane dispatcher had to call the shipper, locate a replacement carrier for the next stop on the driver's planned route, tell the consignee about a revised delivery window, and enter new ETAs in the TMS. Every task needed its own call or system change. Each call introduced a wait while attention moved between the conversation and the board. By 11 AM, two additional loads had reached amber status without being noticed early enough to stop escalation.
That is the cascade problem in its usual form. It is not a major systems breakdown. It is a routine chain of adjustments, each taking slightly longer than expected, using bandwidth faster than a small team can restore during peak hours.
Why TMS Tools Missed This Use Case
To put it plainly, TMS platforms were not created to automate cascade recovery. They were created for planned operations. Their main roles are assignment, tracking, and documentation, and they perform those roles well. Most TMS architecture assumes that people will manage disruption response.
That assumption made sense when TMS platforms were designed. Dispatch teams were bigger relative to load volume. For most freight types, the time from disruption to required response was longer. The data needed to automate re-routing decisions was also not practically available in sufficient volume.
Those circumstances have changed. Mid-market operations now run leaner teams against higher load volumes than they did a decade ago. Shippers have narrowed pickup and delivery windows. Real-time carrier telemetry is also broadly available through ELD mandates. The argument for automating disruption response is materially stronger than it was when the leading TMS platforms were architected.
MatchLog is not a TMS, nor is it intended to replace one. It works beside your existing TMS to manage the disruption-response layer that TMS platforms leave to manual work. The TMS stays the system of record. MatchLog aims to shorten the time uncovered loads remain open after something goes wrong.
Tracing the Cascade
Not every disruption cascades. A late truck without downstream connections creates one recovery event. A cascade begins when the disrupted assignment supports the planning assumptions of another assignment.
In mid-market freight brokerage operations, the most common cascade pattern centers on carrier schedule dependencies. One carrier running multiple lanes in a day creates a chain: a delay on the first lane tightens the window for each lane that follows. Without explicit chain tracking in the TMS, every link looks like a separate issue. The dispatcher handles them one at a time, unaware that resolving the first quickly could prevent the second and third.
The other common cascade pattern concerns equipment. When a reefer unit fails on a temperature-controlled load, any available truck will not do. The replacement must have the right equipment type, which sharply reduces the carrier pool. Equipment-specific loads take longer to recover, and that longer cycle creates the same bandwidth strain as a schedule-dependency cascade.
The Detection Gap
Detection latency is one factor that intensifies cascades. Most dispatchers learn about an emerging issue when the carrier or shipper calls. Carrier alerts arrive when the driver chooses to report the delay, often after it has already become material. Shipper alerts arrive once the pickup window has been missed or is close to being missed.
ELD data changes this in theory. A carrier 90 minutes behind schedule appears in position data before the driver calls, before the shipper notices, and before the window closes. The space between when a problem can be detected and when a person detects it is where cascade potential exists.
Building MatchLog's detection layer meant determining how to separate meaningful ETA drift from normal variation in carrier progress. A carrier 15 minutes behind at the beginning of a route will usually recover by delivery. A carrier 15 minutes behind at 60% of the route has a much higher probability of arriving late. The model must make that distinction continuously across all active assignments, rather than only those the dispatcher is watching at that moment.
What Early Recovery Changes
When a dispatcher learns about an emerging issue 45 minutes before the pickup window closes instead of 5 minutes after it closes, the recovery choices are genuinely different. Replacement carriers can be called before committing their trucks elsewhere. The shipper can receive notice early enough to adjust dock scheduling. If a cascade exists, it may be stopped at the first link instead of being found three links later.
Early detection does not ensure early recovery. The replacement carrier must still be available. The call must still be made. The dispatcher must still decide which option to confirm. Early detection expands the viable choices and lowers the cost of each by preserving more lead time.
In our 3-customer early-access cohort, disruptions we observed being identified earlier generally ended with fewer secondary adjustments. The sample is small, and operations vary enough that we are cautious about strong generalizations. Still, the directional finding fits the logic: earlier detection, more options, a shorter recovery loop, and less cascade.
Hard Work Beyond the Algorithm
When we explain MatchLog to people outside freight operations, they most often ask about the algorithm. How does it choose a carrier to recommend? What model does it use?
The algorithm is a real part of what we built, and we have devoted meaningful time to it. The more difficult issue, however, is the data plumbing that makes the algorithm useful. Accurate replacement-carrier rankings require current position, available hours of service, historical reliability on the specific lane, equipment type, and whether the carrier has answered calls quickly in the past. Bringing all those inputs into a form that can be processed in real time and reliably across varied carrier types and TMS configurations is where most of the engineering complexity sits.
We make this point not to complain about the technical challenge, but because it matters when assessing tools in this space. The question is not "do they have an algorithm" but "what data is actually feeding it and how fresh is it." An accurate algorithm on stale data will miss the same cascades a dispatcher would miss.