# 78 spreadsheet tabs ran a business, and nobody had written down how > How a wholesale distributor moved off a single shared Excel workbook onto a real order system, without losing the rules that lived only in its cells. Source: https://redbumerang.com/en/case-studies/order-system/ Process AI / wholesale distribution One workbook, one tab per delivery date, no formulas anywhere in it. The business ran correctly every day on rules that lived in the arrangement of cells and in somebody’s memory. *Client anonymised. Measured against the workbook, the migration output and the data model, 6 September 2026.* ## The problem A single Excel file ran a live wholesale distribution business, and the rules it enforced existed nowhere else. One workbook. Seventy-eight tabs, one per delivery date. Under each date, customers grouped by delivery leg; under each customer, the day's order typed as free-text shorthand — 2x pečen pršut polovice, 1# panceta narezek 100g. The scheduling lived in the same cells as the orders, as notes to whoever was reading: na 14 dni — every fortnight. klicati ob petkih — call on Fridays. klicano — called. poslan SMS. dostava JUTRI. There were no formulas in it. Not a single one, across all eighty sheets — and six cell comments in the entire workbook. That is the whole of the documentation. This matters more than it sounds. A rule inside a formula is at least written down; you can open it and read it, however awkwardly. These rules were not written anywhere. They lived in the layout of the sheet and in the habits of the people who used it. The business ran correctly every day on knowledge that existed only in the arrangement of cells and in somebody's memory. And because it was one shared file, one person could safely edit it at a time. It also grew by one tab every working day. Seventy-eight was simply where it had reached. On that trajectory the file would have carried more than three hundred worksheets by the end of the year — a single workbook nobody could open, search or reason about, getting worse at a fixed rate with no natural stopping point. The practical consequences were the ones that cost real money: - Nobody could answer "who do we call today?" Each customer's calling rhythm was real, but it existed only as a pattern in past orders. It had never been written down, so it had to be remembered. - No view of a customer across days. Every sheet was a day; a customer's history was scattered across seventy-eight of them. - No record of who changed what, and no way for two people to work at once. ## What Red Bumerang built The workbook was read end to end, the rules were recovered from it, and the result was rebuilt as an application several people can use at once. Not a spreadsheet with a better front end. A system with a real customer and product master, three roles, order and call statuses, holiday handling, printing, analytics, and an audit entry for every change. 363 customers. 111 products. 1,581 orders. 3,888 order lines. All recovered from free text that had never been structured. The part that answers the question nobody could answer The calling rhythm was reconstructed from the order history. Every customer had one. None of them was recorded. So each customer's past orders were analysed for a recurring pattern, and where one existed clearly enough, it became a schedule. Of 335 customers with order history, 174 were given a recurring calling schedule. 153 had too few orders to judge, and 8 showed no pattern at all — and are reported as such rather than assigned a guess. The application now builds each day's call list from those schedules, shifts it around public holidays, and lets staff dismiss a call once without breaking the pattern. "Who do we call today" is now a screen rather than a memory. The discipline the system imposed Orders had been prose. Now they are items. Nothing in the workbook checked what anyone typed. An order line was whatever the operator felt like writing that day — the same product described three ways by three people, with no code tying them together. The rebuilt system does not accept prose. Every line is entered against the real product catalogue through a searchable picker, with a cut and a pieces-to-kilograms conversion attached, so an order in pieces and an order in kilos are the same record. That constraint is doing more work than it appears. A business cannot analyse what it has not standardised, and no amount of reporting built on free text would have produced a usable answer. Disciplining the input was the precondition for everything downstream — the call list, the analytics, the per-product view. The 21.2% we deliberately did not automate The parser reads shorthand like 8x kulen narezek 500g 4kg and turns it into a structured line — product, quantity, cut, and the conversion between pieces and kilograms. It flagged 823 of 3,888 lines — 21.2% — as needing a human to look. That is a deliberate design decision, not a shortfall. Slovenian order shorthand is genuinely ambiguous: kom and kos are each both a unit of count and a word describing a cut. A parser that resolved those silently would be wrong on some unknown fraction of a live order book, and nobody would know which. So it flags instead of guessing, and every line keeps its original text. A system that tells you which fifth of the data to check is worth considerably more than one that hides its uncertainty. ## Where the AI actually is None of it runs at inference time. All of it was in the building. The running system is deterministic: rule-based parsing with a confidence score, a histogram-based schedule detector with fixed thresholds, ordinary application code. Nothing calls a model. What AI did was the archaeology. It read an undocumented workbook and a price list, worked out the domain and the data model from them, wrote the parser's rules, designed the schedule-inference logic, and built the application. That is the honest version and it is the stronger claim: AI recovered the rules a business had been running on without writing down, and then built the system that enforces them. The result runs predictably, every day, without a model in the loop. ## The rules nobody had written down Two examples that surfaced only because the whole file was read: - The same product existed under two article codes — a five-digit code and a nine-prefixed six-digit version of the same thing. Anyone reading a single sheet would see two products. They had to be merged into one. - Two branches of one retail chain shared a single customer code, and had to be kept apart by name and sub-code — otherwise two separate delivery relationships collapse into one. Neither was written down anywhere. Both were being applied correctly every day by people who knew. ## Method What the numbers count. 78 dated sheets is the workbook's own content, February to May 2026 (80 worksheets in total, two of them not order sheets). The customer, product, order and line counts are the output of a single deterministic migration pass over that workbook. 21.2% is the share of order lines the parser flagged for review. The schedule figures cover the 335 customers that had order history. What is not claimed. No time saving, cost or return figure is published, because none was measured. No study of the manual process exists from before the rebuild. The build is described as taking days on the owner's account; no precise figure is given, because the version history cannot support one. Scope. One client, one workbook, Slovenia. In production and in daily use. --- ## Bring us a process, or a market. Every system here started as a conversation about work that was already happening — how it actually runs, where it costs the most, and what the order underneath it looks like. That is the first meeting.