Demand forecasting models trained on your historical order data -- typically 18--36 months of line-item order history at the SKU and location level. Model architecture selection based on your data characteristics: LightGBM or XGBoost gradient boosting for large SKU catalogues with strong feature engineering (pick frequency, days-since-last-sale, price elasticity, lead time); Temporal Fusion Transformer (TFT) for datasets with complex seasonal and trend patterns where the transformer's attention mechanism identifies long-range temporal dependencies; Prophet (Facebook open source) for SKUs with clear weekly and annual seasonality where interpretability is more important than marginal accuracy gains. External signals incorporated into the feature set: promotional calendar (promotions historically increase velocity 1.5--4x; the model learns the lift multiplier per promotion type and product category); pricing history (price elasticity estimated per SKU to adjust the forecast when prices change); weather data for weather-sensitive categories (OpenWeatherMap historical API); economic indices for high-value durable goods categories. Output format: daily or weekly forecast per SKU per location with P10/P50/P90 confidence intervals -- the P10 and P90 bounds inform safety stock calculations at the desired service level. Accuracy metrics reported as Weighted Absolute Percentage Error (WAPE) or Mean Absolute Scaled Error (MASE), compared against your current forecast method as a baseline so the improvement is quantified before deployment.

Route optimisation using the Vehicle Routing Problem with Time Windows (VRPTW) solver augmented with ML-derived travel time predictions. Standard TMS routing solves VRP with static distance matrices; our approach replaces static distances with ML-predicted travel times that incorporate real-time Google Maps Platform/Mapbox Traffic API signals, historical traffic patterns by day-of-week and hour, and weather conditions affecting road speed on specific lane types. Dynamic re-optimisation: routes are re-calculated at configurable intervals during the day (every 30--60 minutes) as traffic conditions, driver locations, and new orders are updated -- stops can be resequenced or reassigned between vehicles to maintain on-time delivery as conditions change. ML performance learning: historical route outcomes (actual vs planned delivery times, overtime events, late deliveries) are used to build driver-specific and lane-specific correction factors. A driver who consistently runs 15% slower than the planned route time on suburban stop sequences gets a route planned with that buffer built in. Constraints modelled: vehicle capacity (weight and volume), customer time windows (hard and soft), driver hours of service regulations (EU Working Time Directive / US FMCSA Hours of Service), vehicle compatibility per stop (refrigerated vehicle required, narrow access), and driver certification requirements per cargo type. Integration: route output delivered to your TMS (Oracle TMS, SAP TM, BluJay, project44) or dispatch app via REST API; driver assignment and sequence updated in real time in the driver's mobile app.

