Tecof • September 15, 2026
AI Demand Forecasting: How to Predict Stock Needs
In Brief
Demand forecasting is the work of putting a number on how many units a product will sell in an upcoming period, based on past sales and known external factors. AI did not invent this; it made it scalable. A shop owner can estimate demand for thirty products in their head, but not for three thousand. A model's value is not that it beats a human on a single product, but that it forecasts three thousand products every day with the same discipline. As of 2026 the question is no longer "can AI know demand" but "which method do we use for which product group, and what margin of error do we accept".
Tuesday morning, 09.15. The purchasing meeting before the November campaign. On screen: of 3,700 active products, 212 have been out of stock for two weeks, and those 212 accounted for 9 percent of total revenue in the same period last year. On the same screen, 340 products have been sitting in the warehouse for nine months, taking up space worth 18 percent of the rent. The purchasing manager sums it up in one sentence: "We bought too much of the wrong products and too little of the right ones."
The problem is not money, it is the decision method. Those 212 products were ordered by looking at last year's annual total; those 340 were bought because a supplier discount looked attractive. Neither decision had a forecast behind it, only instinct. Building demand forecasting is not about banning instinct; it is about making visible where instinct is right and where it is expensive.
What a Forecast Measures, and What It Does Not
Teams usually hold a quiet disagreement about what a forecast even is, and it surfaces at the end of the meeting. Settling the terms up front shortens every argument that follows.
Forecast, target and plan are not the same thing
- Forecast: the numerical expectation of what happens if you intervene in nothing. It is neutral; it is neither optimistic nor pessimistic.
- Target: the sales figure you want to hit. It can sit above the forecast; that is an intention, not an error.
- Plan: the work you will do to close the gap between forecast and target — ad budget, discounts, a new channel.
- Order quantity: forecast plus safety stock minus stock on hand minus stock in transit. It is not the same number as the forecast.
When these four blur together, this happens: the target gets used in place of the forecast and the warehouse fills to the target. When the target is missed, the excess stock stays, and nobody counts it as a forecasting error, because there was no forecast.
Which data do you start with?
Hunting for the ideal data set is the politest way of never starting. Three things are enough to begin: daily unit sales per product, whether the product was actually available that day, and price. Without the third you cannot strip out discount effects; without the second you cannot separate "it did not sell" from "there was none", and the model reads out-of-stock days as falling demand. That single detail is the most common mistake in first forecasting systems.
Horizon and granularity
The forecast horizon is set by your lead time. A store that receives goods from a domestic supplier in 7 days does not need a 90-day product-level forecast; 14 to 21 days is enough. A store bringing goods from the Far East in 60 days has to look 90 to 120 days ahead. The same logic applies to granularity: variant-level forecasting is the most valuable and the noisiest. A daily forecast is meaningless for a variant selling 2 units a week; aggregate to weeks.
The Real Difference Between Classic Methods and Machine Learning
AI is not the right answer for every product. Deciding which product deserves which method pays off more than picking a model.
Moving averages and exponential smoothing
The average of the last 4, 8 or 12 weeks works surprisingly well on steady sellers. Exponential smoothing adds the rule that recent weeks matter more. The advantage of these methods is transparency: you can explain where the number came from to the purchasing team in a minute. For most of the catalog that is enough, and it needs no model infrastructure at all.
Machine learning models
The gradient boosting family (LightGBM, XGBoost) is still the most practical option for e-commerce demand forecasting; deep learning only pulls ahead with thousands of products and a long history. These models earn their keep where several factors act at once: weekend effect, discount percentage, competitor price, weather, campaign day. None is decisive alone; together they are, and no human tracks that combination across three thousand products.
New products and slow movers
You do not forecast a product with no history, you draw an analogy: take the first 8 weeks of products launched in the same category, at a similar price point, under similar launch conditions. For slow movers (1 to 3 units a month) the average misleads; the question there is not "how many will it sell" but "do we accept the risk of running out".
| Product type | Example | Recommended method | Horizon | Expected WAPE |
|---|---|---|---|---|
| Steady best-seller | Basic tee, black | Exponential smoothing | 14-28 days | 15-25% |
| Seasonal | Coats, swimwear | ML + season variable | 60-120 days | 25-40% |
| Promo-sensitive | Electronics accessories | ML + price/discount | 14-30 days | 30-45% |
| New product | Launch collection | Similar-product analogy | 8 weeks | 50%+ |
| Slow mover | Edge sizes | Service-level rule | Lead time | Not measured |
Variables Specific to Turkey
The trouble with taking an off-the-shelf forecasting model as-is is that it was built around another country's calendar. Local correction makes more difference than model choice.
Campaign calendar and religious holidays
November campaign week, New Year, Valentine's Day, back to school and the two religious holidays are not all fixed-date events. Ramadan and Kurban Bayramı shift eleven days earlier each year, so a "same week last year" comparison gives the wrong answer around them. Feed the calendar to the model as days-until-holiday, not as a week number. Likewise, cargo flow changes in years when public holidays land midweek; keep that as its own variable.
The marketplace effect
Demand on your own site for products you also list on Trendyol and Hepsiburada moves sharply on marketplace campaign days. When a marketplace issues a coupon in a category, sales on your own site drop and the model reads it as falling demand. Include marketplace order data and campaign days in the forecast; forecasting the two channels separately and summing them is more accurate than a single blended forecast.
Lead time and shipping
Stock decisions are shaped as much by lead-time variability as by forecast accuracy. If delivery via Yurtiçi Kargo or Aras Kargo swings between 1 and 3 days while supplier lead time swings between 5 and 22 days, the real risk sits with the supplier. Measure the distribution of lead time, not its average: how many times in the last 12 months did this supplier run late, and what was the longest delay? We covered the operational side of that flow in our logistics and warehouse management guide.
Currency and price changes
When costs rise on imported goods, prices rise and demand falls. If the model does not see price as a variable, it learns the post-increase sales drop as "demand fell" and forecasts the next period low. Price and discount percentage are a mandatory input to a forecasting model, not an optional one.
Measuring the Forecast: What Error Is Acceptable?
An unmeasured forecast is no different from last year's spreadsheet. The step most often skipped at first setup is recording how the forecast itself performed.
WAPE, MAPE and bias
- MAPE: mean absolute percentage error. It explodes on low-volume products; forecasting 2 units on a product that sold 1 is a 100 percent error. On its own it misleads.
- WAPE: the sum of errors divided by the sum of actual sales. Because it is volume-weighted it is more useful in e-commerce; track this at catalog level.
- Bias: systematic drift. If the forecast sits consistently above reality that is positive bias, and your warehouse swells. Look at the direction of the error before its size.
The practical rule: get bias near zero before you try to lower WAPE. An unbiased forecast at 30 percent WAPE costs less than one at 25 percent WAPE that always drifts high.
Service level and safety stock
Safety stock is the insurance you buy against forecast error, and it is not free. The higher the service level you want, the more capital you tie up. The decision follows the product's margin and the cost of running out: alongside the lost sale there is the cost of sending the customer to a competitor.
| Service level | Safety factor | Chance of stockout | Suitable product group |
|---|---|---|---|
| 90% | 1.28 | 1 period in 10 | Long tail, low margin |
| 95% | 1.65 | 1 period in 20 | Standard catalog |
| 98% | 2.05 | 1 period in 50 | Best-sellers, high margin |
| 99% | 2.33 | 1 period in 100 | Hero products under active ads |
Safety stock is the factor multiplied by the variability of demand across the lead time. The longer the lead time, the larger the variability, which is why shortening lead time often pays off faster than improving the model.
Calculate what the forecast is worth
The value of a forecasting system shows up in two lines: revenue lost to stockouts and capital tied up in excess stock. Write both down monthly. To measure lost revenue, multiply the number of out-of-stock days by that product's average sales on in-stock days. For excess stock, total the cost of items that have not moved in nine months. If those two numbers are not falling, the model is not working, whatever WAPE says.
Turning a Forecast Into a Purchase Decision
A forecast is a number; it earns its value when it is attached to an action. This is where most projects break: the model runs, the dashboard looks good, and purchasing raises the order from a spreadsheet anyway.
The reorder point
The formula is simple: expected demand over the lead time plus safety stock. When stock falls below that level, an order is raised. Calculating this for every product is not a human's job; it is the system's. If product coding is messy the calculation is messy too, because the same product ends up with two codes and two stock records. A disciplined SKU structure is the invisible prerequisite of a forecasting project.
ERP and channel integration
A forecast that does not meet stock reality in the same place produces no decisions. Stock and purchasing data on the Logo, Mikro or Netsis side has to sit in one table with store and marketplace sales data. The hard part here is not the model but the mapping: if the table linking the ERP stock code to the marketplace barcode is wrong, the forecast will be wrong too. We explained how that link is built in our piece on APIs and integrations; a ready integration layer resolves the mapping at setup.
Automated alerts and actions with agents
The most practical use of a forecast is an alert, not a report. "These 14 products will run out within the lead time" does more work than a weekly forecast report. One step further is attaching the alert to an action: pausing ads on a product about to run out, drafting the supplier order, putting it in front of purchasing for approval. Provided the permission ceiling lives in the system rather than the prompt, that flow can be handed to AI agents; a human approves the decision, the agent does the preparation. We laid out the whole approach in our guide to agentic commerce.
Building Demand Forecasting in Thirty Days
Most demand forecasting projects die in data cleaning. The timeline below is ordered so that a team starting from zero reaches a system that produces decisions in the fourth week.
Days 1-7: extract the data and mark out-of-stock days
Pull 24 months of daily sales by product. Flag whether the product was available each day. Mark out-of-stock days as "unknown", not as zero demand. No model is built this week; the data is fixed. In categories with high return rates, use net sales rather than gross.
Days 8-14: classify products and build a baseline
Split the catalog into four groups by revenue and sales frequency. Assign each group the method from the table above. Produce a simple moving-average forecast for the whole catalog and measure its WAPE. That number is the bar every later model has to clear; if it cannot, a more complex model is unnecessary.
Days 15-21: add campaign and price variables
Add campaign days, discount percentage and days-until-holiday to the model. Work only on the first group, the products carrying revenue; trying to improve the entire catalog at once is the most reliable way to miss the fourth week. Compare WAPE against the baseline.
Days 22-30: attach it to the order decision and hand over
Calculate the reorder point and turn it into a weekly alert list. Send the list to purchasing and let a human make the call for the first two weeks. For every decision, record whether the list was followed and, if not, why. That note is the most valuable source of improvement next month and shows where the model is untrustworthy far more clearly than WAPE does.
Here is the job for tomorrow morning: list the products that went out of stock in the last 90 days, multiply each one's average daily sales on in-stock days by its number of out-of-stock days, and total it. That figure is the lower bound of the revenue a forecasting system could return to you this quarter, and it is the one number to use when arguing for the project. On an e-commerce platform where stock, sales and forecast data sit in one place, you do not have to redo that calculation by hand every week.
Frequently Asked Questions
How many months of history do you need to forecast demand?
Six months works for products with no seasonality. Seasonal products need at least two full seasons, so 24 months; with one season a model learns the trend but not the season. For products with short histories, leaning on the category average is safer than a bad model.
What error rate is normal?
There is no single right number; it depends on product type. For steady best-sellers, 15 to 25 percent WAPE counts as good, while 50 percent is normal on slow movers. What matters is not the absolute size of the error but its direction versus last month and how close bias sits to zero.
Should I buy a tool or build my own model?
If you are under three thousand products and your data is not in one place, collect the data first; the tool decision comes later. Building your own model is a commitment to ongoing maintenance: a model is not built once and left, it is re-measured every season. If nobody will own that maintenance, an off-the-shelf solution is the better call.
Why does the forecast break during campaigns?
Because a campaign day is a different world from the normal days in the history, and the model has not seen enough of them. The fix is to flag campaign days as their own variable and, where possible, manage campaign forecasting separately from normal periods. Ahead of a campaign, discount percentage is the single most decisive input.
Should I forecast marketplace sales together with my own site?
Forecasting separately and summing is more accurate, because demand behaves differently on each: price and promotions dominate on marketplaces, marketing and loyalty on your own site. But take the stock decision jointly; if the stock pool is shared, the forecasts must merge at the reorder point.
How do you forecast demand for new products?
By analogy: take the first 8 weeks of sales for the last 5 to 10 products launched in the same category, at a similar price point, with a similar promotion budget, and use the average as the starting forecast. Update it as the first three weeks of real data arrive; in a launch, the first 21 days tell you more than the model does.
Does a forecasting model also reduce excess stock?
Yes, but not on its own. Excess stock usually comes from minimum order quantities and supplier discount decisions rather than forecast error. The model tells you the right quantity; if the supplier says "500 units minimum", the decision is still a commercial one. The forecast makes the cost of that decision visible; it does not make the decision.
Who should own the forecast?
The purchasing or planning team. If the people who build the forecast are not the people who live with its consequences, the system is abandoned within a few months. The technical team supplies the infrastructure and the measurement; the commercial side decides which error is acceptable.
Is there anything to watch on data protection?
As long as forecasting works at product level it processes no personal data, and that is the healthiest setup. Once you move to per-customer personalised forecasting, privacy notices, processor lists and retention periods come into play. If you do not need customer identity for the forecast, aggregate at product level; data minimisation is better for both compliance and performance.
What should I do when the model gets it wrong?
Do not change the model on the strength of one bad forecast; models are good on average, not on single events. Once a month, review the twenty largest deviations and write down the cause of each. Most causes turn out to be in the data rather than the model: an unrecorded campaign, a mismatched product code, a bulk order that was returned.