Before MatchLog, I spent a few years helping create dispatch tools for regional carriers in India. The company I worked with had expanded from a small regional operation into something larger and more complicated, but its dispatch process had not kept pace. There were more loads, carriers, and lanes, yet the basic method remained the same: dispatchers calling carriers, checking status in spreadsheets, and relying on a TMS that was often out of date.
The dispatchers were not failing at their jobs. Most were excellent. They knew their carrier panel deeply, maintained strong relationships, and had good instincts about which carriers to trust on particular lanes. The difficulty was the structure of the work itself, which made strong performance unusually hard. They had too much information to track, too many decisions happening at once, and too many calls standing in for what should have been data flows.
Why Phone Calls Remain the Default
When a load is disrupted, most freight operations begin by reaching for the phone. They call the carrier to learn what is happening, the shipper or receiver to set expectations, and potential replacement carriers to locate available capacity. The phone call acts as a universal adapter: it works across situations, handles ambiguity, and supports relationship management.
The drawback is that this approach does not scale. A dispatcher handling 40 active loads who faces three simultaneous disruptions at 9 AM may make approximately 12 to 15 phone calls over the next 90 minutes, while also assigning new loads, answering in-transit carrier questions, and updating TMS records. One call becomes shorter than it should be. Some status updates wait. Some decisions rely on incomplete information because there was not enough time to collect the rest.
The dispatch floor is not a broken place. It is a place where capable, intelligent people are doing what they can within constraints that were never designed around their real workload. Most of their tools were built to store and retrieve information, rather than to cut down the number of calls they must make.
What "Fewer Phone Calls" Means as a Product Requirement
When Priya and I began discussing a better tool, we first spent substantial time with dispatch teams. Their message was consistently not "I need better analytics" or "I need a better dashboard." It was this: my work is too reactive. Too much of each day goes toward responding to problems that have already happened instead of managing them before they occur.
The calls are only the symptom. The deeper problem is information lag: the dispatcher does not see an issue developing until it has already taken shape. Once a carrier calls to report that they are late, the time available for a measured response has already narrowed. The dispatcher is forced to scramble under pressure rather than make an informed choice with lead time.
Making fewer phone calls a product outcome depends on two things: spotting problems before carriers report them and cutting the search effort required to find an answer. Both are software problems rather than communication problems. They call for real-time monitoring of carrier position data and a scoring system that finds the best available replacement option more quickly than a dispatcher can work through a mental shortlist.
Why MatchLog Is Not a Better TMS
The TMS is the obvious incumbent response to freight operations problems. When something fails, the discussion often sounds like this: "Does your TMS handle that? Which TMS are you on? Have you tried a different TMS?" Most operational data already resides in TMS platforms, so the instinct to add more features there is understandable.
We chose not to build a TMS for several reasons. Most importantly, TMS platforms are established and deeply woven into daily operations. Switching costs are high, and integration is genuinely complex. A new entrant competing through TMS features faces a major adoption barrier, while reaching the feature parity needed to justify a switch would take years before the novel functionality could even make the product compelling.
At a deeper level, our target is not a record-keeping problem. It is a real-time decision problem. TMS platforms serve the first need. MatchLog serves the second. We connect with whichever TMS an operation already uses and work on top of it, adding monitoring and matching without asking the operation to change platforms. The scope is narrower, but it is a scope three people can actually execute on in the first year.
MatchLog as It Stands Today
We are a small, bootstrapped team working with three freight operations teams in early access. MatchLog focuses on two areas: spotting ETA drift from carrier telemetry before the carrier reports it, and showing the best available replacement carrier from the operation's existing network after a disruption is confirmed.
We are not saying we have the complete answer for freight dispatch operations. We have a focused part of that answer that we believe is right, supported by 60 days of close work with real operations teams. The scope will expand as we learn and as our early-access partners show us which problem matters most next. For now, we are building incrementally from what is actually working, rather than following a roadmap written before we had customers.
The teams we work with say the detection capability most clearly changes the feel of their day. A 60-minute warning that a carrier is running late creates a different situation from a 10-minute warning. That difference led us to put monitoring ahead of matching when we had to choose. Everything else comes after getting early warning right.