Guides

New Products Have No Sales History. You Still Have to Buy Them.

The launch order is the one buy where the history column is empty — so you borrow the rate from something you've already sold, and you keep the window short enough to be wrong cheaply.

The one order you have to place before any data exists

Every reorder decision is downstream of history. Velocity comes from past sales, lead time from past deliveries, and the cover period bets that the near future resembles the recent past. Take the history away and the whole apparatus has nothing to grip.

That is the situation on the first order for a new product. The row exists, the supplier is quoting a minimum, and the column that would normally decide the number is empty. So the number gets picked another way — a round hundred, or the MOQ, which is the supplier deciding your opening position for you.

The reframe worth making: you aren't missing information. You're missing this SKU's history. Everything else is intact: the categories you sell into, the price bands that work, the seasonal shape of your year. A new product is new to your catalog, not to your market, and most of what you need to size line one already sits in products you've sold for months.

Borrow the demand rate from the closest thing you've already sold

The standard method for a no-history SKU is analogous forecasting: pick the closest comparable in your catalog and borrow its early demand pattern. This is planner practice you do yourself — Assisty doesn't select a comparable, store a link between two products, or copy one product's history onto another.

Picking well means matching on what drives volume: same category, same price band, same season or launch window, same channel mix. A ceramic mug launched in November tells you little about a travel tumbler launched in March. The nearest neighbour by demand behaviour beats the one picked by description.

Then adjust, don't copy. The comparable gives you a starting rate you deliberately move for differences you know about: a higher price point usually means a slower rate, and a line extension off a bestseller inherits more demand than a first product in a new category. Every adjustment should be a sentence you could defend out loud.

Finally, produce a range — conservative, expected, high — not a point, and write down which SKU you borrowed from. That note makes the estimate reviewable in three weeks instead of a number nobody can reconstruct.

DimensionThe first orderEvery order after it
Where the demand number comes fromA comparable SKU you chose and adjusted by handThis product's own sales history
How wide the error bar isWide by construction — it's a borrowed rateNarrow, and it tightens as history accumulates
What limits the downsideThe cover period you're willing to riskThe arithmetic itself, checked line by line
How often you look at itTightly, while the signal is still formingOn your ordinary buying rhythm
What you're actually decidingHow much you're willing to be wrong byHow much to buy

The launch order isn't a smaller version of a normal reorder — it's a different decision with a different lever.

Shorten the cover on purpose — the first order is a probe, not a bet

The arithmetic doesn't change for a new product.

first order = borrowed daily rate × cover period − on hand − incoming

For a launch, on hand and incoming are usually zero, which leaves two terms: a rate you borrowed and a window you chose. Only one is under your control, and it isn't the rate: that's a guess with wide error bars by construction. The cover period bounds how expensive being wrong turns out to be; a longer cover multiplies your error by more days.

So make it short on purpose. A short first cover buys you a second decision, made with real sales instead of borrowed ones. Scale into demand rather than committing your whole first-season position early.

Short has a floor, and the supplier sets it: lead time and MOQ. A cover shorter than lead time guarantees a gap before the next delivery lands: you're scheduling a stockout. (See matching the forecast horizon to lead time.) And an MOQ can exceed the cover you'd have chosen, in which case the honest move is to recognise you're taking a bigger position than you wanted.

In Assisty this is a row you adjust rather than accept. Every SKU in the Smart Buying Table gets a quantity you can check, adjust, and turn into purchase orders by hand or by conversation, with a was→now chip, per-row undo, and nothing committed until you create the order (buying-table.html). The four-line audit for any suggested quantity applies here too (how to spot-check a reorder suggestion in thirty seconds), but here the interesting line is the one you supplied yourself.

Worked example

Suppose the closest comparable in your catalog averaged about 6 units a day in its first month. The new product is priced higher, so you discount the borrowed rate to 5/day. Your usual cover on an established SKU is 60 days; for this one you choose 21. Nothing on hand, nothing incoming: 5 × 21 = 105 units instead of 300. If it sells at 9/day, you're reordering in week two with real numbers in hand. If it sells at 2/day, you're sitting on roughly 105 units rather than 300 — a correctable mistake instead of a season-long one. (Illustrative numbers.)

Hand over to the real forecast the week the data shows up

The borrowed comparable is scaffolding, and scaffolding has an expiry date. Its job is to hold up one order, not to become a permanent input.

Review it closely while it's live: creating that decision point was the whole reason you shortened the cover. Two things to check at handover, both producing the same failure mode: a parent total that looks right on top of a split that isn't.

First, variant mix. Buying decisions happen at variant level, so the forecasts do too — Assisty shows predicted sales per product or per variant over the period you pick (forecasting.html). Total demand can land close while the size or colour split doesn't. Mix ratios are steadier than individual variant volumes, so parent estimate × historical mix is a reasonable first cut — but only real weeks confirm it. (Forecast at the variant.)

Second, early-week distortion. Launch traffic or a promo inflates the first days into a rate no ordinary week reproduces. The opposite is quieter: after a sellout, zero-sales days look identical to days nobody wanted it, and drag the rate down. Assisty lets you exclude days you were out of stock, so the forecast reflects real demand rather than the days you couldn't sell (forecasting.html). Don't overcorrect off a handful of launch days in either direction (why sales history lies after a stockout).

StageYou supplyAssisty computes
Before any sales existThe comparable, the adjusted daily rate, and the cover period you're willing to risk — all decided outside the product, before you touch the rowNothing for this SKU yet; your first 30-day forecast appears as soon as your sales history syncs (forecasting.html)
The order itselfThe quantity itself — adjusted by hand or by conversationNothing velocity-derived for this SKU yet — the velocity-based suggestion (rounded to case sizes, capped at max stock) is what a SKU with history gets. What the row still gives you: the was→now chip, per-row undo, and nothing committed until you create the order (buying-table.html)
Once a few real weeks existThe judgment call on what's ordinary and what was a launch artefactForecasts per product or per variant over the horizon you choose, with out-of-stock days excludable; at-risk items carry straight into the Smart Buying Table (forecasting.html)

What the launch order asks of you, and what the product takes over once history exists.

Once a few real weeks are behind it, the SKU stops being special. It's forecast over the horizon you choose, flagged when it runs out before the period ends, and it arrives in the Smart Buying Table with everything else (forecasting.html). The comparable's job is finished: drop it and stop reasoning from it.

Buy the first order small, then let the data decide the second

Install Assisty and see your first 30-day forecast as soon as your sales history syncs.

Install on Shopify