Case Study | Maritime Logistics | Machine Learning

$18M Annual Fuel Savings. 450 Vessels. Still Running 6 Years Later.

Predictive Freight Router: ML-Powered Logistics Optimization

Context

A global container shipping operator managing 450 vessels and 1.2 million TEUs annually was routing ships using static lane assignments updated quarterly by a team of four analysts. Their ETA predictions were off by 3 to 5 days. Fuel procurement was based on historical averages, not actual voyage conditions. Bunker fuel is the single largest operating cost in container shipping, and they were burning $18 million more annually than the physics of their routes required. The operator needed ML-powered route optimization that could factor in weather, currents, port congestion, draft restrictions, and fuel price arbitrage across bunkering ports. The system had to integrate with their SAP Transportation Management instance (SOAP APIs, not REST) and their existing Rails-based operations dashboard.

Approach

•Built a PyTorch Graph Neural Network that models the global shipping lane network as a graph, with ports as nodes and routes as edges weighted by fuel cost, time, weather risk, and port congestion
•Rails middleware layer bridges SAP TM (SOAP/XML) with the ML pipeline (SageMaker/REST), handling data transformation, caching, and error recovery
•Route optimizer evaluates 15,000 permutations every 6 hours, incorporating live weather data, real-time port congestion feeds, and bunker fuel price APIs
•Progressive deployment: ran shadow mode for 8 weeks (ML recommendations alongside human decisions) before switching to ML-primary with human override

Results

Methodology →

Annual Fuel Spend (excess)

$18M → Eliminated

-100%

ETA Accuracy

±5 days → ±12 hours

10x improvement

Route Optimization Cycle

Quarterly → Every 6 hours

Automated

Port Congestion Delays

14% → 3.2%

-77%

Bunker Fuel Procurement

Historical avg → Dynamic arbitrage

Cross-port optimization

Analyst Team

Route planning → Exception handling

Higher-value work

✓450 vessels optimized across Atlantic, Pacific, and Indian Ocean trade lanes

✓1.2 million TEU annual throughput with no service level degradation

✓Survived the COVID-19 supply chain disruption (model adapted to unprecedented port closures)

✓System still in production 6+ years later (now on Rails 7, upgraded from Rails 5)

✓ROI payback period: 4.5 months

Stack & Integrations

Ruby on Rails (5 → 7)

PyTorch (GNN)

AWS SageMaker

SAP TM (SOAP)

PostgreSQL + PostGIS

Redis / Sidekiq

Weather API (ECMWF)

AIS Vessel Tracking

Bunker Fuel Price APIs

Approach Deep-Dive

The Graph Neural Network was the architectural insight that made this work. Traditional route optimization treats voyages as independent point-to-point calculations. But shipping networks are graphs: what happens at one port affects every connected route. When Shanghai gets congested, it does not just delay ships going to Shanghai. It cascades to Busan, Long Beach, Rotterdam. A GNN captures these network effects natively.

The model ingests four data streams: historical voyage data (3 years of AIS tracking data covering every vessel in the fleet), live weather forecasts (ECMWF model, updated every 6 hours), real-time port congestion indicators (berth occupancy, vessel queue lengths, average wait times), and bunker fuel prices at 200+ bunkering ports worldwide.

Every 6 hours, the optimizer generates route recommendations for every vessel currently at sea. Each recommendation includes: optimal speed profile (varying speed throughout the voyage to minimize fuel burn while meeting delivery windows), recommended bunkering ports (buy fuel where it is cheapest along the route), weather routing adjustments (reroute around developing storm systems), and port approach timing (speed up or slow down to arrive when berth space is available rather than anchoring to wait).

The SAP integration was the hardest part. SAP TM uses SOAP/XML over HTTP with complex nested schemas. The Rails middleware layer handles bidirectional data sync: pulling voyage plans and cargo manifests from SAP, pushing optimized routes back. The middleware includes a robust retry layer (exponential backoff with dead letter queue) because SAP's SOAP endpoints are, to put it politely, temperamental about uptime.

The COVID stress test was unplanned but revealing. When ports started closing in March 2020, the model's training data had no precedent for "major global ports shut down simultaneously." The model's confidence scores dropped (correctly), and it escalated more decisions to human analysts. As new data accumulated over 8 weeks, the model adapted. By June 2020, it was routing around closures and congestion patterns it had never seen in training data. The GNN's graph structure helped here: it could propagate disruption signals through the network even for port pairs it had never seen disrupted together.

Timeline

Months 1-2Data pipeline (AIS feeds, weather API, SAP extraction, fuel price APIs)

Months 3-5GNN model development and training on 3 years of historical data

Months 6-7SAP middleware development and integration testing

Months 8-9Shadow mode (ML recommendations parallel to human decisions)

Month 10Production cutover with human override capability

Months 11-12Performance tuning, model retraining with live data

Lessons Learned

"Shadow mode deployment is non-negotiable for ML systems that affect physical assets. Running ML recommendations alongside human decisions for 8 weeks built trust and caught edge cases the model mishandled."

"SAP integration always takes longer than you think. Budget 40% more time for the middleware layer than the ML model itself."

"The model that survives disruption is not the most accurate one. It is the one that knows when it does not know, drops its confidence score, and escalates to humans."

Related Case Studies

Healthcare Platform Resurrection

Rails 3 → 7, zero downtime

FinOps Fraud Detection

$14.7M caught

Cold Chain Guardian

$42M cargo saved

Burning Money on Suboptimal Logistics?

If your routing, scheduling, or resource allocation is driven by static rules or quarterly analyst updates, there is a quantifiable gap between what you are spending and what the math says you should be spending. We build ML systems that close that gap and stay in production for years.

View Data Analytics Platform Services

$18M Annual Fuel Savings. 450 Vessels. Still Running 6 Years Later.

Context

Approach

Read the Full Case Study