How to Forecast Component Demand for Product Bundles
A component's real demand is its own sales plus every bundle that contains it. The calculation, worked, and the reorder mistakes bundles cause without it.
A component sold both on its own and inside two bundles has three demand streams feeding one stock number. Forecast the streams separately and you will order for that stock number three times. Forecast only the product page and you will order for roughly two thirds of what the shelf actually loses.
This post is the arithmetic for that, worked end to end. How Shopify represents bundles and decrements component stock is covered in the bundle inventory management guide; this one assumes the decrement happens and deals with the buying decision it creates.
Why bundles break a forecast
Every forecasting method on this site starts from a column of past unit sales for one SKU. That works because, for an ordinary product, the sales column and the stock movement are the same event counted once.
A bundle severs that. The gift box sells as a gift box, and a candle leaves the shelf. If your planning routine walks the product list and forecasts each row from its own history, the candle gets planned from the candle's row and the gift box gets planned from the gift box's row, and nothing in that routine notices that the second row spends the first row's stock. The candle stocks out while your forecast, computed correctly, says it should have had five weeks of cover left.
The candle's sales column and the candle's stock movement stopped being the same number the day you launched a bundle containing it.
The calculation
Component demand = standalone unit sales + the sum, across every bundle containing it, of (bundle unit sales × quantity of the component per bundle)
Straightforward to write down. Two conditions have to hold before the sum is true, and both are easy to miss.
The standalone figure must be standalone. If the number you are calling standalone sales already includes units consumed by bundles, adding the bundle term counts those units twice. This is the single most expensive mistake in the topic, because it is invisible: the total looks bigger, bigger totals feel safer, and the over-order arrives before anyone questions the method. Which kind of number your report gives you is the subject of the section after next, and it is worth settling before you calculate anything.
All the histories must cover the same period, after the bundles launched. Bundle sales usually displace some standalone sales rather than adding cleanly on top. Suppose the candle sold 40 a week before you launched a twin pack, and now sells 35 a week while the twin pack draws 10 a week. The bundle added 5 units of real demand, not 10; the other 5 came out of the standalone column. Take a pre-launch standalone history of 40 and add today's full bundle draw of 21 and you get 61 a week against a true 56, roughly 9% high, which is 60 surplus units a quarter and $420 of cash at a $7 unit cost. Use post-launch figures for both halves and the displacement is already handled, because it is baked into the standalone number you are reading.
The awkward case is a bundle that has not launched yet, where no post-launch history exists. There you have to estimate what share of the bundle's sales will be new demand rather than displaced demand, and be explicit that it is an estimate. Assuming full additivity is the aggressive end of that range, not the neutral one.
A worked example
One component, two bundles, twelve weeks. Cedar & Fig, 250g sells on its own, sits in the Cedar & Fig gift box (one candle per box), and sits in a twin pack multipack (two candles per pack).
- Standalone: 34, 36, 33, 35, 36, 34, 35, 37, 34, 36, 35, 35. Total 420 units, 35 a week.
- Gift box: 6, 14, 9, 22, 5, 12, 8, 18, 7, 11, 10, 10. Total 132 boxes, 11 a week, one candle each.
- Twin pack: 4, 6, 5, 7, 3, 5, 6, 4, 5, 6, 4, 5. Total 60 packs, 5 a week, two candles each.
Component demand = 420 + (132 × 1) + (60 × 2) = 420 + 132 + 120 = 672 units in twelve weeks. That is 56 a week, or 8.0 units a day across 84 days, against the 5.0 a day the candle's own sales suggest.
units sold on its own product page
units consumed by the two bundles
units that actually left the shelf
true units a day, against 5.0 standalone
Week by week, the gap moves around more than the averages suggest.
| Week | Standalone | From bundles | Total |
|---|---|---|---|
| 1 | 34 | 14 | 48 |
| 2 | 36 | 26 | 62 |
| 3 | 33 | 19 | 52 |
| 4 | 35 | 36 | 71 |
| 5 | 36 | 11 | 47 |
| 6 | 34 | 22 | 56 |
| 7 | 35 | 20 | 55 |
| 8 | 37 | 26 | 63 |
| 9 | 34 | 17 | 51 |
| 10 | 36 | 23 | 59 |
| 11 | 35 | 18 | 53 |
| 12 | 35 | 20 | 55 |
The standalone column never once reaches 38. The real weekly draw peaks at 71 in week 4, because the two bundles are erratic and the candle is not. A component's variability is inherited from the bundles it sits inside, which is why a stable SKU can start behaving like an unstable one without anything about the product changing.
Now the double count, in the same numbers. If your candle figure already includes bundle-driven units, it reads 672 and not 420. Add the bundle term anyway and you plan for 924 units, 11 a day, 37.5% more than the store consumes. Over one twelve-week cycle that is 252 surplus candles, $1,764 of cash at a $7 unit cost, sitting on a shelf because a stream was counted twice.
Getting the data out of Shopify
Pulling and cleaning a sales history is its own job, covered in forecasting demand from Shopify sales data. Bundles add one question to that process, and it has to be answered before the numbers mean anything: is the component figure in front of you standalone-only, or does it already include bundle-driven units?
Shopify documents that component inventory levels are reduced when a bundle sells. What we could not find documented on Shopify's bundles pages is how a bundle sale is attributed in the product sales reports, and the answer may well differ between Shopify's own Bundles app and the third-party bundle apps. So do not take a general answer, including this one. Test it:
- Note the component's current available quantity and its units sold for the day.
- Place one real order for a bundle containing it, for a known quantity.
- Check the component's available quantity moved by the amount you expect.
- Check the sales-by-product-variant report for the same day and see whether the component's unit count moved too, or only the bundle's.
If the component's sales figure moved, your report is already giving you combined demand and the bundle term would be a double count. If only the bundle moved, your component figure is standalone and the calculation above applies as written. Ten minutes, once per bundle app, and it settles the question for your store rather than for a hypothetical one.
One more thing to strip out while you are in the export: weeks when the component or the bundle was unavailable. A stockout looks exactly like zero demand in a sales report, and a bundle that could not be sold because a different component ran out produces a zero on this component too.
Reorder points for components
Nothing about the formula changes. The reorder point formula takes average daily sales, lead time and safety stock; a bundle component just feeds it a different first input.
Cedar & Fig, 250g, on a 12-day lead time with a 30-unit buffer:
- Standalone demand only: (5 × 12) + 30 = 90 units.
- Combined demand: (8 × 12) + 30 = 126 units.
The 36-unit gap between them is four and a half days of real demand at 8 a day. A trigger set at 90 does not fail loudly; it fires four and a half days late, every cycle, and the buffer absorbs the difference until a slightly heavy bundle week arrives and it does not. That is the pattern behind most bundle-related stockouts: not a wrong method, a right method fed one of the three streams.
Two practical notes. Set the trigger on the component, never on the bundle, because the bundle holds no stock of its own to trigger against. And recalculate the component's rate whenever a bundle containing it is added, retired or repriced, since each of those changes one of the terms in the sum.
Promotional bundles
A bundle promotion is a demand spike on every component at once, and the components feel it very differently. Estimating the size of the uplift is covered in promotions and inventory forecasting. What matters here is how it lands.
Say the gift box runs at 40 a week for two weeks instead of 11. The candle's draw goes from 56 a week to 85, an increase of about half. The wick trimmer inside the same box has no standalone sales at all, so its draw goes from 11 a week to 40, close to four times. The component with the least standalone demand takes the largest relative hit from a bundle promotion, and it is usually the cheap one nobody watches.
Two rules follow. Convert the promotion into component units before you order anything, not into bundle units. And check the lead time of every component against the promotion date, because the one that cannot arrive in time caps the whole thing regardless of how much of everything else you bought.
When a component is the constraint
Shopify derives bundle availability from the component products' inventory levels, and the product with the lowest inventory level determines how many bundles can be sold. In planning terms, one component owns the ceiling for the whole bundle, and buying more of anything else does not raise it.
With 210 candles and 64 trimmers on hand, you can sell 64 gift boxes. Another 200 candles changes that number not at all. So the review order for a bundle runs by cover and lead time rather than by value: work out how many weeks of cover each component has against its combined demand, sort ascending, and the top of that list is the bundle's real constraint. It is often the cheapest line in the box, which is why it rarely gets reviewed first. Watching that number fall before it bites is the same job as predicting stockouts before they happen, applied to a component rather than a product.
Keeping three streams, two bundles and one stock pool aligned in a spreadsheet is doable for one bundle and gets ugly fast. StockCue's forecasting is bundle-aware on every plan including Free: bundle sales flow through to component demand, so the component's reorder point is calculated against everything that drains it rather than against its own product page.
Frequently Asked Questions
How do I calculate total demand for a product that is sold alone and inside bundles?
Add the component's standalone unit sales to the unit sales of every bundle that contains it, multiplied by how many of that component each bundle uses. A component selling 420 units on its own over twelve weeks, plus 132 gift boxes using one each, plus 60 twin packs using two each, has a true demand of 672 units, not 420. Two conditions have to hold for that sum to be right: the standalone figure must not already include the bundle-driven units, and all three histories must come from the same period, after the bundles launched.
Do bundle sales show up in Shopify product sales reports?
Check it in your own store rather than trusting a general answer. Shopify's bundles documentation states that component inventory levels are reduced when a bundle sells, but we could not find a statement on those pages about how the sale is attributed in product sales reports, and the behaviour may differ between Shopify's first-party Bundles app and third-party bundle apps. Place one test order for a bundle, then look at whether the component's unit count moved in your sales-by-product-variant report. That single test tells you whether your component figure is standalone-only or already includes bundle demand, and everything downstream depends on knowing which.
How do I set a reorder point for a bundle component?
Use the same reorder point formula you use for everything else, with combined demand as the daily sales input rather than standalone demand. For a component drawing 672 units over 84 days, that is 8 units a day, so a 12-day lead time gives 96 units of lead-time demand plus your safety buffer. Using the standalone rate of 5 a day instead would set the trigger at 60 plus the buffer, which fires after you have already crossed the real one.
What happens to the other components when one runs out?
The bundle stops being sellable, because Shopify derives bundle availability from the component products' inventory levels and the product with the lowest inventory level determines how many bundles can be sold. The other components keep whatever standalone demand they have, and the units you bought specifically to sit inside the bundle stop moving until the missing component is back. That is why the component with the longest lead time deserves the earliest reorder trigger, not the one with the highest sales.
STOCKCUE
Adding up three demand streams by hand every buying cycle is the step that quietly stops happening. StockCue's forecasting is bundle-aware on every plan including Free, so a component's reorder point already accounts for the bundles that spend it.
Install StockCue on Shopify →