Tech pack versioning across two factories: what breaks and how to hold the line

A knit top goes to two factories, one in Portugal for EU orders and one in Vietnam for the US pool. Factory A asks a question about rib width, the designer answers in a WhatsApp thread, updates her Illustrator file, and emails Factory A the new tech pack. Factory B, still cutting against the version from three weeks ago, produces 1,800 units with the original 2cm rib. The size run is wrong, the hero color ships late to the US, and a chargeback window opens with the biggest wholesale account. Nobody did anything obviously wrong. The version just drifted.

What does tech pack versioning across multiple factories actually require?

Tech pack versioning multiple factories apparel brands depend on is the discipline of making sure every factory cutting the same style is cutting against the same revision, that every revision has a number and a changelog, and that no factory can start production against a version that has been superseded. It sounds administrative. It is actually the foundational control for Breakpoint 1 of the 6 Breakpoints framework, the moment product data starts fragmenting across the people who need it.

The reason this breaks in the mid-market is structural. When I started Uphance, what I kept running into was design teams working in Illustrator, production teams working in spreadsheets, and factories working from PDFs attached to emails. Three systems, three versions, no shared clock. A single factory brand can muddle through on discipline. A two-factory brand cannot. The second factory is the moment the cost of a broken versioning system becomes visible, usually in a sample round or a short ship.

The stakes are not time saved. They are retailer standing and the orders a brand can accept next season. A production manager spending a day a week chasing which factory has which version is the person who should be onboarding the third factory for next year’s expansion. The capacity to grow is sitting inside the version chaos.

Stage 1: lock the master before anything leaves the studio

Owner: design, with sign-off from the product developer.

Input: the Illustrator file, the BOM, the construction notes, the graded spec from the pattern maker.

The check that says it is done: a single tech pack with a revision number (call it Rev A), a timestamp, and a named owner. The Illustrator flats on the tech pack are the same flats the designer is working on, not an exported snapshot that will diverge the moment she edits the artwork. This is where a bidirectional Illustrator plugin inside PLM earns its keep: when the designer updates the flat, the tech pack updates. When the colorway changes, the tech pack reflects it. There is no exported PDF floating in an email thread two weeks behind the live file.

Most brands skip this stage because the designer is already working, and locking the master feels bureaucratic. The cost of skipping shows up at Stage 4.

Stage 2: release Rev A to both factories through one channel, at the same time

Owner: product developer or production coordinator.

Input: Rev A tech pack, the factory allocation (which style, which factory, which quantity split), the sampling calendar.

The check that says it is done: both factories have acknowledged receipt of the same revision number through the same system. Not an email to Factory A on Tuesday and a WeTransfer link to Factory B on Thursday. One release event, both acknowledgements logged against the style record.

This is the stage where the operational anti-pattern lives. If Factory A gets the tech pack a week before Factory B, Factory A starts asking clarification questions first, and those answers go into design updates that Factory B has never seen. By the time Factory B opens the file, they are already behind on context they do not know exists.

Stage 3: route every factory question through one person and one log

Owner: the product developer who owns the style, not the designer.

Input: the question from the factory, the current revision, the history of previous answers on this style.

The check that says it is done: the question, the answer, and any resulting change are logged against the style record and visible to both factories within 24 hours. If the answer requires a change to the tech pack, it triggers Stage 4. If it does not, it is a clarification and both factories see the clarification.

The failure mode here is the designer answering questions directly in Slack or WhatsApp because the factory asked her directly and she wanted to be helpful. Her answer never makes it to the tech pack, never makes it to the other factory, and three weeks later the two factories are building to different interpretations of the same spec. The product developer has to be the firewall, and the design team has to accept that direct factory contact is a bug, not a feature.

Stage 4: issue revisions as numbered releases, never as overwrites

Owner: product developer.

Input: the approved change (from a fit session, a construction question, a trim substitution, a costing round).

The check that says it is done: Rev B exists as a distinct version, Rev A is marked superseded, both factories have acknowledged Rev B, and the changelog names what moved from A to B in plain language. Not “minor updates.” Specifically: “rib width 2cm to 2.5cm, confirmed with both factories, applies to all size breaks.”

The common failure is the designer updating her Illustrator file in place, re-exporting the tech pack with the same filename, and sending it over with a note saying “use this one.” Now the factories have two files with the same name and different contents. The cutter opens whichever one is on top of the inbox. A real revision system makes Rev A readable even after Rev B exists, because the fit session comments on Rev A need somewhere to live.

This is also where the critical path calendar matters. A revision issued after the sampling window closes needs a different approval path than a revision issued before first proto. If the calendar does not know what gate a style is sitting at, revisions get applied at the wrong time and the factory ends up re-cutting trims they already ordered.

Stage 5: gate production against the current revision

Owner: production manager at the brand, with a counterpart at each factory.

Input: the current approved revision number for the style, the PO issued to the factory, the factory’s own cut ticket.

The check that says it is done: the PO references the revision number explicitly. The factory confirms, in writing, which revision they are cutting against before they cut. If the revision on the PO does not match the latest approved revision, cutting does not start. This is a hard gate.

Most brands do not have this gate. The PO goes out referencing the style number, not the revision. The factory cuts against whatever tech pack is in their folder, which may be Rev A, may be Rev B, may be a hybrid where the cutter grabbed the BOM from Rev B and the construction notes from Rev A because that was the order the files landed. A hard revision gate on the PO is a 30-second check that prevents a four-week re-cut.

Stage 6: reconcile the first sample round against the released revision, not the designer’s current working file

Owner: product developer and designer together.

Input: the physical samples from both factories, the released revision the samples were built against, the fit comments.

The check that says it is done: fit comments are written against the revision number the sample was built from, not against whatever the designer has been editing in parallel. If the designer has moved on to Rev C in her head while the factories are still working from Rev B, her fit comments on the Rev B samples are evaluating the wrong thing. The sample round has to be judged on what was asked for, not on what the designer wishes she had asked for.

This is the stage teams skip, and it is the most expensive one. Skipping it means fit comments and design updates get entangled, the next revision carries both the fit corrections and the designer’s new thinking, and neither factory knows which changes came from which source. The sample round that was supposed to converge the two factories ends up pushing them further apart, because each factory interprets the hybrid revision slightly differently. By the time this is caught, bulk fabric is on the water, trims are ordered, and the cost of fixing it is a season delay or a markdown.

Generic ERPs underbuild this entire sequence because they treat a tech pack as a document to attach to a style master. Horizontal PLM tools underbuild it because they do not understand that the sampling calendar, the Illustrator source file, and the factory PO all have to reference the same revision number for the gate to hold. The product data scorecard walks through the diagnostic for Breakpoint 1 if you want to see where your current setup sits.

The stage that gets skipped and what it costs

Stage 6 is the one teams skip. The sampling round feels like a creative conversation, not a reconciliation exercise, so fit comments and design evolution get mixed. The cost is not visible in the sample round itself. It is visible eight weeks later, when both factories deliver bulk that neither matches the original intent nor matches each other, and the brand ships two different versions of the same SKU to two different regions. The stockist who notices is the one who stops reordering. The capacity the brand loses is the retailer it cannot pitch next season because this season’s wholesale ship report is a mess.

The sequence is boring. The absence of the sequence is what shows up as chaos at Breakpoint 1, and it is the chaos that costs the brand the next retailer.