When a Pre-Production Sample Review Belongs in PLM

A merchandiser opens her inbox on a Tuesday morning. The PP sample for a core knit top arrived from the factory in Tirupur on Friday. The fit session was Monday afternoon. There are now eleven emails: three from the technical designer with red-line photos, two from the head of production asking whether the neckline binding was approved, one from the factory asking for sign-off so they can start cutting on Thursday, and five reply-all threads debating whether the rib trim matches the lab dip from October. The tech pack in the shared drive is on version 4. The factory is working from what they believe is version 3. Nobody has formally approved anything. Cutting starts in 48 hours.

What is a pre-production sample review, and why does it belong in PLM?

A pre-production sample review is the structured sign-off on the PP sample, the last sample made before bulk, against the approved tech pack, graded specs, approved trims, and approved lab dips. It is the gate that authorizes the factory to cut bulk. It pulls together the technical designer, the production lead, the merchandiser, and often a QA contact, and it produces a single decision: approved, approved with comments, or rejected with required revisions.

The review belongs in PLM because every artifact it touches already lives there, or should. The tech pack version. The graded spec. The bill of materials. The trim card. The colorway and the matching lab dip approval. The critical path milestone that says PP approval was due on a specific date. When the review runs in email and a shared drive instead, those artifacts get decoupled from the decision, and the decision gets decoupled from the milestone. That decoupling is where BP2, production and supply execution drifting from the plan, starts.

From the fit calls I run with prospects each week, this is the workflow that exposes the most expensive gap in a brand’s stack. Buyers will tell me their PLM is fine, then describe a PP review process that is entirely email, WeTransfer, and a Monday morning meeting where someone takes notes in a Google Doc. The PLM is holding the tech pack. It is not holding the decision.

Why does the PP sample review keep falling out of PLM?

Three reasons, in the order I hear them.

The first is that most mid-market PLM tools were built to author tech packs, not to run reviews. They are document repositories with a comments field. The technical designer uses them to build the spec, exports a PDF, sends the PDF to the factory, and the factory sends back a sample. Everything after the PDF export happens outside the tool. The review is a separate workflow that never made it into the product.

The second is that the people doing the review are not the people who live in PLM. Technical design lives in PLM. Production and merchandising often do not. They live in email, WhatsApp, and a critical path spreadsheet. When the PP sample arrives, the review naturally migrates to the channel those people already use, which is email, and the PLM becomes a passive record of what the spec used to say.

The third is Illustrator. Designers build flats, callouts, and construction details in Illustrator. If the PLM cannot accept those files as live, structured data, the design team exports PNGs and pastes them into a tech pack template. Revisions to the flat then have to be re-exported and re-pasted. By the third revision, the version in PLM and the version on the designer’s desktop are different. The factory is working from whichever PDF landed in their inbox most recently. Uphance handles this with a bidirectional Adobe Illustrator plugin, so flats, artwork, colorways, and specs sync both ways onto the tech pack, but the broader point holds even outside our stack: if your PLM cannot ingest design files as live data, your PP review will fragment.

What does a PP sample review actually need to capture?

A proper review captures seven things, and each one has to be tied to a specific version of a specific artifact, not a free-text comment.

1. The sample identity. Which style, which colorway, which size sample, which factory, which PO. PP1 versus PP2 if there were revisions.
2. The measurement audit. Graded spec versus measured sample, point of measure by point of measure, with tolerance. A sleeve length that is half an inch long on a size M is not a comment, it is a deviation against a spec line.
3. The construction audit. Stitch type, seam allowance, binding, topstitching, label placement, care label content. Each line item maps to a row in the BOM or the construction section of the tech pack.
4. The trim and material audit. Lab dip approval reference, trim card reference, fabric lot if relevant. The review confirms what was used, against what was approved.
5. The fit decision. Approved, approved with comments, or rejected. If approved with comments, the comments must be revisions the factory can act on without another sample round.
6. The bulk authorization. The explicit handoff to production with the approved spec version locked in. The factory cuts against that version, not whatever PDF they happen to have.
7. The critical path update. The PP approval milestone gets a real timestamp, and any slippage cascades to downstream milestones (bulk cut, in-line inspection, final audit, ex-factory, ship window).

If any one of these seven is in email and not in the system, the review is partially outside PLM, and the bulk run is being authorized against a partial record.

What goes wrong when the review lives in email?

Four failure modes show up repeatedly. The objections I hear most often in evaluations cluster around exactly these.

