How a freight carrier sees next week's demand with Snowflake

The capacity call a carrier has to make blind

A road-freight carrier plans its week before the freight arrives. How many prime movers run, how many drivers are rostered, which lanes get the trailers. Those calls are made days ahead, and getting them wrong is expensive in both directions. Too little capacity and the freight backs up, customers churn and the network pays overtime and sub-contractor rates to recover. Too much and trucks and drivers sit idle on the carrier’s cost.

The frustrating part is that the information to plan well already exists. Every consignment booked, every lane run, every customer’s pattern over years is sitting in the carrier’s systems. The trouble is that it rarely arrives in a form a planner can use in time. Booking history lives in the freight management system, customer detail in another, forward bookings in a third, and the planning view is a spreadsheet someone rebuilds each week from partial extracts. By the time it is current, the decision has already been made on gut feel.

Demand is also spiky, and the spikes are what hurt. Volume lifts before Christmas, drops across the public holidays when the network all but stops, and surges for individual customers on a promotion or a contract change. A forecast that smooths those away looks reasonable on an average week and fails on exactly the weeks that matter. Reacting after the freight is on the dock is a structural disadvantage in a business that runs on lead time.

Why Snowflake as the forecasting platform

The aim is one governed place where the carrier’s whole demand history lives, modelled the way the business plans, so a forecast can be trusted instead of argued with. We headline these builds on Snowflake because the alternative the carrier already has, a stack of spreadsheets rebuilt from scattered extracts, breaks the moment volume or systems change and cannot be the single source planning needs.

Snowflake earns the headline for a few practical reasons. It pulls historical consignments, bookings, customer records and the event calendar into one platform rather than competing exports, so a forecast and a finance number reconcile to the same data. It separates storage from compute, so heavy back-testing of forecasting models runs without slowing the reports planners open each morning. And it gives the carrier one governed source of truth, with clear access controls over commercially sensitive customer volumes, which matters when several teams plan from the same numbers.

The supporting stack sits around that core. Apache Spark handles the heavy processing, cleaning and reshaping years of consignment records and running the model training and back-testing at scale. The forecasting models learn how volume moves by lane, customer, season and event, then write their projections back into Snowflake. Power BI reads from that single source to put projected volume next to current fleet and crew capacity, which is the view a planner actually rosters from. We kept the data platform independent of the reporting layer on purpose, so the same forecasts can feed cost-to-serve or route analysis later, not just this week’s roster.

Building it, and where it got hard

The model was rarely the hard part. The friction lived in the data and the calendar, and one issue stood in for the rest. The peaks.

Early in the build a straightforward run-rate forecast looked fine on a normal week and then missed badly on the weeks that count. It under-called the pre-Christmas surge, over-called the volume across the public holidays when the network effectively stops, and let a single unusual customer week distort the baseline for everything after it. The booking history did not help, because it was scattered and inconsistent across systems, with the same lane named three ways and estimated and confirmed bookings mixed together. A forecast built on that was confidently wrong on exactly the days planners needed it most.

The fix was less about a cleverer algorithm and more about honest data and explicit signals. We unified and modelled the booking history in Snowflake first, resolving lanes and customers to consistent identifiers and keeping forward bookings apart from completed consignments. We then modelled seasonality and the public-holiday calendar as their own signals, so the forecast lifts and falls where the freight really does, and flagged known one-off events so a single odd week did not poison the baseline. We forecast at the lane and customer grain that planning actually uses, not a single network total that hides where the pressure sits. And we showed the forecast as a range rather than one number, so a planner could roster for a likely high and low instead of betting on a point estimate.

One constraint shaped the rest. The source systems could not take heavy query load during the day, so Spark did the demanding processing in scheduled windows and wrote tidy, modelled results into Snowflake, which kept the planning reports fast and left the operational systems alone.

What changed

In a representative build the forecast stopped being a smoothed average and started reflecting how the freight actually moves. Forecasting at the lane grain with explicit holiday and seasonality handling cut average error against a naive run-rate baseline, and the improvement was largest through the peak weeks where a bad call costs the most. Volume forecasts firmed up roughly a week earlier than the old spreadsheet view, which gave fleet and crew rostering a real window to act rather than a scramble. Modelling public holidays and known customer surges surfaced the spikes the old forecast had been smoothing away, so planners saw them coming instead of meeting them on the dock.

These figures are illustrative. They describe the pattern we see rather than a published result for a named carrier. The shape is the point. The booking history that was always there starts reaching the people who size fleet and crew while there is still time to act on it, and the capacity call gets made on data instead of gut feel.

Where this fits

Freight demand forecasting is one application of our Data-Driven Decision Making service, built on Snowflake, for transport and logistics. It is a contained, high-return starting point, because the data already exists and the value comes from unifying it properly and forecasting at the grain the business plans on. It also gives the carrier a single source of truth and clear governance over sensitive customer volumes. If your capacity calls are made on last week’s spreadsheet, the place to start is to map your booking and consignment data and decide the handful of forecasts that would change your roster.