You do not need enterprise software to stop losing track of which spec sheet went to which factory. A disciplined naming convention, a single change-log tab, and a two-step approval gate—all inside tools you already have—will give your team a reliable revision history for every style.
Key takeaways
- A structured file name encodes style, season, and revision number so anyone on the team can read the history at a glance.
- A dedicated change-log tab inside the tech pack itself is the single source of truth for what changed, who approved it, and when.
- An approval gate (even a simple one) prevents unapproved drafts from reaching suppliers.
- Consistent folder architecture means you can audit a style's full revision trail in under two minutes.
- These habits cost nothing to implement and scale comfortably to a mid-size brand managing dozens of active styles.
What you need before you start
- A shared drive or cloud folder your whole team can access (Google Drive, Dropbox, SharePoint, or similar)
- A spreadsheet application (Google Sheets or Excel) for the change-log tab
- A PDF viewer that supports annotations, or a shared spreadsheet that doubles as your master spec sheet
- A clear list of who on your team has authority to approve a revision before it leaves the building
- At least one existing tech pack to use as a test case
Before you touch a single file: agree with your team on every convention in this guide before you roll it out. A naming system only works if everyone uses it the same way from day one.
Why version control matters when you have no PLM
A tech pack is the primary contract between your design team and your factory. When revisions pile up without a system, factories sew to the wrong spec, QC teams reference an outdated measurement chart, and nobody can reconstruct what changed between sample rounds. The cost is re-sampling, delayed launches, and eroded supplier trust.
PLM platforms solve this with built-in revision tracking, approval workflows, and audit logs—but they come with implementation timelines and licence costs that many small-to-mid brands cannot justify in early stages. The good news is that the logic behind PLM version control is simple enough to replicate manually, and the discipline of doing it manually makes the eventual PLM transition far smoother.
Step 1: Define your file-naming convention
Action: Create a naming template and write it down somewhere your whole team can find it—a shared doc, a pinned Slack message, or the README file in your drive root.
A reliable template looks like this:
StyleCode_StyleName_[Season]_TP_v[##]_[Status]
For example:
BW024_CropJacket_AW26_TP_v01_DRAFT.xlsx
BW024_CropJacket_AW26_TP_v02_APPROVED.pdf
Field definitions:
| Field | Format | Example |
|---|---|---|
| StyleCode | Brand prefix + sequential number | BW024 |
| StyleName | Short, no spaces (use CamelCase) | CropJacket |
| Season | Two-letter season + two-digit year | AW26 |
| TP | Literal string; marks this as a tech pack | TP |
| Version | v followed by two-digit zero-padded number | v01, v02, v11 |
| Status | DRAFT, IN-REVIEW, or APPROVED | APPROVED |
Expected result: Every file in your drive tells you exactly what it is, which style it covers, which season, and whether it is safe to send to a supplier—without opening it.
Rule: Only files with status
APPROVEDleave the building. A file inDRAFTorIN-REVIEWis internal only.
Step 2: Set up your folder architecture
Action: Create a top-level folder for each season, a subfolder for each style, and two fixed subfolders inside each style: WORKING and APPROVED.
/AW26
/BW024_CropJacket
/WORKING
BW024_CropJacket_AW26_TP_v01_DRAFT.xlsx
BW024_CropJacket_AW26_TP_v02_IN-REVIEW.xlsx
/APPROVED
BW024_CropJacket_AW26_TP_v01_APPROVED.pdf
BW024_CropJacket_AW26_TP_v02_APPROVED.pdf
Why two subfolders? The WORKING folder is your scratch space. The APPROVED folder is your archive—nothing goes in there without passing the approval gate in Step 4. Never delete old approved versions; they are your audit trail.
Expected result: Anyone on the team can navigate to a style and immediately see the full approved history in one folder and the current working draft in another.
Tip: If your drive supports it, set the
APPROVEDfolder to read-only for everyone except the designated approver. This prevents accidental overwrites.
Step 3: Add a change-log tab to every tech pack
Action: Inside your master tech pack spreadsheet, add a tab named CHANGE LOG as the first or last tab. Give it the following columns:
| Column | What to record |
|---|---|
| Version | The version number this row describes (v01, v02…) |
| Date | Date the revision was made |
| Changed by | Name of the person who made the change |
| Section changed | Which part of the tech pack (e.g., Measurements, BOM, Construction Notes) |
| Description of change | Plain-language summary of what changed and why |
| Approved by | Name of the approver (blank until approved) |
| Approval date | Date approval was given (blank until approved) |
Fill in a new row every time you increment the version number. Do not edit previous rows—treat them as locked once the version they describe has been approved.
Expected result: Any team member—or any supplier who receives the pack—can open the change-log tab and read the complete revision history of the style in plain language, without needing to diff two files.
Common mistake: Teams fill in the change log after sending the file to the factory. Fill it in before you increment the version number. The log is part of the pack, not an afterthought.
Step 4: Install a two-step approval gate
Action: Decide who can approve a revision and write their name (or role) next to the APPROVED folder. Then enforce this two-step process for every version bump:
Step 4a — Internal review
- The person making the change saves the file as the next version number with status
IN-REVIEWin theWORKINGfolder. - They fill in the change-log row (columns: version, date, changed by, section, description).
- They notify the approver—by email, Slack, or whatever your team uses—and share a link to the
IN-REVIEWfile.
Step 4b — Approval
- The approver opens the
IN-REVIEWfile, checks the change-log entry against the actual changes in the spec. - If satisfied, they fill in
Approved byandApproval datein the change-log tab, save a PDF export, rename it toAPPROVED, and move it into theAPPROVEDsubfolder. - They notify the team that the new approved version is live.
Expected result: There is never any ambiguity about which version is current and approved. The APPROVED folder holds the ground truth; the WORKING folder holds everything in progress.
Warning: Skipping the PDF export step is a common shortcut that causes problems. Factories sometimes edit spreadsheets they receive. Sending an approved PDF—locked, with the version number embedded in the filename—prevents untracked edits on the supplier side.
Step 5: Communicate version changes to suppliers
Action: Every time you send a new approved version to a factory, include a short cover note—in the body of the email or as a separate line in your purchase order—that states:
- The style code and name
- The version number you are sending
- The two or three most significant changes from the previous version (copy from the change log)
- The version number the factory was previously working from
This forces you to be explicit about what changed, and it gives the factory a paper trail they can reference if a QC dispute arises later.
Expected result: Your supplier knows immediately that a new version has arrived, what is different, and that they should stop referencing the previous version. Ambiguity about which spec to sew to drops sharply.
Step 6: Run a monthly version audit
Action: Once a month, spend fifteen minutes checking that the system is being followed. For each active style:
- Open the
APPROVEDfolder and confirm the highest version number matches what you last sent to the factory. - Open the change-log tab and confirm every version has a completed row, including approval name and date.
- Check the
WORKINGfolder for any staleIN-REVIEWfiles that were never resolved—either approve them, reject them, or delete them. - Note any styles where the naming convention was not followed and correct the filenames.
Expected result: The audit takes less time each month as the habit becomes routine. It also surfaces any styles where the process broke down before those gaps cause production errors.
Troubleshooting common problems
Problem: Two people edited the same file at the same time and the versions diverged. Solution: Designate one person as the owner of the working file for each style at any given time. Use your drive's version history (Google Drive and SharePoint both keep it) to recover the correct state, then reconcile manually.
Problem: A supplier is sewing to an old version and nobody noticed. Solution: Add a visible version banner to the first page of every tech pack—large, bold text reading the version number and approval date. Make it impossible to miss. When you send a new version, explicitly ask the factory to confirm in writing which version they are referencing.
Problem: The change-log tab is not being filled in consistently. Solution: Make the change-log the first thing the approver checks before signing off. If it is incomplete, the approval does not happen. Treat an empty change-log row the same way you would treat a missing measurement: a blocker, not a suggestion.
Problem: Files are accumulating and the folder is getting hard to navigate.
Solution: At the end of each season, archive the entire season folder to a separate _ARCHIVE directory. Keep the current season's folder clean. Never delete approved versions—move them, not delete them.
Problem: The team is working across time zones and approval delays are slowing things down.
Solution: Set a clear SLA for approvals—for example, any IN-REVIEW file must be approved or returned with comments within 24 business hours. Document this in your team's working agreement.
What success looks like
After four to six weeks of consistent practice, you should be able to:
- Open any style folder and identify the current approved version in under thirty seconds.
- Reconstruct the complete revision history of a style from the change-log tab without opening multiple files.
- Tell a factory exactly which version they should be referencing, and confirm it matches what is in your
APPROVEDfolder. - Onboard a new production coordinator and have them understand the system from the folder structure and the change-log alone—no tribal knowledge required.
That last point is the real test. If a new team member can navigate your system without asking for a guided tour, the system is working.
FAQ
How many versions of a tech pack is normal for a single style? It varies by complexity, but three to five versions between initial draft and production approval is common for a new style. Carry-over styles with minor updates may only need one or two. What matters is that every version is documented, not how many there are.
Should I version-control the BOM separately from the tech pack? If your BOM lives inside the tech pack spreadsheet, version them together—same file, same version number, same change log. If your BOM is a separate document, apply the same naming convention and keep a cross-reference note in both change logs.
What if my team uses PDF tech packs rather than spreadsheets? The naming convention and folder structure work identically. For the change log, maintain a separate companion spreadsheet for each style, or add a change-log page to the PDF using annotation tools. The discipline is the same; the file format is secondary.
When should I reset the version number back to v01? Never mid-season. If a style is significantly redesigned for a new season, start a new season folder with v01. Within a season, always increment—even if the change feels minor. Minor changes that are not tracked are how errors reach the factory floor.
How is this different from what a PLM system does? A PLM system automates the naming, stores versions in a database, enforces approval workflows programmatically, and gives every stakeholder a live view of the current state. What you are building here replicates the logic manually. It requires more discipline but costs nothing. When your volume grows to the point where the manual overhead becomes the bottleneck, you will have a clean, well-documented history that makes PLM onboarding significantly easier.