Version drift. The factory cuts against tech pack v3 because that is the PDF they have, while the approved version is v4 because the designer revised the neckline after the fit session. The first 200 units come back with the wrong binding. The brand owns the cost because the approval was never formally communicated against a locked version.

Comment loss. Three reviewers each send notes by email. The technical designer consolidates them into a revised tech pack. One comment from the head of production, about a label placement change required by a wholesale account’s compliance spec, gets missed. The bulk ships, the retailer rejects the carton, and the chargeback shows up six weeks later. If chargebacks for compliance issues are recurring, the gap is not at the warehouse. It is at the PP review where the compliance spec was not enforced against the sample.

Slippage invisibility. The critical path says PP approval was due on the 15th. It actually happened on the 22nd because the second sample round took longer than expected. Nobody updated the calendar. Bulk cut, inspection, and ex-factory dates all silently slip by a week. The ship window to a major wholesale account is now at risk, and merchandising finds out three weeks later when production reports the delay. By then it is too late to negotiate a revised ship window without a markdown.

No audit trail when a factory disputes. Six months later, a factory bills the brand for fabric used on a revision they claim was requested verbally. There is no record of who approved what, when. The brand pays because the alternative is a fight with a key vendor.

Each of these is a BP2 symptom. Production and supply execution drift from the plan because the plan was not enforced at the gate where it could have been.

When does the review actually need to be in PLM, not somewhere else?

A point of view, because the answer is not always yes for every brand.

If you are doing fewer than 20 styles a season, the review can live in email and you will mostly survive. The cost of the workflow gap is bounded by the small style count. Once you cross roughly 50 styles a season, or you are running more than one season concurrently, or you have more than three factories in rotation, the email model breaks. There are too many parallel reviews, too many versions, too many critical path milestones to track in a spreadsheet without something going wrong every week.

The brands I see in the $10M to $20M predictable breakpoint zone almost always cross this line. They have 60 to 200 styles in development at any time, three to six factories, two or three concurrent seasons, and a wholesale book that depends on hitting specific ship windows. The PP review running in email at that scale is not a workflow choice, it is a structural risk.

The POV: if your style count is above 50 per season and your ship windows are wholesale-committed, the PP sample review belongs in PLM, with the decision attached to the locked tech pack version, the BOM, and the critical path milestone. Email is acceptable for communication. It is not acceptable as the system of record.

How does the review tie into the rest of the operation?

The review is not just a design and production concern. It feeds three other parts of the operation that brands routinely underestimate.

It feeds production planning. The approved bulk authorization triggers the cut date, which sets the inspection date, which sets the ex-factory date, which sets the ship window. If the PP approval is in email, the cut date is whatever the factory unilaterally decides. If it is in PLM, the milestone cascade is automatic and slippage is flagged the day it happens, not the week the goods are due to ship.

It feeds the BOM and costing. A revision at PP, a different trim, a different stitch, a different fabric consumption, changes landed cost. If the revision is captured against the BOM in PLM, costing updates. If it is captured in an email reply, the costing in the system is stale and the margin reported to finance is wrong. This is also where BP3, inventory truth, gets weaker, because the standard cost on the SKU diverges from what was actually built.

It feeds wholesale commitments. The brands I work with often have orders booked against styles whose PP samples have not yet been approved. When the PP review slips, the wholesale ship window slips, and account managers need to know immediately so they can have the conversation with the buyer. If the slippage is invisible until production reports it, the brand finds out about the problem after the buyer does.

The critical path / time-and-action calendar is the thing that ties these together. Every style and season tracked against milestones and dependencies from design to delivery, with automatic slippage flagging. PP approval is not a standalone event. It is one node in a dependency graph, and treating it as a standalone email thread is what makes the graph silently incorrect.

What this means for an apparel operations team

Audit one season’s worth of PP sample reviews. Pull the actual decisions and revisions out of email and ask, for each style: what version of the tech pack did the factory cut against, and is that the version the technical designer believes was approved. If you cannot answer that question with a timestamp and a locked version reference, the review is outside the system of record, and BP2 drift is already happening even if you have not yet felt the cost.

The fix is not buying a new tool for every gap. The fix is moving the decision into the same system that holds the artifact the decision is about. The tech pack, the BOM, the trim card, the critical path milestone, and the bulk authorization should all share one version history. The review produces a row in that history, not an email thread next to it.

For brands in the $10M to $20M zone, this is one of the highest-leverage changes available. It does not require a re-platform. It requires deciding that the PP sample review is a system event, not a meeting, and running it accordingly.