AI in retail: what actually gets built inside a retail chain

Search for AI in retail and you get two kinds of page: a vendor explaining why its product is the answer, and a magazine explaining how a global chain uses AI. Neither tells you what happens inside a mid-sized chain with a few hundred stores, its own seasons and size sets, and a point-of-sale system the vendor has never heard of. I spent nineteen months inside one, leading the team that built its operating platform. This page is what AI in retail looked like from there.

The platform I ran for nineteen months

The business was an apparel chain with stores across several regions, selling through its own stores, its own online store and two marketplaces. The platform we built was its operating system: not the tills, but everything the tills feed. It grew to more than 45 domain modules, and the names of those modules are the honest map of what a retail chain actually runs on. Purchase orders. Cost of goods, and a flattened cost table for reporting. Debit notes. Stock transfers between stores, transfer requests, and the requisitions the point-of-sale vendor needed to move stock. Seasons. Size sets. Monthly targets per store. Zones and regions. Vendors and vendor-specific price sets. Custom tax rates. Barcode number ranges. Returns. Tickets and raised issues. Role-based access. Banners and logos for the storefronts. Report requests. Excel upload, because a chain runs on spreadsheets whether you like it or not.

Around that sat the outside systems the business already ran and was never going to replace for us: a point-of-sale vendor, two marketplace order aggregators, the online store platform, the accounting system, and a shipping aggregator. Each one had a workflow in our code for orders coming in, orders being updated, inventory syncing out, and stock transfers syncing back. Those integrations were the work. The modules were the vocabulary of the business; the workflows were where it broke.

A team of seven built on the architecture I laid down, and released on a version cadence, with the long-lived branch named for the release rather than a ticket. I owned the architecture, the split between the transactional database and a separate analytics store so reporting never slowed the tills, the AI layer that turned sales and stock data into answers, and every seam into the systems the business already ran. The how it runs page has the mechanics of that team model, including the release day where a change merged at 8:06, was reverted at 8:09, fixed, re-landed at 8:21 and released at 8:24.

What the data looks like before you are allowed to forecast on it

If you read the commit log of a live retail operation, most of it is not features. It is reconciling other people's data. Missing orders. Excess orders that arrived twice. Return logic that differs between the point-of-sale vendor and a marketplace. A customer name field that one system fills and another does not. Time zones. Pagination limits on a vendor API that had to be reduced, then increased, then batched, because the vendor's throughput was the constraint and not ours.

So before any model, the platform ran a set of scheduled jobs whose only purpose was to make the numbers agree with themselves. From the code:

• Track missing orders, nightly, in batches of 25 with five running at once, comparing what the order aggregators said they sent against what the platform held.
• Compare the transactional database against the analytics store, per sales channel, per week: order counts, item counts, total quantity. Every discrepancy written to a spreadsheet with the channel's name on it, because the person who fixes it works in a spreadsheet.
• A daily inventory snapshot at three in the morning, so stock levels have a history and not just a current value.
• Track inventory item levels into the analytics store, nightly, so the forecast reads from the same numbers the reports read.

Every job takes a lock with a one-day expiry before it runs, so a slow night cannot start the same job twice on top of itself. That is a small thing that saves you from a very confusing morning. The point of all of this is simple. A forecast built on unreconciled orders is confidently wrong, and a planner who has been burned by one will not trust the next one. The reconciliation jobs are the foundation of AI in retail, and they are the part vendors never show you.

The forecast, worked by hand first

The planning method I use inside a chain starts with a rule a planner can follow with a calculator, because a number nobody can reproduce is a number nobody will defend in a buying meeting. The worked version below runs on a representative sample dataset for one division over two months, forecasting the third. Every percentage is computed from that sample by the formulas shown; none of it is a client's live data.

Sell-through asks how fast stock is moving, using closing inventory as the denominator so it reads conservative:

Sell-through % = Sales ÷ (Sales + Closing inventory) × 100

On the sample, the division sold through 39.41 percent in the first month and 29.56 percent in the second, an average of 34.49 percent. Month-on-month growth was minus 36.04 percent, a seasonal dip. Gross profit held at about 50 percent in both months, the ledger-level margin, kept separate from the signal that actually drives the forecast.

That signal is profit against budgeted cost: how far sales ran ahead of the cost of goods the buy was planned against.

Profit % = (Actual sales − Budgeted cost of goods) ÷ Budgeted cost of goods × 100

The sample gave 41.32 percent in month one and 30.62 percent in month two. Weighted 35 to 65 toward the more recent month, that is 34.36 percent. The suggested number for month three is then month two's sales grown by that weighted signal. On the sample that lands above the seasonal dip, and that is the point: the forecast is not a straight-line revenue trend, which would keep falling. It grows the latest month by how far the division beat its planned cost, so efficiency, not raw momentum, earns a more confident plan.

Alongside the number, the sell-through tells the buyer how to spend it. Between 30 and 59 percent reads as selective: some styles sell and some do not, so the split is roughly 60 percent reorder of proven styles and 40 percent new. The system sets the total and the direction. The buyer makes the call on each style. That division of labor is what keeps planners using the tool.

The five feeds that make the number store-aware

