Freight visibility was the right first category for logistics AI investment. The data collection problem was tractable — carrier milestone events, telematics feeds, port EDI messages — and the use case was immediately legible to buyers: knowing where a shipment is, in real time, across all carriers on a single screen. Companies like project44, FourKites, and Shippeo built large businesses on this premise, and the category now has multiple well-capitalized players competing on data coverage breadth and ETA prediction accuracy.
That maturation has important implications for where the next wave of logistics AI investment produces returns. Visibility is not finished as a category — the ETA prediction quality varies widely across traffic and weather conditions, and the coverage gaps in certain European freight corridors remain real. But visibility as a primary venture bet has moved from a question of "can anyone build this?" to a question of "which of the existing players wins?" That's a different investment calculus than what it was three years ago.
The question I've been working through for the past year is what the layer above visibility looks like — and specifically, whether the intelligence capabilities that visibility data enables are best built into the visibility platforms themselves, or whether they represent a distinct and defensible product category that a separate company can own.
What visibility data enables but visibility platforms don't deliver
Freight visibility platforms are built around a data problem: aggregating milestone events from hundreds of carriers, parsing them into a consistent schema, and surfacing them on a unified timeline. The engineering challenge is the breadth and reliability of the carrier integrations. The value proposition is the aggregation itself — seeing all your freight in one place — plus basic alerting when shipments deviate from expected timelines.
What those platforms have not productized well is the decision layer on top of the data. Knowing that a shipment is three hours late tells you the fact. It doesn't tell you what to do about it. For a buyer who is managing 200 open shipments on any given day, the information value of a delay alert is limited if it isn't paired with decision support: should I call the carrier, expedite a replacement shipment, notify the downstream customer, or hold because the buffer stock position will absorb the delay? Each of those responses has a different cost and a different probability of improving the outcome. The visibility platform surfaces the alert; the logistics manager makes the decision based on context that isn't in the platform.
This gap — between tracking data and decision support — is where I see the more durable intelligence opportunity in logistics AI. The companies that close this gap aren't building visibility tools. They're building decision systems that ingest visibility data as one input among many and produce recommendations specific to the operational context of a given shipper.
The decision context problem
The reason visibility platforms haven't bridged this gap isn't a failure of ambition — it's a data structure problem. Optimal response to a shipment delay depends on variables that are specific to the shipper's context: inventory positions at destination facilities, production schedule sensitivity, customer SLA terms, alternative carrier availability on the affected lane, and the historical cost-of-error for this shipment category. Visibility platforms don't hold these variables. They hold carrier data. The shipper-side context lives in ERPs, TMS systems, customer contracts, and the heads of experienced logistics managers.
Building a decision support system that understands operational context requires integrating across a data surface that is messier than the carrier data problem that visibility platforms have already solved. It requires building connectors into ERP inventory data, TMS lane rate tables, and customer SLA repositories — and then training recommendation models on the historical decisions that experienced operators made when facing comparable situations with comparable data available.
That's a harder engineering problem than building a carrier integration network. But it's also a harder problem to replicate, because the model quality compounds with operational data from a specific shipper's environment in a way that a generic visibility platform's alerting logic doesn't. A decision support system that has learned from 18 months of operational decisions at a Nordic FMCG distributor is substantially better at that distributor's specific problems than a generic alerting tool — and the gap grows over time, not shrinks.
Three decision categories that visibility data enables
Based on conversations with European shippers and freight forwarders over the past year, the decision categories where ML-based support generates the most measurable value break into three clusters.
The first is exception prioritization. Large shippers process dozens to hundreds of exception alerts per day. Not all exceptions require the same response urgency. A system that scores exceptions by downstream impact — ranking a three-hour delay on a shipment feeding a just-in-time production line above a one-day delay on a non-critical replenishment shipment — lets operators allocate attention to the exceptions that actually matter. The ranking itself is learnable from historical data: which delay patterns in the past actually caused production line stops or customer SLA breaches, versus which resolved themselves without intervention?
The second is carrier selection at rebooking. When a shipment is canceled or a carrier fails to load, the logistics manager needs to identify an alternative carrier on short notice for that specific origin-destination pair, at current available capacity and price. Manual carrier selection at rebooking relies on the manager's knowledge of which carriers typically have capacity on that lane and how their performance compares. A system with historical carrier performance data at lane granularity — not just average performance, but performance under specific weather conditions, specific seasonal demand periods, and specific origin/destination terminal combinations — can recommend the carrier most likely to deliver within the required window at the lowest available rate. This is not exotic ML; it's a retrieval and scoring problem on well-structured historical data. But it's a problem that most logistics software handles with a static rate sheet lookup rather than a data-driven recommendation.
The third is proactive customer communication. When a high-probability delay is identified early — say, 12 to 18 hours before the expected delivery window — the optimal response often includes notifying the downstream customer before they notice the deviation themselves. We are not saying automation of that communication is always appropriate; customer relationships often require human judgment about tone and context. But automating the identification of which shipments warrant early customer notification, and drafting communication templates populated with the relevant details, reduces the manager's cognitive load and reduces the frequency of customers discovering delays without prior warning from their supplier.
Where the seed stage opportunity sits
The companies building toward this decision support layer are working at the intersection of logistics domain knowledge and ML systems engineering. The logos that get the most attention in this space are the freight forwarder platforms — Flexport and its European equivalents — that are building vertically integrated visibility-plus-decision tools for their own freight brokerage businesses. But vertically integrated tools built for brokerage aren't the same product as a shipper-side decision support tool that works across multiple 3PL and carrier relationships.
The seed-stage opportunity I see is specifically in software that helps the operations teams at mid-to-large European shippers — FMCG, automotive supply chains, industrial distributors — make better decisions on their existing freight, using their existing carrier relationships and their existing TMS. That means building the integrations into the shipper's operational systems, not building a new freight marketplace. It means pricing on outcomes — cost savings from better carrier selection, penalty cost avoidance from better exception management — not just on data access. And it means founding teams that have worked in shipper logistics operations, not freight brokerage.
The visibility market gave logistics AI its first proof point that operators will pay for data aggregation and alerting. The decision intelligence layer is where the value proposition shifts from "better information" to "better outcomes" — and that shift is where durable software businesses in this category get built.