Guides
Your Marketplace and Your Store Are Drawing From the Same Shelf
Two channels sell independently and draw on the same pile of units — which changes what the reorder question is asking.
Two channels, one pile of units
A marketplace listing and your own storefront are two demand streams. Different customers find them, different prices move them, and the same SKU can turn at a different rate on each. What they do not have is different inventory. Both decrement the same physical count in the same building.
That asymmetry is the whole problem: separate demand, shared supply. Demand behaves like two things. Supply behaves like one. Nearly every multi-channel planning mistake comes from applying the wrong shape to the wrong half, either splitting what has to stay pooled or pooling what deserved a separate decision.
The reorder question is about the pull, not the channel
A purchase order answers exactly one question: how many units leave the shelf, from all sources, over the period this order has to cover. The channel a unit left through is invisible to that question. What matters is that it left.
units to cover = combined daily pull × cover period − on hand − incoming
Plan each channel as a self-contained buy and you order the same cover twice. Each plan claims the same on-hand units, each carries its own full buffer, and together they purchase more protection than one pool of stock needs. Nothing flags it, because each plan is internally correct. They are only wrong about each other.
There is a second failure mode, and it is not a planning-method problem at all. It is a boundary problem. A forecast can only see the sales history it reads. Assisty forecasts what each product, and each variant, will sell over the horizon you choose, computed from the sales history it reads from your store, so the word combined holds only if both channels' orders actually land in that history. If one channel's orders never arrive there, they are not in the forecast either, and no choice of planning method recovers them.
That gap is dangerous specifically because it is quiet. Understated velocity is internally consistent: a low daily rate multiplied through the cover period yields a plausibly small order, and every downstream number agrees with every other one. There is no contradiction to notice. The shelf simply empties faster than the arithmetic said it would, and the arithmetic cannot tell you why. Pooling does not fix this, and neither does planning each channel separately. Only getting those orders into the history does.
| Dimension | Plan each channel separately | Plan the combined pull |
|---|---|---|
| What the plan covers | One stream's demand, twice | Every unit that leaves, once |
| Risk of double-buying | High — each plan claims the same on-hand units and carries its own buffer | Low — one balance, netted once |
| A stream missing from the sales history | Not visible — velocity reads low and stays internally consistent | Not fixed by pooling either — only getting those orders into the history fixes it |
| Where channel judgment lives | Buried inside two quantities that get added anyway | Held out separately, as a buffer and reserve decision |
Demand pools; consequence does not
Pooling is not just tidier bookkeeping. It is cheaper. Two demand streams rarely peak on the same day, so their combined variability is proportionally smaller than either stream's variability on its own. Buffer them separately and you pay for both peaks. Buffer the pool and you pay for one.
Suppose a SKU needs a 40-unit buffer to hold service on the marketplace and 30 on your own store. Buffered separately, that's 70 units of capital sitting still. Buffered as one pool against combined variability, the same protection lands closer to 50 — because both streams rarely spike together. The 20 units you free up are real money. But the 50 that remain sit in one pile, and nothing about pooling decides who gets the last one. (Illustrative numbers.)
That last point is where the channels stop being interchangeable. Demand pools. Consequence does not.
A stockout on your own store costs you the sale. It is unpleasant, and it is over. A stockout on a marketplace costs you the sale and then keeps charging. Running to zero can cost you Buy Box eligibility and see the listing pushed down or suppressed, and that visibility is not restored the moment stock is. Worse, if sync lag lets you accept orders you cannot fulfill, the cancellations land on your seller metrics, and marketplaces publish hard cancellation-rate thresholds measured over rolling windows with account consequences attached. Your own store keeps no equivalent scorecard on you.
So size the buffer on combined variability, then sanity-check that size against the channel with the worst penalty. Pooling sets the number. The strictest channel justifies it.
Reserving units is a decision, not a default
Channel allocation, deliberately holding back a defined reserve for one channel, is real practice. So is the display buffer, where you publish fewer units than you physically hold so that sync lag cannot oversell you. Both work. Both cost.
A reserved unit is unsellable everywhere else. Hold twenty back for the marketplace and your own store can stock out with twenty units of that SKU sitting in the building. A display buffer set too generously does the same thing more quietly: you look out of stock while inventory sits on the shelf, and the demand that walked away never appears in any report you will read.
Which means a reserve is worth taking only where the penalty asymmetry earns it. Protect the channel whose stockout outlives the restock. Let the other one absorb the variance.
| Step | What Assisty does |
|---|---|
| Forecast | Predicts sales per product or per variant over the period you pick — buying decisions happen at variant level, so do the forecasts |
| Flag | Marks which items run out before the period ends; at-risk items carry straight into the Smart Buying Table |
| Size the order | Computes a suggested quantity from sales velocity, lead times, and incoming stock — rounded to your case sizes, capped at your maximum stock levels |
| Encode your judgment | Tell Atlas how reality differs from the data and the table recomputes, with a was→now chip and per-row undo; nothing is committed until you create the order |
| Split by channel | Not a described capability — the reserve call is yours to make |
The loop is short, and the first step is yours rather than the software's: make sure every channel's orders reach the sales history your forecast reads, because that history is the only pull any of this can see. From there, forecast at the grain you buy at. Assisty predicts sales per product or per variant over the period you pick, and marks which items run out before the period ends. Check the buffer against your strictest channel rather than your largest one. Carry the at-risk items into the buy plan, where velocity, lead times, and incoming stock turn them into a quantity. Then apply the one judgment no arithmetic will make for you: which channel you can least afford to disappoint.