Operations Logistics

Inventory Forecasting for Marketplaces When Demand Is Spiky

Your forecast is not wrong because the math is bad. It is wrong because Indian marketplace demand does not arrive in a straight line.

Pull up a year of marketplace sales for any brand selling on Amazon or Flipkart in India and the shape is unmistakable. Long flat stretches, then violent vertical walls during sale events, then a hangover dip, then flat again. It is not a trend line. It is a heartbeat monitor. And almost every forecasting method a seller reaches for first is built to smooth that heartbeat into a comfortable average that is wrong on both the quiet days and the loud ones.

The cost of getting it wrong is not symmetric. Overstock ties up cash and racks up storage fees. Understock during a spike does something worse. It hands the sale to a competitor and, on platforms where availability feeds rank, it costs you the organic position you spent months earning. Spiky demand punishes the naive forecast far harder on the downside than the upside, and that asymmetry should change how you plan.

Why steady-state forecasting fails here

Most forecasting defaults to some version of a moving average. Take the last few weeks or months, smooth them, project forward. It is the logic baked into spreadsheets, into basic seller tools, into the gut instinct of anyone who has run a normal business. And on steady demand it works fine.

Indian marketplace demand is not steady. It is dominated by a handful of engineered events. Big Billion Days, the Great Indian Festival, Republic Day and Independence Day sales, Prime Day, end-of-season clearances. On those days a SKU can do a month of volume in seventy-two hours. A moving average treats that spike as either noise to be flattened away or, worse, as a new baseline to project forward from. Both readings are wrong. The spike is not noise and it is not the new normal. It is a known, dated, plannable event.

You are not forecasting demand. You are forecasting a calendar of events, and demand is what happens between them.

This is the mental shift. Stop trying to predict a single smooth curve. Start treating your year as a steady-state baseline with named, dated spikes layered on top, each one planned as its own mini-launch.

Separate baseline demand from event demand

The first practical move is to split your history into two pools. Strip the sale-event weeks out of your data entirely. What remains is your true baseline, the demand that shows up when the platform is not actively manufacturing urgency. Forecast that with whatever simple method you like, because on the quiet days a moving average is genuinely fine.

Then forecast the events separately, because they follow completely different rules. Event demand is driven by your deal acceptance, your ad budget, your discount depth, and your rank going into the sale, not by last week’s run rate. A SKU that idles at twenty units a day can do two thousand units across a four-day event if it lands a lightning deal and the ad spend is there. No baseline forecast on earth predicts that from the run rate. You predict it from the plan.

What goes into an event forecast

  • Last year’s same event, adjusted. Your single best anchor. Take the comparable event from the prior year and adjust for how much your rank, catalogue, and ad budget have changed since.
  • Deal type and visibility. A lightning deal or a featured placement multiplies volume far beyond a quiet listing discount. The slot you secure changes the forecast more than the price does.
  • Discount depth versus the category. Shoppers comparison-hunt hardest during events. Your relative discount, not your absolute one, drives conversion.
  • Planned ad spend through the window. Spike demand is partly bought. If the budget is not committed, the volume will not arrive, and you should not stock for it.

This is why event planning starts months out, not days out. The deep version of this for Flipkart’s flagship event is its own discipline, and we have written separately about planning inventory and ads for Big Billion Days well ahead of time precisely because the forecast and the inbound shipment have to be locked before the platform even confirms your deals.

Buffer stock is not a single number

The instinct after a stockout is to crank safety stock up across the board. Hold more of everything, always. That is expensive and it still does not protect you, because a flat buffer is sized for average variability and your variability is anything but average around events.

Buffer stock should flex with the calendar. For most of the year you hold a lean safety buffer sized to cover normal demand noise plus your replenishment lead time. In the weeks before a known event, that buffer expands deliberately to absorb the spike plus the forecasting error on the spike, which is large. After the event, it contracts again so you are not paying festive-season storage rates to warehouse units that will now sell slowly for two months.

