[All systems](https://mybb.ai/systems/) # Stock and sales data *the team can act on.* Stock and sales information from the chain’s existing systems turned into recommendations the team reviews, decides on and records. Client A fashion retail chain Industry Fashion retail Connects to The chain’s retail management system, read-only ## What we built - The evidence layer - The recommendation engine - The working views The system, drawn with sample data. We never show a client’s own screens. ## 01 Overview The chain’s stock and sales already lived in its retail system. The analyst we built reads them and suggests what to reorder, move between stores or mark down. Each suggestion comes with its evidence, and a person makes the call. 01 ### The evidence layer Versioned readings of stock and sales, with how fresh and complete each source is. 02 ### The recommendation engine Fixed calculations and a rule book the chain approves, so every figure can be traced. 03 ### The working views A worklist, advice cards and stock, rule and catalogue screens, on desktop and phone. ## 02 The challenge Repeat orders were decided after the stock ran out. Repeat orders were decided too late, so best-sellers ran out before new stock arrived. Each decision was put together by hand from the chain’s system, and the knowledge sat with a few experienced people. Stock history was a monthly export, which cannot show how long an item was missing from a shelf. ### What the client wanted to achieve #### Decide in time Advice arrives while a repeat order or a move is still possible. #### Evidence on every card Every figure links back to its reading, its rule and its run. #### A person always decides Nothing is ordered, moved or closed by the system itself. #### Rules as settings The team changes any business value on the rule screen, without a developer. ### How it worked before - Repeat orders decided after stock ran out - Broken size ranges found store by store - Stock history kept as a monthly export **What we found** The chain’s system keeps no past stock balance for an item that did not sell, so it cannot say how long a shelf stood empty. We built a recorder in the chain’s own cloud that reads all stock twice a day. ## 03 How we built it 1. 01 **Mapping how decisions get made** We rebuilt the buyer’s own rules from his working notes and a discovery of more than 85 questions. 2. 02 **Every engineering decision first** A decision map settled the hard questions before any code, each one written down. 3. 03 **Prototyping the risky parts** The transfer method, the order of the evidence and the wording of the AI explanations, each tested on its own. 4. 04 **The screens, early** The worklist and the working views were built ahead of the engine, so the team could react to them. 5. 05 **A read-only link to their system** Readers built against a copy of the chain’s system, plus a recorder in the chain’s own cloud that keeps every stock reading. 6. 06 **The engine at full scale** Repeat orders, transfers, markdowns, carry-overs and findings, tested on a chain of the real one’s size. 7. 07 **The rules, reworked with the buyer** A working session with the buyer replaced several first-draft rules with his own. ## 04 How it works **How a sale becomes advice** The engine reads the chain’s data, checks it, runs the calculations and hands a person ranked advice. 1. Step 01 **Read** **Stock and sales** Read-only, from the chain’s own system. **Stock history** A recorder keeps every reading. 2. Step 02 **Check** **Fresh and complete** Stale or partial data stops the advice it affects. **Blank is not zero** Missing, invalid and zero are kept apart. 3. Step 03 **Calculate** **Sell-through and sizes** Per store and per colour, from fixed calculations. **One transfer plan** No unit is promised twice. 4. Step 04 **Decide** **Ranked advice** With its evidence and its limits. **Recorded** Accept, change or decline, and what was moved. **Repeat order** ### Reorder in time Raised as soon, now or urgent, while there is still time to produce. **Transfer** ### Move it where it sells Units from the logistics centre or another store, with quantities per size. **Markdown** ### Mark down what is slow Items that have stopped selling, with the readings that show it. **Findings** ### Learn for the next buy Excess by size or colour, and lessons for the next purchase. ### Every assessment ends in one of five answers - Advice - Nothing needed - No feasible action - Does not apply - Could not assess ## 05 The outcome Each morning the team opens a ranked worklist: what to reorder, what to move and where, what to mark down. Every card carries the readings and the rule behind it, a person accepts, changes or declines it, and what was done is recorded. | Before | After | | --- | --- | | Conclusions put together by hand | A ranked worklist, each item with its evidence | | Repeat orders decided after stock ran out | Advice raised while there is still time to produce | | Broken sizes found store by store | Transfer lines with quantities per size | | Decisions kept in people’s heads | Every decision, note and rule change recorded | | Monthly stock snapshots | Stock read twice a day, with gaps in the data shown | ## 06 Key figures **17.1 s** for a full analysis of a chain this size, inside a one-minute budget **0** numbers written by the AI in 74 explanations: every figure comes from fixed calculations **A full analysis, at the real chain’s size** Seconds. The budget is one minute. Budget **60 s** First pass **39.6 s** Now **17.1 s** ## 07 Technology What the system runs on, for the technical reader. Cloud AWS, in the chain’s own account Containers Managed PostgreSQL AI Claude, for the written explanations only Data PostgreSQL Prisma A job queue A read-only link to the chain’s retail system How we build Next.js NestJS TypeScript Vitest Playwright Python prototypes ## 08 What comes next Next, the chain’s real stock and sales history is loaded in, and the team reviews real advice cards before the pilot begins. ## 09 About ### About the client A fashion retail chain with its own production, selling through its stores. We name a client only with their permission. ### About MYBB MYBB builds systems around how a business already works. We diagnose it with MYBB ROIQ, build the system, launch it with the team and keep running and improving it. [All systems](https://mybb.ai/systems/) ## Questions about *our work.* **Can you build something like this for my business?** Each system here was built around one business. Answer the 10 questions, and within 48 hours your growth plan shows what we would build for yours. **Why don’t you name the clients?** We name a client only with their permission. Until then, each system is described by the kind of business it serves. **Are these the real screens?** They are redrawn with sample names and numbers. We never show a client’s own screens or data. **My business is in a different industry. Does that matter?** No. We start from how your business works, not from a template for its industry. **Will we have to replace the tools we use?** We start with what already works. The system may keep some of your tools, connect them, and add what’s missing. **Who decides what the AI does?** We agree with you where AI helps and where a person reviews, decides or approves. Those rules are part of the blueprint. **Who runs the system once it’s built?** We do, with your team. We keep running it and improving it as your business changes. **How is the price set?** By the scope, the connections and what the rollout needs. The price is in the blueprint, and nothing is built before you approve it. [Your data, turned into decisions.](https://mybb.ai/start/) We build on the systems your stores already run, so the team acts on stock and sales with the numbers in front of them. Tell us what your chain needs. [Start with MYBB ROIQ](https://mybb.ai/start/) Prefer to talk first? Email [welcome@mybb.ai](mailto:welcome@mybb.ai) --- Source: [A fashion retail chain | Our work | MYBB](https://mybb.ai/systems/fashion-retail/)