Case study · Deliver · Global apparel manufacturer
A global apparel manufacturer runs order operations with 20 people instead of 32.
How the business automated order review and customer data entry beside a legacy system it could not safely change, and cut orders lost to review timeouts by 94%.
- 32 → 20operations headcount, in six months
- −94%orders lost to review timeouts
- 0lines of legacy code changed
A platform business with a legacy core.
The company
A global apparel manufacturer of about five hundred people, making to order for dealers around the world. Dealers, manufacturing partners and suppliers all transact through one platform the company built itself, and every custom order passes through an operations team that reviews it, enters it and moves it into production.
The platform is two generations of technology stacked on each other. It works, and the business depends on it, but nobody could change it with confidence. New hires took months to learn their way around it.
- IndustryApparel manufacturing, made to order for dealers worldwide
- FunctionDeliver: order review, data entry, release to production
- Team in scope32 operations staff
- SystemsIn-house order platform, left unchanged
Growth capped by manual order review.
The challenge
Every order was reviewed by hand: credit and status checks, style and size validation, and matching the customer's order sheet to the platform's fields. Customers sent spreadsheets in their own vocabulary, and someone re-keyed them. A single order meant checks across several back offices.
The cost was visible in the headcount. The bigger cost was not. The platform auto-rejected any order left unreviewed for fourteen days, so when the team fell behind, orders that customers had placed and wanted were cancelled by the system on their behalf. Nobody had decided that. It was how the code had been written years earlier, and the review team was too busy to notice.
Leadership's question to us was whether to rebuild the platform. We took a non-invasive inventory of the code and advised against it. The risk of touching it far outweighed the return, and a rebuild would take years the business did not have.
The system was not the expensive part. The work people did around it was.
Automation beside the system, not inside it.
What we built
We left the platform untouched and built the AI capability as a separate layer beside it. It reads the platform's data and writes only through the interfaces the platform already exposes, so nothing bypasses the existing controls. That design cleared the client's technical committee at the first review and removed downtime risk, which had been the main obstacle to approval.
01
Automated order review
Credit, status and configuration checks that follow written rules run automatically. Orders inside the rules clear on their own. Anything outside them goes to a person with the evidence assembled.
02
Customer order sheets read by meaning
Column headers and values in the customer's own words are mapped to the platform's fields. Rows that cannot be resolved are flagged with the reason, and a person handles only those.
03
A measurement layer
Time, volume and accuracy are recorded per task from the first day, so every decision about what to automate next rests on the client's own numbers rather than on impressions.
Before building anything, we spent three weeks shadowing the team and checking every interview claim against production records. Each task was graded by whether its criteria could be written down and its results recomputed, and only those tasks were automated. Judgement calls, such as agreeing a price across departments or phoning a customer about a material shortage, stayed with people.
Trust earned in shadow mode before anything was released.
Going live
Order review touches orders and revenue, so nothing the system decided went into the database on day one.
- Shadow modeFor two weeks the system decided every order but wrote nothing. Each decision was compared with the human reviewer's. Nothing moved until agreement held steady.
- Controlled releaseAutomatic clearance opened first to existing customers, existing styles and order values inside the historical range.
- Full runningThe boundaries widened week by week as accuracy held, with a sample of cleared orders checked by a person throughout. The client set every boundary.
Twenty people, more orders, legacy system untouched.
Results, six months in
Measured against a baseline recorded before the change.
- Operations headcount, 32 to 20, a 38% reductionReached in six months by removing work, not by pushing the people who stayed. Hours per person were the same before and after.
- Orders lost to review timeouts, down 94%Orders the queue used to cancel on the team's behalf now clear or reach a person in time. Every one kept goes straight to the revenue line.
- Legacy system unchangedNot one line of the platform's code was modified. No downtime, no migration, no retraining on a new system.
- Capacity in handThe smaller team absorbs the full workload with room to take on more, so growth is no longer limited by headcount.
Order volume was stable across the comparison period, and the functions we did not touch showed no movement. The change attaches to the process work, not to the market.
Start with whether you are this shape.
Is this you
01
Is your output capped by what your team can process in a day?
If so, your ceiling is in your headcount, not your market.
02
Is there a system you cannot touch?
Not because nobody wants to. Because touching it breaks things.
03
Is much 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, because every figure above has hours measured inside that company as its denominator, not an industry average.
Start a conversation Next case study: global industrial distributor All case studies