Case study 02 · Custom apparel supply-chain platform
A good business, an untouchable system.
Nothing wrong with the business itself. What capped it was a system nobody could safely touch, and the thirty-two people working around that system. They came to us asking whether to rebuild it. We told them not to. Six months later that team was twenty people, not one line of the old system had been changed, and the business could take on more work than before, not less.
The company
Capped by hands, not by demand.
Made-to-order apparel, sold and manufactured through a single platform: dealers, manufacturing partners and suppliers all transacting inside the same system. Repeat accounts, real margin.
The first conversation was not about AI. It was about technical debt — eight code modules, three back offices running in parallel, new hires taking too long to become useful. They wanted an opinion on whether a rebuild was worth doing.
We took an inventory and came back with a different answer. Two generations of technology stacked on top of each other, with transaction behaviour depending on how a method had been named — the risk of touching that far outweighed the return. Meanwhile that thirty-two person operations team was costing $840K a year, fully loaded.
So the engagement was redefined: leave the old system alone, build AI capability alongside it, and take the operations team out of the repetitive work. That turn got the project approved inside a week — because it removed downtime risk, which was the single biggest obstacle to a decision.
Discovery
Measure the hours before deciding what to change.
This is where most AI transformation projects die — interviews without data validation, and the whole plan ends up resting on the impression that everyone is busy. Three weeks, three lines of enquiry running at once.
Non-invasive code inventory
The true size of the estate, established without disturbing anyone: eight modules, 158 controllers, 348 server pages, 766 front-end pages, 176 distinct spreadsheet import and export methods, 153 reporting routes — and exactly two scheduled jobs in the whole system.
Shadowing and time sampling
Twelve roles observed across five consecutive working days, logged at fifteen-minute granularity, separating productive work from waiting, from context switching, from rework.
Reverse validation against data
Every interview conclusion checked against real production records. This is the difference between what we do and pure consulting. Impressions mislead. Data does not.
Of the 6,144 nominal hours a month — 32 people × 24 days × 8 hours — only about 4,178 were landing on work that produced a business result. The missing 32% was not idleness. It was structural: 17% waiting, 9% switching between systems, 6% rework.
That changed the shape of the solution. At 95% utilisation, AI's only route is to replace the work itself, and the ceiling is low. At 68%, there are two sources of gain — AI replacing work, and process continuity removing the waiting, the switching and the rework.
Findings
Every one confirmed in code or in data.
Not interview impressions. Each of these points at a specific piece of live code or a specific set of production records.
The queue rejected orders on people's behalf
Live code auto-rejected any order sitting unreviewed for more than fourteen days. On the numbers, 143 orders a month were being lost that way.
One person, five systems
A single transaction required checks across several back offices and consoles. Measured during shadowing: eleven switches per person per day.
Export was the workflow
Behind those 176 export methods sat an entire offline routine — open the page, set the filters, export, then rework it in a spreadsheet. And none of those endpoints had usage instrumentation. Nobody knew which reports were still being read.
Five parallel definitions of the same statistics
Sales, finance, payments, after-sales and search each used their own combination of order states. Cross-department reconciliation regularly failed to agree. The numbers were not wrong. The definitions were different.
Approach
Grade the work first, then decide what can be automated.
We did not start by asking what AI could do. We started by grading every operational task by how automatable it actually was. That framework set the ceiling on every reduction figure that follows.
Fully automatable
Deterministic rules and finite enumerations — credit and status checks inside order review, SKU matrix generation, column mapping and unit normalisation. Criteria are enumerable and results recomputable. AI takes these over; people sample-check.
Human in the loop
AI locates the problem and presents the evidence and a recommendation; a person makes the call. Compressible by 30–60%, but never to zero, because accountability has to sit with a person.
AI cannot remove it
Phoning a customer about a material shortage, agreeing price and process across departments, photographing physical product. The direct reason the reduction stops at 69% rather than going further.
Every AI capability runs as an independent side-car service, reads from read-only data sources, and performs every write through existing interfaces. It does not bypass existing authorisation and it does not write to state tables directly. That red line got the design through the client's technical committee on the first pass.
One job, start to finish
A customer's spreadsheet.
Taken from the system running today. The example happens to be an apparel order sheet. Substitute an insurance claim schedule or a bill of materials and the shape does not change.
Reads the headers
Works out which system field each customer column corresponds to — not against a fixed mapping table, but by meaning, so that “fabric spec”, “material” and “cloth” all resolve to the same field.
Normalises the values
Colours, sizes and units aligned against finite enumerations. “Navy”, “dark blue” and the customer's own shade name converge on one colour code; “dozen” and “12 pcs” on one unit.
Flags the problem rows
Rows that cannot be resolved are pulled out with the reason stated. Nobody reads the whole sheet. They handle the rows that were flagged.
Validates before writing
Target data structure validated before any write. Failed validation returns the row rather than writing it. The worst case is an import that did not happen, not bad data that did.
Handover
Trust is bought with data, not promised.
One principle we held to: nothing AI decides goes into the database on day one. Order review directly affects orders and revenue. If the client is going to trust it, the trust has to come from somewhere.
- Shadow modeAI decided every order but wrote nothing, with each decision compared against the human outcome. Over two weeks, more than 3,100 orders compared. Only once agreement held steady at 98.6% did we move on. Operations workload during those two weeks: unchanged.
- Controlled releaseAutomatic clearance opened first to existing customers, existing styles and order values inside the historical range. Starting clearance rate 71%.
- Full runningClearance boundaries widened week by week. By the second month, 88% clearing automatically at 99.3% sample-check accuracy, with the sample rate reduced from 10% to 5%.
Results
Two months of comparison running.
Measured item by item against the pre-change baseline. Every figure below comes out of the measurement layer built into the system. None of it was estimated afterwards.
| Measure | Baseline | Month 1 | Month 2 | Change |
|---|---|---|---|---|
| Operations headcount | 32 | 26 | 20 | −37.5% |
| Effective workload (hours/month) | 4,178 | 3,180 | 2,647 | −36.6% |
| Utilisation per person | 68% | 76% | 82% | +14pp |
| Average review handling time | 4.2 h | 1.1 h | 0.6 h | −86% |
| Orders clearing automatically | 0% | 71% | 88% | — |
| Sample-check accuracy on cleared orders | — | 98.6% | 99.3% | — |
| Orders auto-rejected on timeout | 143 | 34 | 9 | −94% |
| Spreadsheet import first-time success | 46% | 88% | 94% | +48pp |
| Time per customer spreadsheet | 38 min | 14 min | 9 min | −76% |
| SKU time to listing | 2.7 days | 1.1 days | 0.6 days | −78% |
| Data entry time per style | 52 min | 21 min | 14 min | −73% |
| System switches per person per day | 11 | 6 | 4 | −64% |
Before the change, each person was carrying 131 hours a month. After it, across twenty people, 132. Effectively identical. The reduction did not come from pushing the people who stayed — it came from work that should never have existed being removed. That is the reason this holds as a steady state rather than a sprint.
And the business can take on more, not less. Orders auto-rejected on timeout fell from 143 a month to 9 — that is 134 orders a month kept instead of lost, straight onto the revenue line. Review handling time fell from 4.2 hours to 0.6, and in this business the supplier who answers first usually wins the order. After twenty people absorb the entire workload there is still 15.9% of capacity in hand: room held for growth, not room sitting idle.
The attribution has a control. Order volume moved within ±4% across the comparison period, and the four functions left untouched — reconciliation, after-sales, reporting and customer service — showed no material movement over the same window. So the change attaches cleanly to the process work.
Whether this transfers to you
Do not start with what AI can do. Start with whether you are this shape.
Is your output equal to what your team can process by hand in a day?
The important one. If that sentence is true, your ceiling is in your headcount, not in your market.
Is there a system you cannot touch?
Not because nobody wants to — because touching it breaks things.
Is a large share of the work enumerable judgement?
Criteria that can be written down and results that can be recomputed — reviewing, importing, entering.
Three yeses and it is the same shape. The first move is not installing anything — it is measuring your own baseline. Every reduction figure in this case study has as its denominator hours measured inside that company, not an industry average.
Client name available under a non-disclosure agreement.