The University of Michigan ran an AI hackathon on urban heat resilience, and the technical problem the teams worked on is more relevant to a D2C operations lead than it first appears. Cities can't make street-level decisions about heat — where to plant trees, which blocks need cooling centers — because the available satellite thermal imagery is too coarse: roughly 30-meter resolution, refreshed every day and a half. So the teams built models to generate high-resolution thermal maps from cheap, widely available RGB photographs. The whole exercise was about manufacturing a fine-grained, decision-ready signal from data that was too blunt to act on.
That is the exact shape of the problem hiding inside most D2C demand forecasting. Your forecast knows, from years of history, that summer sells more than winter. What it can't tell you is that a heatwave will push electrolyte demand up 60% in the Southwest starting Tuesday, while your nearest warehouse is stocked to the national average. The data you forecast on — aggregate, national, calendar-based — is too coarse for the decision you actually need to make, which is local and happening in 48 hours.
TL;DR: Calendar seasonality is a lagging, national signal. A localized 7-day heat forecast is a leading, regional one. Wiring it into your demand model lets you pre-position heat-sensitive SKUs at the right warehouse before a heatwave, instead of paying expedited freight and eating stockouts after sales data confirms it. If you want us to test which of your SKUs carry a real heat signal, book a 30-min call with Dhwani — no SDR layer.
Calendar Seasonality Is a Lagging, Blunt Signal
Almost every demand forecast already includes seasonality. The model learns the annual shape from historical sales — July outsells February — and projects it forward. This is genuinely useful and it is also structurally limited in two ways that matter for heat-driven categories.
First, it's national. The seasonality curve is fit across all your sales, so it describes an average region in an average year. It has no concept of one metro running 10°F hotter than the seasonal norm next week while another sits at average. Second, it's a lagging learner. The model only knows what historical sales taught it. A record-breaking regional heatwave is, by definition, not in the average — it gets smoothed into the seasonal curve as noise. The forecast reacts to the heatwave only after the sales data from it lands, which is exactly when it's too late to reposition inventory given fulfillment lead times.
Our post on managing seasonal demand spikes covers the calendar layer well — Diwali, Black Friday, the summer season. The heat-forecast signal is the layer above it: the within-season, regional, event-level adjustment that the calendar average can't see.
What a Localized Heat Forecast Actually Adds
A localized heat forecast is a leading indicator. A commercial weather API or a public national meteorological feed gives you a 7-to-14-day temperature forecast at metro-level granularity, updated daily. That's a week of warning about a regional demand event, available before a single unit of that event's demand has been sold.
The value is the combination of two properties the hackathon was also chasing: it's local (metro-level, mappable to your fulfillment zones) and it's forward-looking (a forecast, not a record of what already happened). Calendar seasonality has neither property at the resolution that matters. A national monthly seasonal index can't tell two regions apart and can't react to a specific incoming event.
The decision this enables is inventory pre-positioning. If you know with seven days' notice that the Southwest will see record heat, and you know which SKUs carry a real heat-demand coefficient, you can transfer stock to the warehouse nearest that region before the spike — instead of discovering the imbalance from stockout alerts and rerouting orders across the country at expedited freight rates.
What This Cost a Hydration Brand Last Summer
A $6M hydration and electrolyte D2C brand we work with fulfills from three US nodes — Reno, Dallas, and Atlanta. Last June, a heat dome settled over the Southwest; Phoenix and Las Vegas hit record highs for four straight days. Demand for their electrolyte multipacks spiked roughly 60% across the Mountain and Southwest delivery region over those four days.
Their forecast had stocked the Reno node — nearest to that region — to the national seasonal average for mid-June. It stocked out of the hero SKU in about 36 hours. Orders from the Southwest then rerouted to the Dallas node: an extra two days in transit and about $4.20 per unit in additional freight, during the precise window when customers wanted the product immediately. Roughly 1,400 orders shipped late or split across nodes. The lost-margin-plus-freight cost of that single four-day event ran to the low five figures, and the softer cost — customers who bought a competitor's product locally because the order was delayed — doesn't show up on any invoice.
None of this was a forecasting failure in the conventional sense. The seasonal model was working correctly. It simply had no input that could distinguish a record heatwave in one region from an average June. The heat forecast existed publicly seven days ahead of the spike. It just wasn't wired into the inventory decision.
The signal was public a week early. The gap was that nothing connected it to the warehouse.
We test heat-demand correlation per SKU and wire the forecast feed into Odoo stock-transfer recommendations for D2C brands with multi-node fulfillment. If you want that assessment for your catalog, grab 30 minutes with Dhwani. Written brief inside a week.
How to Build It — Starting Without Machine Learning
The instinct is to reach for a trained model on day one. You don't need one to start, and starting simpler proves the signal is real before you invest in the harder version.
Step 1 — Find the SKUs that actually carry a heat signal. For each SKU, regress its daily regional unit sales against the local daily high temperature over two to three years, controlling for calendar season and promotions. SKUs with a statistically significant temperature coefficient after that control are your candidates. For most catalogs this is 10–25% of SKUs — hydration, sunscreen, cooling products, certain apparel — not the whole catalog. This keeps the work focused and avoids modeling temperature sensitivity into SKUs that don't have any.
Step 2 — Build a temperature-to-uplift table per SKU per zone. The first version is a coefficient table, not a neural network: for each heat-sensitive SKU in each fulfillment zone, how many additional units does each degree above the seasonal norm drive? Refresh it daily against the incoming 7-day forecast to produce a predicted regional uplift. This captures most of the available value and is auditable — you can see exactly why it recommended moving stock.
Step 3 — Turn predicted uplift into a stock-transfer recommendation. Feed the predicted regional uplift into your order management system so it becomes an action, not a chart. In Odoo, this is an internal transfer recommendation between warehouses, raised before the event with enough lead time to actually move the stock. Our post on routing orders to the nearest stock point covers the multi-node mechanics this plugs into.
Step 4 — Graduate to a trained model only when the simple version proves out. Once the coefficient table is demonstrably reducing stockouts and expedited freight, a trained model on Amazon SageMaker can capture the non-linear effects — humidity interactions, the difference between the first hot day and the fifth, the demand pull-forward where a heatwave borrows from the following week. Our overview of AI-powered demand forecasting for Odoo covers where a learned model earns its keep over a rules-based one.
The Transferable Lesson From the Hackathon
The Michigan teams didn't get a clean win — their models struggled to preserve fine spatial structure when translating RGB to thermal, and the honest conclusion was that the signal mismatch between the two sensor types is partly inherent. That's worth holding onto, because it's the same caution that applies here. A heat-forecast demand signal is a meaningful input, not a crystal ball. Weather forecasts degrade past about a week. Demand has many drivers, and temperature is one of them, not all of them.
The transferable lesson is the framing, not a promise of precision: when your decision is local and time-sensitive, a coarse aggregate signal will quietly fail you, and the fix is to pair a leading external signal with the geographic resolution the decision actually requires. The hackathon manufactured spatial resolution it didn't have. A D2C brand already has the signal sitting in a public weather feed — the work is connecting it to the warehouse before the heatwave, instead of explaining the stockout after it. For the safety-stock layer that should sit underneath this, our post on safety stock configuration for seasonal brands covers the buffer math the heat signal then sharpens.
Frequently Asked Questions
How is a heat-forecast demand signal different from the seasonality already in my forecast?
Seasonality in a standard forecast is calendar-based and national: it learns that July sells more than February from years of historical sales, and applies that curve broadly. A heat-forecast signal is event-based and local: it reacts to a specific 7-day forecast for a specific metro area, days before any sales data exists for that event. The two are complementary, not redundant. Seasonality sets your baseline expectation for the month; the heat signal adjusts a specific region's allocation for a specific incoming weather event that the calendar average has smoothed away. A brand running only calendar seasonality is structurally blind to the difference between an average July week and a record-breaking heatwave week in one region.
Which D2C product categories actually have heat-sensitive demand worth modeling?
The clearest signal appears in hydration and electrolyte products, sports and outdoor hydration gear, sunscreen and after-sun skincare, cooling and personal-comfort products (cooling towels, portable fans, cooling bedding), certain beverages, and warm-weather apparel. The test is whether a SKU's regional sales historically correlate with local temperature beyond the calendar season — you can validate this by regressing each SKU's daily regional units against local daily high temperature over two to three years of data. SKUs with a statistically significant temperature coefficient after controlling for season are the ones worth wiring a forecast signal into. For most catalogs this is 10 to 25 percent of SKUs, not the whole catalog, so the modeling effort stays focused.
What data and infrastructure does this take to build?
Three pieces. First, a localized weather forecast feed — a commercial weather API or the public NOAA/national meteorological feeds provide 7-to-14-day metro-level temperature forecasts at no or low cost. Second, a demand uplift model that maps forecast temperature to expected unit uplift per heat-sensitive SKU per fulfillment zone; this can run as a trained model on Amazon SageMaker or, for a simpler start, as a regression coefficient table. Third, an integration into your order management system — typically Odoo — that converts the predicted regional uplift into a stock transfer recommendation between warehouses before the event. The first version doesn't need machine learning at all; a temperature-to-uplift coefficient per SKU per zone, refreshed daily against the forecast, captures most of the value and proves the signal before you invest in a trained model.
About the author
Co-founder & AI Practice Lead, Braincuber Technologies
Co-founder at Braincuber. Builds production AI agents (Anthropic Claude, OpenAI, AWS Bedrock) for US fintech, healthcare, and retail clients with SOC 2 Type II / HIPAA-scope deployments. Joins every architecture review personally.