Predictive ETA and exception detection models score each in-transit shipment at booking and update the risk score as new data arrives during transit. Feature set per shipment: carrier (historical on-time performance for that carrier on this lane, last 90 days); origin-destination lane (historical exception rate for this specific lane, seasonally adjusted); days in transit vs expected transit time (shipments at day N of M carry a different risk profile than those at day 1); weather conditions along the route (tomorrow's forecast weather for the remaining route segments from OpenWeatherMap or Tomorrow.io); carrier scan events (a shipment with no scan in the last 24 hours has a statistically higher exception rate than one that scanned this morning); and shipment characteristics (heavier, larger shipments and temperature-sensitive cargo have higher exception rates on specific carriers). Model output: a delay probability score (0--1) and an estimated delivery date range (P25/P50/P75) rather than a single point ETA. Operational actions triggered by score thresholds: high-risk shipments (score above 0.7) surface to the operations exception queue with the contributing risk factors listed in plain language ("Carrier X has a 34% on-time rate on this lane in Q4; shipment has not scanned in 18 hours; weather delay forecast for destination city today"). Customer-proactive notification: shipments above a configurable threshold trigger an automated customer notification with a revised ETA range and a carrier escalation action -- the notification arrives before the customer contacts you, which drives measurably lower inbound exception call volume.

Carrier rate prediction models forecast spot and contract rate movements for specific lane-mode combinations (FTL, LTL, parcel, air freight) at weekly and monthly horizons. Feature engineering for rate models: diesel fuel price index (US EIA weekly diesel retail price data; EU Eurostat fuel price); DAT Solutions or Freightos Baltic Index historical spot rate data; carrier capacity utilisation signals (tender acceptance rate from freight indices -- a falling acceptance rate signals tightening capacity and rising rates); seasonal demand patterns (Q4 peak, produce season, retailer inventory restocking cycles); and macro freight demand indicators (ISM manufacturing PMI, US Census retail sales data). Model architecture: XGBoost regression with lagged features for the primary rate prediction; ARIMA for the residual component to capture mean-reversion patterns in rate cycles. Output: lane-specific rate forecast with a confidence range for the next 4 and 8 weeks, with a "buy now vs wait" recommendation signal based on whether the model predicts rates will rise or fall. Procurement use cases: the model tells the freight buyer whether to lock in a 90-day contract rate today or wait for better spot conditions in three weeks; it surfaces lanes where spot rates are currently favourable relative to contracted rates, enabling tactical spot purchasing on those lanes while maintaining contracts on lanes where spot is above contract. Historical backtesting is run against your rate transaction data before production deployment to quantify the predictive accuracy the model achieves on your specific lanes.

Shipping document extraction uses a combination of OCR and LLM-based extraction to parse structured data from the unstructured layouts and varying formats of logistics documents. Document types handled: bills of lading (BOL) -- shipper name and address, consignee name and address, notify party, carrier and SCAC code, pro number, commodity description, weight, piece count, freight class, special instructions, and hazmat information; proof of delivery (POD) -- delivery timestamp, recipient name and signature, exception notes, and condition notes; customs entry documents (CBP 3461/7501 for US imports, UK Customs Declaration for UK, EU Intrastat) -- HS codes, declared values, country of origin, tariff duty classification; commercial invoices -- invoice number, line items with HS codes and values, Incoterms, and total invoice value; and carrier freight invoices (for three-way matching against TMS rate confirmations). Document input formats: PDF (both digitally generated and scanned); TIFF and JPEG images from driver mobile apps; email attachments from carrier notifications. Extraction pipeline: document classification (identify document type before applying the type-specific extraction model); OCR via Azure Document Intelligence or AWS Textract (handles skewed scans and handwritten annotations); LLM extraction step using GPT-4o or Claude with structured output mode to interpret ambiguous fields and normalise addresses, dates, and weights to your required format. Extraction confidence scores per field: low-confidence extractions are queued for human review with the relevant document region highlighted, rather than being silently inserted into your TMS with an error. Output delivered via API to your TMS (Oracle TMS, SAP TM, MercuryGate) or ERP.

Load optimisation solves the 3D bin-packing and weight-distribution problem to maximise trailer or container utilisation and ensure legal axle weight compliance. Input data: each shipment's SKU list with dimensions (length, width, height) and weight per unit; trailer or container dimensions; stackability constraints (fragile items, hazmat segregation, FIFO loading for multi-stop routes); and legal weight limits (US federal bridge formula; EU Directive 96/53/EC GVW limits). Optimisation output: a load plan showing item placement within the trailer with a 3D rendering, estimated utilisation percentage, weight distribution per axle, and loading sequence for multi-stop routes (last-off items load first). Achieving 5--12% improvement in trailer utilisation on mixed freight loads is common; the direct saving is fewer trailers per week for the same shipment volume. Warehouse slotting optimisation analyses your WMS pick history to recommend slot assignment changes that reduce total pick travel distance. Analysis dimensions: pick frequency per SKU (A/B/C velocity classification); co-order frequency (SKUs that appear in the same order frequently should be slotted in adjacent locations to reduce inter-aisle travel); order weight and ergonomic constraints (heavy items slotted at waist height, not overhead); and seasonal velocity shifts (SKUs that move to A-tier for Q4 should move to prime slots for Q4). Output: a slotting recommendation report ranking proposed moves by expected pick distance reduction, prioritising high-impact moves that justify the labour cost of physically relocating product. The model re-runs against updated pick history on a configurable schedule (monthly or quarterly) and surfaces moves that have become worthwhile as velocity patterns change.