Demand forecasting: the SKUs with no history

Where demand forecasting is a solved statistical problem, where it is not because the SKU has no history to fit, and what a vendor's own documented cold-start workaround admits about the difference.

By the Foxnut team · Updated 19 August 2026

A forecast for a SKU with history, and a forecast for one without, are not the same problem

Ask a vendor whether its product does demand forecasting and the answer is almost always yes, because most demand forecasting is a solved statistical problem: take a time series of past sales, fit a curve to it, project it forward, and correct for trend and season as more weeks arrive. That part of the category is mature, cheap, and not where a project succeeds or fails. The part worth a comparison is the SKU the curve has nothing to fit against - a new product, a limited drop, a private-label refresh, a range that turns over faster than any item on it accumulates a season’s worth of sales. For that SKU, “automate the forecast” does not mean automate the curve-fitting. It means answer a structurally different question: what does an item do when there is no record of what it has done.

One documented cloud forecasting product states the boundary in its own configuration rather than in marketing language. Of the algorithms it ships, only two are qualified to produce a prediction for an item with no direct sales history at all, and only when a separate file of item characteristics already exists tying the new item to items that do have history; every other algorithm in the same product simply has nothing to compute against and does not attempt it. That is not a limitation buried in a footnote. It is the product’s own admission that a no-history forecast is not a smaller version of a normal one - it is a different operation, run through a different mechanism, on different data, with a different and lower ceiling on accuracy, because it is borrowing an answer from a neighbour rather than reading one off the item’s own record. Anyone evaluating automation here is really evaluating two products wearing one name, and the case for building rather than buying either one is how this studio transfers a forecasting system once it is running well enough that a business does not need the studio to keep it that way.

Four ways to answer for a SKU with no history

The choice is not between forecasting and not forecasting. It is about what stands in for the history that does not exist, and what happens when the stand-in is wrong.

	A person estimates it	Borrow from a like item	Wait, then switch to statistics	A general ML platform, configured for it
What stands in for history	Judgment: a buyer’s read on how a similar launch went last time	A chosen analogue item’s own sales curve, scaled by hand or by rule	Nothing, deliberately - the order is placed on a manual estimate until real sales accumulate	A metadata file describing the new item’s attributes, matched by the system against items with real history
What it needs to work	A person who has seen enough launches to have a real prior	An honestly chosen analogue and the discipline to admit when none exists	Patience, and a tolerance for early stockouts or early overstock while data accumulates	A maintained metadata file, matched against a catalogue large enough to contain real analogues
Where it breaks	A launch unlike anything the estimator has seen before	An analogue chosen because it was convenient, not because it was similar	A launch cycle short enough that the item sells out or is discontinued before it ever crosses into “has history”	An attribute set too thin to distinguish a genuine analogue from a superficial one
What it costs to keep running	Nothing beyond the person’s time, and it does not scale past what one person can review	Almost nothing in tooling, and a real cost in the discipline of choosing analogues honestly	Nothing extra, and it is the default any business already has before it buys anything	A maintained metadata schema, a matching step nobody sees, and a system that needs the rest of the catalogue to already carry good data

The third row is where most disappointment shows up. A borrowed answer, whether from a person’s memory or from a matched analogue, is only as good as the analogue, and nothing in any of the four arrangements can verify the analogue is right before the sales come in to prove or disprove it. Automating the choice of analogue does not remove that risk; it just moves the judgment from a buyer’s memory into a metadata schema someone still has to design and maintain honestly.

What the decision turns on

Six structural dimensions decide whether a process is worth automating. Demand forecasting for a SKU with no history reads differently from the rest of this library on nearly all of them, because the thing being produced is a number about an event that has not happened, made without the one input - the item’s own past - that every other forecasting method assumes exists.

