Nobody called it a crisis at first.

That's the thing about package theft at scale — it doesn't announce itself. There's no alarm, no incident report, no single moment where someone says "we have a problem." Instead, there's a slow bleed. Enterprise accounts start churning. Customer service tickets pile up around missing shipments. Finance flags revenue that quietly disappears quarter after quarter.

By the time it surfaces as a boardroom conversation, the damage is already deep.

The invisible pattern

When I joined FedEx as a Data Scientist, I inherited a problem that had been hiding in plain sight inside the operations data for years. Packages were going missing — not randomly, not at the edges, but in patterns. Patterns that, once you knew what to look for, were unmistakable.

The challenge wasn't a lack of data. FedEx has more operational data than almost any logistics company on earth. The challenge was that nobody had built a system to connect the dots across it.

I built one.

The system

The system I developed was an internal package fraud alerting platform — a set of interconnected microservices running on Google Cloud that could ingest operational signals, identify anomalous behavior across routes, facilities, and employee activity, and surface alerts before a shipment was gone for good.

The core of it was straightforward in concept, hard in practice: if you look at enough legitimate package journeys alongside enough fraudulent ones, patterns emerge. Certain combinations of signals — scan sequences, timing anomalies, route deviations, employee behavior patterns — cluster in ways that are statistically distinguishable from normal operations.

The model didn't catch every case. No model does. But it caught enough, consistently enough, that the business impact was measurable and significant.

Where the numbers land

The platform contributed to over $300 million in revenue protection — not through theoretical prevention, but through actual recovery of at-risk enterprise accounts that have churned, and through the identification of over 100 internal employees terminated for theft.

That second number matters as much as the first. The fraud wasn't just external. Some of it was inside the operation. And without a systematic way to detect it, it would have stayed invisible.

The real lesson

I tell this story not to brag about a dollar figure, but because it illustrates something I think gets missed in most conversations about ML in logistics.

The value wasn't in the algorithm. It was in the question.

The algorithm was competent, not revolutionary. What made the difference was framing the problem correctly — not "how do we catch bad actors" but "what does normal look like, and what deviates from it?" That reframe turned a surveillance problem into a pattern recognition problem, which is a much more tractable thing to build.

Most of the highest-ROI ML problems in logistics operations work the same way. The data exists. The signal is there. The gap is almost always in how the problem is defined, not in the sophistication of the model that follows.

The pattern is in your data too

I've spent the years since building similar systems in different contexts — estimated delivery date forecasting, computer vision for warehouse operations, garment measurement automation. The domains change. The underlying dynamic doesn't.

Somewhere in your operational data, there's a pattern that's costing you money. It's probably not obvious. It's probably not what you'd guess if I asked you right now.

But it's there.

I write about ML in logistics and operations. If you're working on a problem that sounds like this, I'd like to hear about it — waugh.joseph10@gmail.com