Build a Demand Forecasting Model for Freight Forwarding

Most freight forwarders rely on the forecasting module within their Transportation Management System (TMS) or export data to a BI tool like Power BI. These TMS modules are often based on simple moving averages. They recognize historical volume and basic seasonality but cannot incorporate external signals like regional manufacturing output, fuel price volatility, or port congestion data. The models can tell you what happened last year, but not why, making them unreliable when market conditions change.

Consider a regional forwarder with 15 dispatchers focused on the Southeast US. Their TMS correctly predicts a summer spike in demand for refrigerated trucks out of Georgia. But one year, a key food processing client signs a contract that doubles their weekly volume, and a new manufacturing plant opens nearby. The TMS model, blind to these specific contract and economic changes, under-predicts demand by 30%. The result is dispatchers scrambling for carriers, paying premium spot market rates, and failing to service a key account properly.

The structural problem is that TMS platforms are designed for transaction recording, not predictive analysis. Their data models are rigid; you cannot add a field for a 'local manufacturing index' to the forecasting logic. They are closed systems designed to work only with the data they generate internally. Accurate, forward-looking forecasting requires joining internal TMS data with diverse external data sources, a task for which these platforms are not architected.

The first step would be a data audit of your TMS. Syntora would analyze 12-24 months of historical shipment records, focusing on lanes, equipment types, customer tender history, and pricing. The audit identifies the strongest predictive signals and surfaces any data quality gaps, such as inconsistent lane naming, before modeling begins. You receive a data readiness report that outlines the potential of your existing data.

The technical approach uses a time-series model, likely a gradient-boosted machine like XGBoost, written in Python. This model is wrapped in a FastAPI service and deployed on AWS Lambda for low-cost, on-demand execution. This service would run on a schedule, ingesting nightly data exports from your TMS and enriching it with data from external sources like the Federal Reserve Economic Data (FRED) API for relevant regional indicators. Using the Polars library ensures efficient processing of even large historical datasets.

The delivered system is an API that provides weekly demand forecasts by lane and equipment type. This API can power a simple dashboard for your dispatchers, built with a tool like Streamlit, or push the forecast data directly into a custom field in your TMS. You receive the full Python source code, a runbook for model retraining, and a Supabase database schema for storing historical forecasts to track model accuracy over time.