The right buffer also depends on where your stock physically sits, because the fulfilment model dictates your lead time and your reaction speed. A unit in a platform warehouse converts to a sale instantly but cannot be repositioned quickly. A unit you ship yourself gives you control but adds days to every replenishment cycle. That tradeoff sits underneath every buffer decision, and it is the same calculation we walk through in the fulfilment math comparing FBA, Easy Ship and self-ship. Your forecasting and your fulfilment choice are not separate problems.

The asymmetry that should bias you

When you forecast a spike, you will be wrong. The only question is which direction, and the two directions are not equally costly.

Overstock on a fast-moving SKU going into a festive period is a cash and storage problem. Annoying, recoverable, and on a SKU that already sells, the excess usually clears over the following weeks. Understock during the same event is a different category of damage. You lose the immediate sales, you lose the deal slot you may not get back, and on Amazon especially you lose velocity at the exact moment the algorithm is watching hardest. The rank you drop can take weeks of full-price selling to climb back, which means a few days of empty stock quietly taxes you for a quarter.

We have argued before that the true cost of a stockout is mostly the ranking damage you cannot see on the invoice, and that argument is exactly why your event buffer should lean heavy. When the downside of one error dwarfs the downside of the other, you bias your forecast toward the cheaper mistake. For your hero SKUs during a major event, planned overstock is not waste. It is insurance priced correctly.

Quick commerce breaks the model again

Everything above assumes a marketplace where you ship into one or a few central warehouses. Quick commerce inverts the problem. Demand still spikes, but now it spikes locally and you are forecasting per dark store, where a single SKU’s daily volume is small enough that ordinary statistical noise swamps the signal. The buffer logic survives. The forecasting method does not. That is a distinct enough problem that we treat it on its own in forecasting inventory for quick commerce dark stores, and you should not assume your marketplace model ports over to it cleanly.

What changed recently

The last festive cycle made the case for event-led forecasting better than any argument could. On 22 September 2025, India’s GST 2.0 reform collapsed the old four slabs into a simpler structure and cut rates on more than two hundred items, deliberately timed to land with Navratri and the festive run. The effect on demand was immediate and uneven, exactly the kind of engineered spike a moving average cannot see coming. Consumer durables sales reportedly jumped forty to forty-five percent and e-commerce platforms were among the biggest beneficiaries, per Outlook Business. If you had stocked to last year’s run rate, you were short on the categories that moved hardest.

The platforms then converted that demand into record events. Amazon reported its Great Indian Festival 2025 drew over 276 crore customer visits with the highest-ever number of sellers recording a sale and seventy percent of traffic from tier 2 and tier 3 cities, per About Amazon India. Flipkart’s Big Billion Days 2025 leaned on the same tax tailwind and on Flipkart Minutes, with quick commerce reshaping festive delivery expectations rather than sitting beside the main sale, per Coresight Research. The deeper tier-2 and tier-3 pull matters for forecasting because it widens which SKUs spike and where, and it rewards brands that already understand how demand behaves beyond the metros.

Quick commerce kept compounding the local-forecasting problem too. Through 2025 Blinkit pushed past a thousand dark stores with plans toward two thousand, and Zepto crossed nine hundred on its way past eleven hundred by early 2026, per Akoi. Every new store is another node where your per-location forecast is thin, noisy, and unforgiving of a flat buffer. The platforms answer this with AI-driven demand forecasting and replenishment as core infrastructure, and brands selling into them need a matching discipline, not a spreadsheet.

Make the calendar the spine of the plan

The brands that get this right are not running smarter algorithms. They are running a discipline. They keep a rolling event calendar twelve months out, every platform sale marked, and they build the inbound shipment plan backwards from each event date through the inbound lead time so stock lands before deals go live, not during. They forecast baseline and events as two separate exercises with two different methods. And they accept that on hero SKUs in peak windows, a deliberate overstock beats a stockout every single time.

None of this is exotic. It is operational rigour applied to a demand curve that punishes anything less. This is the core of what our Operations & Logistics Management work does for a brand, and it sits directly alongside the Marketplace Performance and Advertising & Media Buying teams, because the ad budget and the deal slots are what create the spike you are stocking for. Forecast the calendar, not the average. Buffer for the event, not the steady state. The math only works when it respects the heartbeat.

Related insights

India's Commerce Engine

Put it
to work.

hello@zane.marketing

Book a meeting