Boosting Delivery Success to 98% and Saving 3,360+ Parcels Annually

The Challenge

An e-commerce fulfillment operation handling about 4,000 shipments a month was losing revenue to three coupled problems: orders split into more parcels than necessary, carrier and shipping-account choice made without a live success probability, and a 9% delivery failure rate. Extra splits raised shipping spend. Weak routing and late visibility into failures delayed fulfillment and eroded customer trust. International orders added a further choice — which point of entry and which flights those lanes depend on — and temperature-controlled goods had to stay within cold-chain capacity. Upstream systems also needed a controlled way to land raw operational payloads before they were cleaned and used for scoring.

The Solution

• Minimum parcel split

  For each order, the rules engine builds a bin-packing problem and solves it with OR-Tools SCIP. The solver returns the smallest set of parcels that still respects volume and separates cold from ambient items, which cuts avoidable multi-parcel fees.

• Scored carrier and route selection

  Airflow keeps a parcel-level feature store and shipping-account KPIs in Aurora MySQL. At decision time the rules engine loads the current MLflow model and scores candidate warehouse, carrier, and shipping-method options, including point-of-entry risk. The assignment is the option with the highest predicted delivery success, not a static carrier rule. Proposed models are compared with the live model before promotion.

• Flight-aware lane context

  The FlightAware client queries AeroAPI for departures from an origin airport and for historical flights on a given ident. Results are flattened to a time-ordered frame of scheduled versus actual movements, so lane reliability can be read from real flight history rather than from carrier name alone.

• Early failure detection

  A second model reads carrier tracking events in the first days after ship and flags parcels likely to fail while there is still time to intervene. Clarity exposes those scores, account health, and model drift to operations.

• Raw data intake

  Partners and internal jobs push JSON into the Data Quality API. Each payload is stored as a row in data_quality_raw and left unprocessed until a downstream job picks it up. The service is deployed with the rest of the platform (EKS, Argo CD, ECR) and reports health against the same Aurora write database the scoring path uses.

• Production path

  The scoring API, data-quality API, model registry, and ETL run on EKS, deployed by Argo CD from Git, with secrets and logs in AWS. FlightAware access is a Python integration against AeroAPI, using the same secrets and MySQL conventions as the ML pipelines.