From State-Level Guesswork to Store-Level Precision: Granary
Grocery retail runs on thin margins and thinner shelf life. Granary forecasts, plans and grades assortment down to a single SKU in a single store - already live across an 11-store Mumbai pilot.
Grocery is one of the hardest categories to plan for. Margins are thin, a lot of the catalogue is perishable, and a chain the size of Smart Bazaar and Smart Point runs something like 12,000 SKUs across 4,000 stores - a combinatorial planning problem no manual process was ever going to solve well. Stock targets used to get set at the state level, one number applied across every store in that state regardless of what that specific store's shelves and customers actually looked like. Forecasting error sat above 55% before Granary, and decisions about what to keep, discount or delist ran on manual review with no consistent, auditable reasoning behind them.
Grocery retail also can't afford to get this wrong twice. Bad calls on perishables show up as shrinkage and waste almost immediately, and a chain running thousands of SKUs across thousands of stores needs a way to catch outliers - zero sales, negative inventory, unusually high days-on-hand - before they become a bigger problem, not after.
Granary is an agentic planning and assortment platform purpose-built for grocery, running forecasting, replenishment and category optimisation for Smart Bazaar and Smart Point. It's live today across an 11-store Mumbai pilot spanning ten segments of food and household and personal care, with a forecasting engine that's already cut prediction error roughly in half.
Forecasts 12,000 SKUs across 4,000 stores from a 48-million-row daily refresh on Databricks, and has already brought forecasting error down to 41% from a 55%-plus baseline.
Store-level, not state-level
Article-level stock targets get set per store through MBQ automation, replacing the old state-level manual approach that treated every store in a state the same.
A nine-reason classification system - inventory holding cost, discontinued product, quality defect, supplier reliability, and more - turns delisting from an ad hoc call into an audited one.
For a category manager or store-ops lead working through the Command Centre, a typical pass looks like this:
1. Open the Home screen and see exceptions first - zero sales, negative inventory, high days-on-hand, high markdown - surfaced automatically rather than buried in a report.
2. Check category performance: sales trend, gross margin, overstocked and understocked stores, drilling from format down to an individual store.
3. Review the assortment through Range Review, where SKUs are graded into demand and revenue bands and sorted into quadrants like Core Stars, Niche Premium, and candidates to Rationalize.
4. Select SKUs to delist, in bulk if needed, each one tagged with a reason code that feeds an audit trail.
5. Check shelf availability against a top-SKU checklist that's shared directly with store operations.
6. Behind all of it, the forecasting engine refreshes daily, so the next day's exceptions and recommendations are already waiting.
Granary runs as layers, from raw data up to an agentic decisioning brain:
Sales, inventory, supplier and loyalty data feed ML pipelines on Databricks, refreshed daily across the full SKU-by-store forecast.
Agentic layer (Cortex)
Assortment intelligence, forecasting, a rules engine and replenishment logic sit here - the actual decisioning brain behind what the Command Centre shows.
The operator-facing surface: category-manager, buyer and store-ops dashboards, an exception inbox, and a decision audit trail, with a handful of screens already live on real data and dozens more in build.
A digital mirror of the store itself - planogram, shelf, capacity, expiry - to simulate an assortment or layout change before it goes live on an actual shelf.
Still planning stock at the state level, not the store level?
Fill out the form
Share your contact information to get started
Speak to an expert
A member of our sales team will get in touch with you