Three signals build the number above: revenue, margin against planned cost, and sell-through. Enough for one division-level target, but it treats every store, region and week alike. It cannot see that one zone has a festival next month and another does not, that a flagship and a small-format store deserve different slices, or that a store opening on the tenth exists. Five small feeds fix that, and each one is shaped like the data the chain already has.

Then the market signals, each one a signed line a planner can see, question, or switch off: a planned price revision, an end-of-season markdown, an early summer pulling warm-weather styles forward, online demand the store-only history never counted. The plan reconciles line by line. Grade split and vendor rounding redistribute without changing the total; season, festival, price, markdown, weather, online and new stores each move it. A planner can read the whole path from last month's actuals to next month's plan and point at the line they disagree with.

When a model earns its place

Everything above is a transparent rule. With the feeds loaded, the same inputs feed models that learn the patterns the rule only approximates. Not one model: a ladder of three, and a division runs on whichever rung its data can support.

1. Statistical. Classic time series, level plus trend plus seasonality, with festivals and promotions as regressors. Fully interpretable. Needs about two years of history.
2. Gradient-boosted trees. Learns from every item, store and week at once, with the five feeds as features, and captures the interactions the rule cannot, such as festival by region by store grade. Returns the drivers behind each forecast. The default for most of the catalog once the feeds exist.
3. A deep model across the whole catalog. Returns a distribution rather than a point: a tenth-percentile floor, a median, a ninetieth-percentile ceiling. Safety stock is sized to the ceiling, not the median. Needs more history and more compute, and pays only on large assortments where availability precision matters.

No model is picked on faith. Each division is backtested on its own history, holding out recent months, forecasting them, and measuring the error. The lowest-error engine wins that division and is re-checked as data grows. A new line with two months of history starts on the rule and stays there until a model beats it on that division's own numbers. Two things never leave the planner's hands: the objective, whether the season needs service level, margin or working capital, and the constraints, minimum quantities, lead times, open-to-buy and display minimums, which the model optimizes inside and never around. And every forecast shows the factors behind it, because a forecast a planner cannot explain to the buying director is not a forecast.

Open-to-buy: the number that closes the loop

The plan is not the deliverable. The buy is. Open-to-buy resolves the sales plan, the stock you hold and the stock on its way into one number: how much you may purchase this month.

Open-to-buy = Planned sales + Planned closing stock + Planned markdowns − Opening stock − On order

On the sample, the sales target for the month and the purchase budget it implied were very different numbers, because the stock already on the floor and the orders already placed came off the top. That gap is the whole reason merchandise financial planning exists. The sales plan, the inventory plan and the markdown plan meet in one line, run every month, re-forecast in season.

The last piece is leadership's number. The organization commits one figure for the month, top-down. The system splits it across divisions by forecast weight and checks every slice against the bottom-up build. Where they agree, the plan is healthy. Where they disagree by a few percent, that gap is flagged and becomes the conversation before the buy, not after. Move one division up and the total stays fixed, so the difference is drawn proportionally from the others, and any division can be pinned so the rebalance flows around it. Adjust once at the top and every plan downstream re-runs to the buy.

The AI layer over the data

Two more things ran on that platform that most people would call the AI in retail, and both came last, after the reconciliation and the forecast.

The first was a web agent over the analytics store. A planner types a question, uploads a spreadsheet if the answer needs one, and gets a streamed answer with a generated chart, in a session that remembers what was asked before. It is a headless agent with tools behind it, not a chatbot with a database connection, and the difference is that it can run a query, check the result, and run another one before it answers.

The second was a stock-flow simulation: a warehouse feeding several channels, each with its own lead time, minimum display quantity, daily sales forecast per item, service-level target and capacity, with the supplier's lead time, minimum order and case-pack sizes as hard rules. Performance thresholds classify a channel as high or low performing against its forecast, and stock adjustments follow. A replenishment manager and a network optimizer run on top, and the output is stockouts, alerts and receipts per channel per day. Its job was to test a replenishment policy before it touched real stock. If a policy stocks out in the simulation at a 95 percent service-level target, it does not ship.

Where AI in retail is the wrong call

• The storefront chatbot. It answers questions and moves no stock. Spend the money on the forecast.
• A dashboard before the reconciliation. A beautiful chart of numbers that disagree with the point-of-sale report gets the whole project called into question.
• A model before the rule. If the planners have not seen the number built by hand and agreed with it, they will not trust a model that lands within a percent of it.
• A buyer who will not use the number. If the buying meeting runs on instinct and the forecast is decoration, fix the meeting first. No engineering changes that.
• Mid-migration. If the point-of-sale or the accounting system is being replaced this year, wait. Every seam you build will be rebuilt.

What a retail engagement looks like

The order is the one this page follows, and it is not an accident. Week one is the decisions file: the owner's rules about what may touch the live systems, which vendor is staying, what is not up for debate. The first weeks of building are reconciliation jobs, because nothing else is worth doing until the numbers agree. Then the forecast as a rule, worked with the planners on their own data until they can reproduce it. Then the feeds, one at a time, each one a line they can see. Then the models, on backtests, division by division. Then open-to-buy and the top-down reconciliation. Every week something ships that a real planner can open. The handover is a written contract of what shipped, what was deliberately not built, and who owns each piece afterwards. It runs the same way in every industry; the forward deployed engineer page is the role, the how it runs page is the week-by-week mechanics, and the owner's version is what it asks of you.

Common questions