On 29 September 2026, I spoke with the Retail Innovation Council’s Q3 Technology and Innovation ExCo about a transformation programme for a grocery chain. The business took on the same problem twice: first through a traditional programme that ran for more than a year without getting a working tool into stores, and then through a new approach that put the first tools in teams’ hands in six weeks.

The retailer and the problem had not changed. The way we worked had.

The problem with the old programme

The business wanted to improve range planning: which products each store carries, how much stock it holds, and when it reorders. Best-sellers were running out while slow-moving products occupied shelf space for months.

The first attempt followed a familiar sequence. Teams spent months discovering and defining the problem, reviewing vendor proposals, watching demos, and running proofs of concept. Each stage waited for the previous one. By the time a solution was ready to reach a store, the business context and the people involved had already changed. The programme had consumed more than a year, but nothing useful had reached the shop floor.

This is a costly way to learn. A long specification can describe what people believed they needed months earlier. A proof of concept can look convincing without changing a single decision in a store.

Use AI to shorten the learning loop

AI changed the cost and speed of trying things. We could work through data, store feedback, and operational evidence faster, then build a small version of a tool and put it in front of the people who would use it.

Instead of treating discovery, definition, development, and delivery as one long line, we ran them as short loops. Each loop started with an outcome, tested an idea on real work, captured feedback, and either improved it or moved on. Several workstreams could progress at once. Going back to change something no longer meant waiting months for a formal change request.

The point was not to ask AI to make every decision. It was to make each decision cheaper to test, so that business teams could see what worked before a large programme was built around it.

Break one broad request into practical decisions

We turned the range-planning problem into three questions:

  1. Which products should a store stop stocking?
  2. What is the right minimum stock for each product in each store?
  3. What replenishment rule should determine the next order?

Those questions led to three pieces of work: a delist tool, a minimum-stock tool, and an ordering tool. Each could be tested against a specific business decision instead of waiting for one large system to be completed.

Start with the delist tool

The delist tool began identifying products that a store should stop carrying. It was live by 7 July. At first, merchants rejected around two-thirds of its suggestions. We treated those rejections as useful information, captured the reasons, and used AI-assisted analysis to improve the rules behind the recommendations.

Over the following weeks, the rejection rate fell from 66% to 20%. The important part was not that the tool made a recommendation. It was that the team could understand why people disagreed and use that feedback to make the next version better.

Set minimum stock with review built in

The minimum-stock tool went live the same week. It flags when a store’s minimum stock for a product appears too high or too low compared with what sells. Regional and national teams review changes before they become rules in SAP.

We did not try to solve every product category at once. We started with best-sellers, where a wrong stock level has a visible impact and the results are easier to check, then planned to work through the long tail.

Simulate replenishment before launch

The ordering tool was at a different stage. It was not live. Before building it, we asked the business team to write down its replenishment strategy. We then used AI to simulate that policy across 106 stores. Every result could be traced back to the clause in the policy that produced it, so teams could see what a proposed rule would do and revise it before deployment.

That distinction matters. A simulation is not a live tool, and a projected result is not a measured outcome. The simulation gave the team a faster way to test its policy before committing to an implementation.

What changed in six weeks

By the end of the first six-week cycle, the project team reported that product availability had improved from 95% to 98.88%, stock held had fallen by 20%, and fresh-food waste had fallen by 50%.

These figures came from this specific project. They are not a forecast for every retailer or a guarantee that AI will produce the same result elsewhere. They show what the team reported after focusing on a real operating problem, getting tools into use quickly, and improving them with feedback from the people responsible for the decisions.

Change the way the team works, too

The project’s operating rhythm changed along with the software. Review meetings were transcribed, and AI helped turn the discussions into actions with an owner and a date. The team did not have to rely on separate spreadsheets for status updates or build another presentation for every leadership review.

That mattered because a faster development cycle is only useful if the organisation can keep up with it. Teams need to see what is changing, make decisions, and act on the information while it is still relevant.

The lesson for retail transformation

AI does not remove the need to understand stores, products, customers, or the people doing the work. It can make it faster and less expensive to examine evidence, test an idea, and change course. That creates room for a different kind of transformation: smaller outcomes, shorter feedback loops, and fewer months spent waiting for a finished system before anyone can learn from it.

The question is not only how quickly a team can build software. It is whether the team can put a useful change into the hands of the business, see what happens, and make the next decision with better evidence.

Same business. Same problem. A different way to run the transformation.