A mid-sized retail chain in Saudi Arabia with 50 stores, 12,000+ SKUs, and around SAR 800 million annual turnover was running replenishment on spreadsheets, with weekly reviews and the judgment of planners. Six demand planners took a look at history, talked about what “felt right,” and generated purchase orders for each category. That process worked pretty well for stable items, but it went out the window when it came to the things that matter most in retail: seasonality, promotions, shifting Ramadan timing, store-level demand variation, additions to the product line, and unanticipated shifts in what customers want to buy.
The result was a familiar, but costly cycle. As a consequence, 8-12% of SKUs were out of stock at any time, leading to an estimated SAR 15 million in lost sales. Meanwhile, the company had also accumulated almost SAR 40 million in stagnant stock. Promotions skewed baseline demand. Some stores ran out, others had piling up. Organizing stock transfers between stores is done via phone calls and WhatsApp messages, rather than a structured system.
At aTeam Soft Solutions, we developed an AI agent for demand sensing, store-level forecasting, auto-replenishment, and inter-store transfer optimization. The system integrated machine learning, dual-calendar-seasonality modeling, promotion-aware demand corrections, and natural-language explanations that planners could really trust. The result was quantifiable: stock-outs dropped to 2.1 percent. Excess inventory of slow-moving items dropped 35 percent, and the retail chain had its best ever, achieving its greatest Ramadan preparation cycle to date.
Before we designed anything, we took the time to learn how the client’s replenishment process worked in real life. None of what we discovered, team, was broken. It was a team overwhelmed by trying to run a very large retail business using tools and techniques that were far too simple for business complexity.
The retailer had a presence in the form of 50 stores spread across 8 cities in Saudi Arabia with offerings in consumer electronics, home appliances, and accessories. That added up to 12,000+ SKUs on paper. In real operations in practice, that translates into 600,000 SKU-store pairs, if you consider every product individually in every store. No group of humans can run that with accuracy on weekly spreadsheets and intuition, no matter how experienced they are at planning.
The demand planning team consisted of around six people. Each week, they’d analyze category sales, assess current inventory, review recent promotions, and make a manual decision about what to reorder. Their method is basic: look at what sold the previous month, look at what’s in stock, and order what they need based on averages and a little experience. That’s fine working for slow-moving industries. It was not in a large retail chain where demand shifts by store, by week, by product life cycle, by type of promotion, and even by religious or national events.
A planner might be saying, “This item sold 100 units last month, so I’ll order 100 for the coming month.” But that reasoning overlooked a few things the company had already learned to be true:
The implications for operations appeared in every aspect.
A quota of between 8 and 12 percent of all SKUs was out of stock somewhere in the system at any given time. That doesn’t mean every out-of-stock item was as important, but it does mean that shoppers routinely found themselves in stores or on the web and were unable to get hold of products they had been planning to buy. The company projected lost sales of approximately SAR 15 million annually due to stock-outs alone.
And the company had too much inventory in the wrong places at the same time. SAR 40 million was tied up in slow-moving inventory. Some of them, between 3% and 4% of inventory, became obsolete every year and had to be written off or heavily cut back. This is a classic retail planning failure mode: too little of what is selling now and too much of what sold then before.
Ramadan, Eid, back to school, and Saudi National Day only intensified the problem. These seasons brought real category uplifts, and yet the current process didn’t cater for that properly. One planner may know that TVs go well before Ramadan, another may be bullish on kitchen appliances, and another might overcompensate because they ran short last year. The buying was uneven as a result. Some of the categories were understocked just as demand peaked. Others were severely overbought and then sat in warehouses after the event.
Promotions caused yet another distortion. A product might spike 300% on a campaign and then drop 50% off the shelf, but the replenishment process was manual, and often the promotion spike was rightly accepted as the new normal. That resulted in over-ordering immediately after these promotions concluded. The team was aware that this issue existed, but they had no real way to isolate promotional lift from baseline demand.
Variation at the store level was also being ignored. The chain was in effect overplanning at the central level. A store in a crowded mall had traffic and attachment sales patterns that were radically different from those of a store in a residential neighborhood. A store near a university was different still, particularly as to gaming accessories, laptops, and seasonal electronics. And replenishment decisions were frequently made as if the company had a more homogeneous network than it really did.
Intra-store transfers were the most obvious evidence that the system was reactive. A fast-moving item sold out in one store, so someone phoned another store to enquire if they had some in stock. If they did so, the teams would work out a manual transfer. There was no organized optimization, no ranking of which store should send stock, and no system-level consideration of whether moving stock away would create another shortage in the coming week.
That was the daily reality. The planners weren’t failing because they weren’t trying hard enough. They spend their days doing something no spreadsheet-driven weekly process can do at scale: predicting 600,000 inventory decisions across a market fragmented by local seasonality, promotion noise, shifting religious calendars, and inconsistent store behavior.
And that was the problem aTeam Soft Solutions was addressing. Not only better forecasting in theory, but also a real, practical AI auto-replenishment system that can run at the real scale of the retailer’s business.
The obvious solutions were already tried by the client.
They had an RP with a native demand planning module, but it was based on simple moving averages. That’s fine for steady, repetitive demand. It’s not sufficient for consumer retail in Saudi Arabia, where demand fluctuates with promotions, new product launches, local events, weather, and the Hijri calendar. A moving average is not able to differentiate between a genuine increase in demand and a transient promotional distortion. It can’t understand that the Ramadan timing shifts from year to year. It can’t tell that a store needs to stock a product more heavily in one store than in another.
They also reviewed a SaaS demand planning application. The problem was not that the software was badly made. It was just that it anticipated cleaner data and more stable historical patterns than the client had. Many SKUs did not have three years’ worth of dependable history. Many were new products, short-lifecycle accessories, or seasonal launches. The tool also failed to manage Saudi-specific seasonality properly. Gregorian-based seasonality models cannot capture Ramadan, Eid, and Hajj demand fluctuations unless they have a specific Hijri calendar model integrated into the system.
Manual capacity planning also had a hard limit. Six planners cannot perform any deep analysis of 600,000 SKU-store combinations with spreadsheets and meetings. They basically end up averaging the problem out to the category level, which is what caused all sorts of issues for the business in the first place.
And this is why the retailer didn’t want “better reports.” They wanted an AI agent that would sense demand in real-time, justify forecasts, recommend orders, and ultimately execute routine replenishment with human supervision. This was an actual AI-demand-forecasting-retail problem, and it had to be solved as an operational workflow, rather than as a machine learning model in a vacuum.
We developed the system in stages, as the demand planning teams do not trust automation just because it has a good accuracy score. They trust it when they can compare it against their own judgment, understand why it is recommending something, and know that it is sensible during critical business periods.
The first ten weeks were devoted to consolidating data and building out forecasts.
We ingested POS transaction history, pricing history, promotions data, product master data, store metadata, new product launches, and store opening and closing records, along with weather data. In that, it gave us a much more complex picture than the planners ever had before. The system was looking at more than just ‘what sold last month’ as it was looking at the context of when those sales happened.
We developed the demand modeling at the SKU-store level, not just nationally. This was one of the radical shifts in design. The AI agent predicted sales at the store and product level, so a gaming accessory store near a university, a high-end product in a high-class residential area, or a mall-based product line could all perform differently within the model.
The forecasting logic was threefold, referring to daily, weekly, and monthly seasonality, but most importantly, it processed commercial Saudi Arabian timing. We added a dual-calendar FE layer so the models could learn both Gregorian patterns as well as Hijri-aligned events. Ramadan, Hajj, Eid, and other Islamic-calendar patterns were explicitly modeled rather than being labeled as random demand outliers. That’s a big difference that was made.
We also simulated promotion lift and post-promotion drop. Rather than blindly learn from spikes in data, the system treated base demand and campaign-driven uplift separately. It also factors in price elasticity, product lifecycle stage, and cannibalisation. If Product A was on sale, the model could understand that Product B, which is similar, could sell less in that period rather than thinking that both are on the rise independently.
During this stage, the AI agent did not buy orders or create POs. It was just forecasts, and the forecasts were put in the same place as the planners’ manual forecasts. It was a matter of trust. Planners got to compare the AI forecast to what they would have ordered and track where the system was more conservative, more aggressive, or more context aware.
We also included natural language explanations. That turned out to be critical. A planner could tell not just that demand was going to increase but why: Ramadan begins in three weeks; traditionally, this category grows 40% in the first week, this store is above average in last year’s performance in this category, and the item is also scheduled for a promotion. That’s the explanation layer that turned the model into a collaborator rather than a black box.
In the next step, we generalized the AI agent from forecasting to replenishment policies.
Using the forecasted demand, the system computes the recommended order quantity for each SKU-store combination, taking into account on-hand and on-order inventory, safety stock, supplier lead time, minimum order quantity, and relevant category constraints. For certain products, it also factored in the lifecycle and the risk of holding slow-selling stock. This is where the project became a practical retail demand planning AI agent instead of just a forecasting project.
The recommendations were then consolidated by the supplier to generate purchase orders in a commercially viable manner. There is no point in computing optimal store-level quantities if the consequent purchasing plan is unaware of freight economics or minimums for orders from suppliers. Thus, the AI agent balanced local demand requirements with supplier-side purchasing efficiency.
Demand planners took a look at the recommended POs in the dashboard. Routine items were good to go with one click. High-priced, rare, or strategically sensitive items could be examined more closely. For the 500 best-selling SKUs—the group that accounts for some 60 percent of revenue—the system entered a phase of automatically generating purchase orders after a few weeks of demonstrated accuracy. Planners still received a daily digest, but they no longer had to manually assemble those orders line by line.
This is where the first big productivity wins showed up. The planners stopped wasting their efforts on mundane replenishment work and began focusing and spending more energy on supplier negotiations, category strategy, and exceptions management.
When replenishment was stable, we turned to inter-store transfers, which were previously handled via phone calls and reactive coordination.
The AI agent was keeping real time track of stock in all 50 stores. When it anticipated a stockout at one location and found surplus inventory of the same SKU at another store, it produced a transfer suggestion. It did not just consider today’s shortage. It had also considered whether the source store was itself likely to be running short of that same stock in the near future; it was examined if the transfer distance was reasonable; and finally, if the risk of lost-quarter was worth the logistics cost.
That matters a lot because the wrong transfer optimization can go fix one shortage by creating another. So the system factored in anticipated near-term demand forecasts at both the source and destination stores when it made a transfer recommendation.
After approval, these transfer recommendations became action items in day-to-day operations. Pick lists were created at the source store. Delivery assignments were issued to the logistics players. What had previously been reactive coordination from store to store turned into a systemic balancing of inventory.
This stage had brought much more into the inventory system. The company no longer thought just in terms of what was in each store. Instead, it was thinking about how its whole retail network could prevent customers from losing sales.
In the final stage, we generalized the system to promotion-aware and externally informed planning.
Marketing promotions were a built-in part of the forecasting module. When a promotion was planned, the AI agent would modify demand forecasts for that product at the relevant SKUs and at the store level. It also modeled post-promotion demand depression, which is among the most common causes of retail overstocking following a successful campaign. When a promotion brought demand forward in time, the system subsequently diminished replenishment recommendations thereafter.
We then incorporated external signals that include competitor pricing on leading Saudi e-commerce platforms, social media trend indicators, and schedules for new product releases from top brands. These did not replace internal sales history, but they did make the sales prediction model more responsive in categories where market movement counts, notably electronics and accessories.
Seasonal pre-positioning was strengthened significantly as well. The AI agent started adjusting inventory six to eight weeks before Ramadan, considering the Hijri-based demand patterns, store-level category performance, and the latest sales indicator. This was one of the highest commercially valuable components of the project because Ramadan preparation is where the old system had consistently generated the most both in lost sales and overstock.
For aTeam Soft Solutions, this is what made the rollout a concrete demonstration of AI inventory optimization that Middle Eastern retailers can use in practice. It wasn’t just statistical accuracy. It was about tying forecasts to ordering, transfers, promotions, and real calendar activity down in the region.
The system was implemented using a Python FastAPI backend with Airflow to manage the data pipelines. POS sales, product information, promotion calendars, price history, inventory quantity, and external signals were fed into a structured environment in which both historical model training and live replenishment logic could run dependably.
The time-series sales data was saved in TimescaleDB to allow for efficient processing of large SKU-store time histories. The rest of the operational data, such as product characteristics, supplier constraints, inventory status, transfer recommendations, and purchase order logic, was handled by PostgreSQL.
For prediction, we employed a combination of Prophet and LightGBM. Prophet managed interpretable trend and seasonality components well, particularly when augmented by custom calendar features. LightGBM enabled modeling of intricate interactions, like effects of promotion, lifecycle, and store-specific nonlinear patterns. We didn’t try to do everything with one model. Distinct categories, different problem types demanded distinct strengths.
The Hijri-Gregorian model layer was one of the most significant aspects of implementation. Every sales transaction was represented in both calendar systems, enabling the models to learn the recurring religious-season demand pattern even though the Gregorian dates were shifting every year. This was crucial since an agentic AI inventory management Saudi Arabia wouldn’t cope with Ramadan as a regular off-the-shelf seasonality logic would depict correctly.
Claude was used in two high-value layers: interpreting promotion effects and explaining forecasts. We learned that planners accepted suggestions far more quickly when the AI agent could say, in plain English, why demand was changing. That made the system much more usable for the daily operations.
The React dashboard unified it all together. Planners view forecasts, confidence intervals, PO recommendations, transfer recommendations, and the reasoning for each recommendation. SAP integration enabled the generation of approved purchase orders directly within the ERP, and also the receipts and the inventories were looped back into planning to keep the system up-to-date.
In aTeam Soft Solutions, we consider this as a fundamental design rule for enterprise forecasting systems: the model is crucial, but the workflow layer is what makes it a functioning AI agent within the business.
The Hijri calendar challenge turned out to be the most region-specific technical issue on the entire project. Ramadan moves forward by about 10-11 days each year on the Gregorian calendar, which implies that standard seasonal models trained on Gregorian dates only cannot properly learn Ramadan patterns. We solved this by introducing dual-calendar features and Islamic holiday flags. This had now become the fundamental part of the forecasting engine, rather than being an optional adjustment.
Promotions were yet another challenging area, since not all promotions work the same way. A 30% discount on a high-end TV generates a very different demand curve than a buy-one-get-one offer on a cheap throw rug. We trained promotion classifiers for types, percentage discount, bundle, flash sale, gift-with-purchase, and more, and modeled lift uniquely for each category. Without this, the machine would have mistaken promotional spikes for real baseline growth.
New products created the classic cold-start issue. Approximately 20% of SKUs had less than 8 weeks of sales history at any point in time. Conventional forecasting methods generally don’t work in this space. We fixed this with a similar-product bridging technique. The AI agent, after determining the category, brand, price point, and other attributes, the agent identified similar products and used their historical demand patterns as a prior until sufficient actual sales data was available.
We also had to be careful to manage human adoption. Early on, planners gave us a very useful rule: a forecast that is a little less accurate but well understood is often more useful operationally than one that’s more accurate but feels like a black box. That’s the feedback that changed the design. Explainability turned a nice-to-have into a core product requirement.
The stockout rate was reduced from 8-12% of SKUs to 2.1%. That single change transformed the experience for customers across the network and recaptured an estimated SAR 11 million a year in lost sales when products were out of stock.
Slow-moving stock was reduced by 35%, which released around SAR 14 million in working capital. Equally important was that the write-offs of obsolete inventory came down from 3-4% to 1.5% per year. That meant the company was not just carrying less excess inventory — it was carrying the wrong inventory less often.
Forecast accuracy greatly increased. At the level of SKU-store-week, WAPE is around 82%, compared to approximately 55% from the prior manual approach. For a network of this size and assortment complexity, that was a major operational improvement.
Approximately 70% of the routine replenishment orders are now generated automatically with a demand planner review, which redefined the planning team’s role. Each planner is now responsible for approximately twice the number of SKU categories as before, not because they are working harder, but due to the repetitive forecasting and PO generation tasks being offloaded to the AI agent.
Store-to-store transfers became a meaningful performance lever, rather than an emergency workaround. The system now handles more than 200 transfers a month and recovers about SAR 500,000 each month in sales that would have been lost to local stockouts.
The most compelling evidence was generated during Ramadan 2025 preparation. With 89% category-level forecast accuracy, the AI agent started pre-positioning inventory six weeks in advance. It was the finest-ever Ramadan sale in the company’s history, said the retailer, because of the right availability of crucial categories at the right stores in the right amounts.
For aTeam Soft Solutions, this result is what makes the project a prime example of AI demand forecasting for retail done well in Saudi Arabia. The business didn’t just receive better forecasts. It got lower stockouts, fewer dead stocks, and quicker replenishment, enabling better transfers and greater seasonal execution.
The solution incorporated Python and FastAPI to provide backend services, leveraging Prophet and LightGBM for demand forecasting, Claude for promotion impact analysis and natural language explanations, PostgreSQL and TimescaleDB to hold operational and time-series data, Redis to coordinate tasks rapidly, React.js for the planning dashboard, SAP integration for purchase order generation and inventory synchronization, AWS EC2, RDS, and S3 for infrastructure and storage, SageMaker for model training, and Airflow to orchestrate forecasting and replenishment pipelines.
The biggest takeaway was that forecast accuracy is not the only KPI that matters.
In the beginning, we focused heavily on improving the numbers. That was necessary but not enough. The planners were quite explicit about the fact that they had to understand the recommendation; they couldn’t just be given it. When we introduced the forecast in plain language explanations, trust jumped quickly. The planners were able to understand why the model predicted increased sales and when it was responding to promotions, seasonality, or store-specific patterns.
We also realized that Middle East regional retail forecasting is required to have local calendar intelligence embedded within the solution from day one. Seasonality Hijri-aware is not just a reporting overlay. It should be present at the feature level within the model.
Finally, we also found that the best AI agent for planning is the one that integrates the forecast, replenishment, transfer, and promotion workflows into a unified operating loop, and that’s in fact true. A forecasting model is nothing but interesting. An AI auto-replenishment system that alters inventory outcomes is what really matters to the business.
Retail chains in Saudi Arabia and the UAE, along with broader Middle East retailers, are often aware they have issues with stockouts and overstocks, but they commonly underestimate how much of this is driven by the planning structure versus the effort of the planner. When replenishment is still based on averages, gut feel, and assumptions at the category level, the company continues to pay twice: once for lost sales and once for excess inventory.
At aTeam Soft Solutions, we design and develop end-to-end solutions where an AI agent manages store-level forecasting, replenishment recommendations, transfer logic, and promotions-aware planning with a human in the loop. That’s how retail planning teams can go from spreadsheet-driven reaction to ongoing, explainable inventory control management.