Demand forecasting: process profile
Dimension	What it reads on demand forecasting	Source
Exception variance	The title's own case is close to the modal one in a catalogue with real turnover, not a tail case. Of the algorithms one documented cloud forecasting product ships, only two are qualified to produce a prediction for an item with no direct history, and they work only when a separate item metadata file already exists connecting the new item to items with real sales - every other algorithm the same product offers has no history to fit and does not attempt a no-history forecast at all. That is a vendor drawing its own line between two different jobs inside one product, not a business choosing to treat new items as special.	AWS, Amazon Forecast Developer Guide, coldstart forecasting and dataset documentation
Volume	Not the size of the catalogue, and not units sold. What the documented product actually requires is data points per item: its own guidance recommends the majority of series carry more than 300 data points for its statistical algorithms, wants each series above 300 and ideally at least 1,000 for its deep-learning algorithms, and warns that testing against only 1 to 10 time series will often produce poor results outright. Below 5 data points a new item is silently dropped from coldstart processing unless the business explicitly tells the system not to drop it. A catalogue can be large and still fail this floor everywhere it matters, if most of what is on it is new.	AWS Samples, ForecastCheatSheet.md, amazon-forecast-samples repository
Cost of an error	Asymmetric by construction, and the two directions are absorbed by different parts of the business. The classical formalisation of this exact trade-off defines the per-unit cost of ordering one too many as the unit cost less what can be recovered in salvage, and the per-unit cost of ordering one too few as the margin foregone - sometimes inflated further to account for the ill-will of a customer who could not be served. A merchandising or inventory function absorbs the first kind of miss as a write-down; a sales or customer-facing function absorbs the second as a lost margin and, on the ill-will reading, a customer who may not come back. A SKU with no history makes both directions worse for the same reason: the formal trade-off assumes a demand distribution to solve against, and a new item has none of its own to supply one.	Gallego, 'The Newsvendor Problem', IEOR 4000 course notes, Columbia University
Reversibility	The forecast itself is free to revise at any time; nothing is committed by changing a number. What is not freely reversible is what the forecast triggers. In one major planning system's own documentation, converting a planned order into an actual purchase, transfer or production order is called firming, and a firmed order is also described as a released or open order - the language of something that has left the plan and become a real commitment. Reversing it afterward is not editing the plan back; it is cancelling the resulting order through its own separate, tracked workflow, and in some configurations the same system will not permit a confirmed order line to be deleted outright at all, only cancelled with a status record left behind. The window for a free correction closes at the firming step, not at the forecast.	Microsoft, Dynamics 365 Supply Chain Management, order-firming and purchase-order-deletion documentation
Regulatory exposure	Close to nil on the forecast itself, and the applicable standard says so by what it declines to cover. The operative auditing standard on inventory directs the auditor to be present and test the effectiveness of the physical count and the reliance placed on the client's representations about quantities and condition - a fact about what is actually on the shelf at the balance-sheet date. The same standard states plainly that it relates only to observation of inventories and does not address other auditing procedures. Nothing in it confirms, tests or attests to the number that decided how much would be on the shelf in the first place. A forecast is a probabilistic estimate about the future; what eventually gets checked by an outside party is a fact about the past.	PCAOB AS 2510, 'Auditing Inventories', paragraphs .01, .02 and .09
Vendor market maturity	Consolidating toward general tooling rather than maturing as a dedicated category. One major cloud forecasting product closed to new customers on 29 July 2024; its own transition notice states that the vendor will keep investing in security, availability and performance but does not plan to introduce new features, and directs customers instead to a general low-code machine-learning tool whose capabilities happen to include time series forecasting rather than a product built around it. Combined with the fact that the same discontinued product's coldstart capability worked through only two of its several algorithms and only with a maintained metadata file as a workaround, the honest reading is that no-history forecasting was never the vendor's core strength - it was a documented accommodation bolted onto a statistical engine designed for a different case.	AWS Machine Learning Blog, Amazon Forecast to Amazon SageMaker Canvas transition notice

Two of those rows carry the argument. The exception row says the no-history case is not a tail a system can shrug off, because a real, shipped forecasting product draws an internal line between items it can fit a curve to and items it cannot, and routes the second group through a different, weaker mechanism entirely. The reversibility row says the forecast is the cheap part of this process; the order it produces is the expensive part, and the expense arrives the moment that order is firmed rather than at any point while it was still a number in a spreadsheet.

The vendor-maturity row is the quiet one and it should temper expectations before anything else does. A category where a major vendor closes its dedicated product to new customers and points people toward a general tool is not a category with a settled, off-the-shelf answer for the hard version of the problem. It has a settled answer for the easy version - the SKU with real history - and an admittedly weaker, metadata-dependent workaround for the version this page is actually about.

Demand forecasting: the studio’s position

One claim on this page needs to be read with more care than the rest of it. It traces to one source only, the founder’s own account of a client engagement: an operating record, not a cited market statistic.

Named directly

The studio has built a second, more complete supply-chain system, for a different client than the one behind this pillar's other supply-chain pages, and the engagement's own account of scope confirms demand forecasting as work it actually did, alongside supplier onboarding and order fulfilment

Method The founder's observed pattern across the systems the studio has built and handed over; stated as operating experience, not a cited market statisticSample One client engagement, confirmed against the process list in this pillarPeriod As of August 2026Source Foxnut Studios engagement records (not externally retrievable)

What the studio's engagement records support, and what they do not
Number	What it measures	Period	Source
Named directly	The studio has built a second, more complete supply-chain system, for a different client than the one behind this pillar's other supply-chain pages, and the engagement's own account of scope confirms demand forecasting as work it actually did, alongside supplier onboarding and order fulfilment	As of August 2026	Foxnut Studios engagement records (not externally retrievable)

The record states which processes this second engagement reached, nothing more - not how the forecasting itself performed, how it handled the no-history case this page is about, or what it cost. Everything else stays unstated, because the founder did not supply it and this page does not infer it.

What this comparison usually gets wrong

The first error is treating the whole catalogue as one forecasting problem. A catalogue is really two populations - items with enough history to fit a curve to, and items without - and they need different arrangements, different accuracy expectations and different review discipline. A pilot run against the easy population and then extended to the whole catalogue will look excellent in the demo and fail exactly where the business needed help most.

