MORI Reorder Tool

MORI is an award-winning brand on a mission to help families sleep better through sustainable, high-quality babywear. Bitcube has been a partner to MORI almost since the brand's inception — a key pillar of their growth, evolving from a technical service provider into a foundational part of their global operations. We provide a comprehensive team extension, embedding developers and QA engineers directly into MORI's day-to-day workflow, managing everything from daily store maintenance to high-level architectural innovation and migrations as platforms evolve.

Once a month, MORI has to answer one question: how many of each product do we order?

It sounds like a small question. It isn't. MORI sells through three Shopify storefronts, six Amazon marketplaces, retail doors, pop-ups, a marketplace partner and two wholesale accounts, with stock held in third-party warehouses in each region. Ten separate systems, each counting the same units in its own way. Before anyone can decide what to buy, somebody has to make all ten of them agree.

For years, that somebody did it by hand, in Excel. Three workbooks carried the entire process: a UK file of 28 tabs and 110MB, a US file of 14 tabs, and a roll-up where the two markets met and the buy was finally decided. Every cycle opened the same way. Six reports pulled, opened and pasted into the tabs feeding the top sheet. Then a planner read every line in both markets, checking what the forecast produced against what they actually knew about that product. Every line, because there is nothing downstream to catch a mistake: whatever number survives that review is the number that gets ordered and paid for. The review alone took a day per market.

By MORI's own estimate, roughly 95% of each cycle went into assembling the data and 5% into the forecasting decision itself. The expensive part of the job had become the part nobody was hired to do.

The files carried the wear of it. Supplier lead times and order minimums were kept in two places that had to agree with each other. A minimum-stock tab in each market file was wired to nothing at all, so the top-up it was meant to trigger happened by hand, or didn't happen. The proposed order quantity was generated by formula and then typed over, and the original figure vanished the moment it was overwritten. When the two markets were pasted into the roll-up, they went in as flat values, so nothing in the final buy linked back to where any figure came from.

That last part matters more than it looks. A buy gets argued about before it gets placed, and a number nobody can explain is a number nobody can defend.

The obvious response would have been to automate the forecast. It would also have been the wrong one. The forecast was never the bottleneck, and the judgement inside it is the part MORI's merchandisers are actually paid for. Supplier terms, cover targets, the seasonal shape of a category, the eight sanity checks applied before any quantity is accepted: those are decisions, not data, and they belong to the team.

The bottleneck was everything underneath. Ten sources that had never existed in one place, three of which keep no history whatsoever and answer only for the moment you ask them. Two markets forecast separately but meeting in a single purchase order, because a supplier's minimum applies to the combined quantity and neither market can be sized alone. And not one figure anywhere in the process that could be traced back to where it came from.

We didn't build a reorder tool. We built the data foundation underneath it, and the reorder tool was the first thing that foundation had to carry.

That distinction is the whole project. A tool solves the problem in front of you. A foundation solves the next four as well. Every object in this one is defined in a file rather than assembled by hand, so adding a sales channel means adding a connector and a handful of rows, and adding a forecasting method means putting it alongside the ones already there. Nothing about the reorder is welded into the layers beneath it, which is why what came after the reorder arrived so quickly.

Two of those channels offer no clean route in. The wholesale supplier portal is a web application built for people, so a browser drives it exactly as a person would. The UK warehouse sends its reports as email attachments, so a mailbox is scanned and every file parsed on arrival. Both would break if the other side changed something, so neither is trusted. Both are checked for freshness, every night.

Getting ten systems to agree turned out to be the real engineering. Amazon will tell you what changed last night quickly, or tell you what happened last year slowly, but never both at once, so the connector runs two readers: one keeping pace nightly, one walking the history backwards in thirty-day passes. One feed reports by its own internal option numbers and never states a product code at all, so its rows resolve on barcodes, then on a crosswalk built from the pairs its own sales prove. Products relaunched under new codes leave their stock and their entire trading history stranded on the old one, so both are brought forward onto the code in use today, and a relaunched line arrives carrying its predecessor's history rather than looking like a brand new product to be bought on nothing. Several systems report the same physical shelf in different terms, so each pool is now counted once, from the system that actually operates it.

Some history had already stopped existing. Three sources answer only for today, Amazon's ledger reaches back about eighteen months, the supplier portal holds thirteen rolling weeks. Each was recovered as far back as it serves, and daily positions were reconstructed where the feeds had never captured them. From here it is captured forward, every night, because there is no second chance at a day nobody recorded.

Everything that survives all of that is reduced to three simple shapes: what sold, what is held, and what is on its way. Each carries the product, the market, the channel and the day. It sounds almost too plain to mention, and it is the entire trick. It means a figure means the same thing wherever it is read, by whoever reads it, and it traces back through every layer to the feed it came from and the day it arrived.

The flow runs one way only. Nothing writes back into those tabs, so a spreadsheet can never overwrite a measured number. The team keep every decision and lose the ability to accidentally corrupt the data, which is the right way round and the opposite of how the old workbooks behaved.

The output lands in Google Sheets, for the same reason. Not a dashboard, not a portal, not a new system to learn. The proposal, the shortfall against both minimums, the cover the order would give, the closing position it leaves behind, each surfaced as a view with the team's own columns beside it. They filter to the market, month or supplier they want, and nobody has to build a report for them.

Three are genuine candidates. A SKU curve takes a product's own seasonal shape and grows it month by month. A class curve does the same with a category's shape, for a new line with too little history of its own. And TimesFM, Google's forecasting foundation model, is called directly with no model fitted at all.

The other two exist to be beaten. One is simply what the line sold in the same month last year, lifted to this year's level. The other takes the three months before the cycle and holds them flat. Neither will ever be the buy. They are the bar and the control, and any method that cannot beat last year's month or the run rate held flat has not earned the cycle.

We replayed thirteen historical cycles and put every method beside what actually sold. MORI's own arithmetic won. The SKU curve scored best on the lines the buy turns on, and it is the one in use. Every cycle is stamped and kept, so a method is judged on what happened rather than on what it promised, and the choice can change whenever the evidence does.

The foundation stood complete in development three and a half weeks in. Moving it into production went one domain at a time: product, then stock, then sales, then intake, then the month, then the forecast, then the buy. Each was compared against MORI's own August cycle before the next one opened, line by line rather than on totals, because totals hide exactly the errors you need to find. A domain closed only when it landed within five per cent of the buy the team had made by hand. No threshold was loosened to get anything across.

So the same foundation carries an AI agent that answers in plain English. Which lines drove last month across the marketplaces. How a day of trade read against the stock behind it. Which sizes are sitting. What a wholesale account took, and when it landed. Questions somebody would otherwise have written SQL for, or waited a week on a report for.

It is grounded in MORI's own vocabulary, with every column described in their words rather than a glossary the model invented. It runs as the person asking, with their access and no more. Asked something the data cannot answer, it says so, rather than answering off the nearest column that looks close enough.

The reorder itself sits deliberately outside it. The buy and the forecast are numbers a purchase order is placed on. Those are computed and checked, never generated.

And nothing ties the foundation to that one agent. MORI point Claude at the same data for their own analysis, and the next thing the team asked for was building their own views the same way. Whatever answers the question reads the same numbers the buy reads.