The second error is measuring accuracy the same way on both populations. A forecast for an item with three years of seasonal history and a forecast for an item three weeks old are not comparable numbers, and blending them into one accuracy metric hides the population that is actually driving stockouts and write-downs.

The third error is automating the order alongside the forecast for new items specifically. The newsvendor cost is already asymmetric and already worse for a SKU with no history to estimate a demand distribution from; adding an automatic, unreviewed purchase order on top of an estimate with no track record turns a modelling weakness into a live commitment before anyone has seen whether the estimate was any good.

The fourth error is expecting a metadata-based workaround to close the gap to a real forecast rather than merely narrow it. Borrowing an analogue’s demand curve is a documented, shipped technique, not folklore, but it is still an assumption that the chosen analogue is actually similar, made before any sales exist to confirm or deny it. Treating a coldstart prediction as equivalent in confidence to a statistical forecast built on the item’s own history is the single most common way this category oversells itself.

The verdict

The evidence supports automating the easy population and putting a person, not a rule, on the order that follows a no-history forecast. Where a SKU carries enough of its own sales history to clear a forecasting product’s own stated floor, statistical forecasting is a mature, largely solved capability, and the honest first move is configuring what an existing planning system already includes rather than commissioning anything new. Where it does not, the choice narrows to which stand-in for history a business is willing to trust, and none of the four available stand-ins - a person’s judgment, a chosen analogue, a wait-and-switch policy, or a metadata-matched coldstart prediction - deserves the same confidence as a curve fit to the item’s own record.

The reason is structural rather than a comment on how good any particular product is. The exception row says the no-history case is common enough, in a catalogue with real turnover, that a shipped product routes it through a separate and weaker mechanism rather than treating it as noise. The cost-of-error row says the two ways this goes wrong are absorbed by different parts of the business and both get worse without a real demand distribution to estimate against. The reversibility row says the expensive step is not the forecast, it is the order the forecast triggers once that order is firmed - which is exactly why a no-history forecast belongs in front of a person before it belongs in front of a vendor.

For a team weighing this, the useful first count is not an accuracy percentage. Split the catalogue into items with a full season of sales and items without one, and count what share of revenue, not what share of SKUs, sits in the second group. A business where that share is small has a configuration decision to make on an existing system. A business where it is large is being asked to buy confidence in a number that, by the documented mechanics of every product that makes one, is borrowed rather than earned - and the honest next question is whether the analogue it would be borrowed from is one anyone would actually stand behind. share that new-SKU split, and the answer comes back plainly: a forecasting problem, or a merchandising one.

The part most pages leave out

When not to choose Foxnut Studios

Situations where another option is the better call, and where we say so in the first conversation rather than the fourth.

The catalogue, or the part of it under discussion, does not clear even the vendor's own stated floor for a working forecast: most items carry a thin run of sales, a new range turns over before any item accumulates a season's worth of data, or the count of items with real history is a handful against a catalogue of hundreds. The person already doing it, unchanged. One documented forecasting product states its own recommended floor as the majority of series carrying more than 300 data points for its statistical algorithms, warns that testing against only 1 to 10 series will often produce poor results, and drops any item with fewer than 5 data points from coldstart processing unless it is explicitly told not to. Below that floor, a human's judgment call is not a stopgap for a system that is not ready yet - it is the correctly scoped answer.
New items are not the exception in the catalogue, they are most of it: a private-label refresh, a limited drop, a fast-fashion range, or any assortment where the modal SKU has been on sale for weeks rather than years. A redesigned process, not an automated one. A system built to fit curves against historical demand is solving the wrong problem for a catalogue where most items never accumulate the history a curve needs; the design question stops being which algorithm and becomes which existing items are close enough analogues to borrow from, which is a merchandising judgment before it is a modelling one.
The intended use of the forecast is to fire a purchase order automatically once a threshold is crossed, with no review step before the order reaches a vendor. A human control point, or a rule that only ever proposes and never commits. Converting a plan into an actual order is a one-way step in at least one major planning system's own documentation - a firmed order becomes a real purchase order, and reversing it means cancelling that order through its own tracked workflow, not editing a number back to what it was. A forecast that is wrong costs nothing by itself; a forecast that is wrong and already converted into a live order costs the cancellation process, and in some configurations that same system will not let a confirmed line be deleted at all, only cancelled with a record left behind.
The business already runs an ERP or planning system with a built-in statistical forecasting module, has never turned it on, or runs it against a catalogue narrow and stable enough that the module's own stated limits do not bind. That module, and the studio says so. Statistical demand forecasting is a solved, shipped capability wherever a catalogue has the history to feed it; a business is more often the wrong side of a configuration decision than in need of a built system, and the honest first move is to check what the licence already includes.

Sources

Foxnut Studios works on briefs like this one from Bengaluru and Paris. If you want the shape of that before you talk to anyone, here is what an AI engagement covers and what you keep.