The short answer
- Number versions sequentially and never overwrite a file
- The approval must record which version was approved, not just that one was
- A change after approval starts a new version and needs a new approval
- Reorders should state the version used, so runs match
- "final_v2_USE_THIS" is how shops print the wrong file
Artwork changes. A customer adjusts a date, adds a sponsor, wants the logo larger, changes their mind back. Three rounds in, a shop with no versioning has several files with similar names and no reliable way to say which one the customer actually agreed to.
Then something is printed, the customer says it is wrong, and neither side can prove anything.
How it goes wrong
| What happens | Result |
|---|---|
| File overwritten with a change | The approved version no longer exists |
| Versions named in words | Nobody can tell which is latest |
| Approval says "approved" and nothing else | Approved what? |
| Change agreed by phone | No record it was agreed at all |
| Two people editing separately | Two current versions |
| Reorder uses the newest file | Different from the original run |
The last row is the sneakiest. A repeat order produced from the latest file rather than the approved one comes out subtly different from the first run, the customer notices without being able to say why, and concludes your quality is inconsistent.
"Approved" without a version number records that something happened, not what.
Version, don't overwrite
Sequential numbers, always, and every version kept. Storage is free; a lost approved file is not.
The rules
- Numbers, never words — v1, v2, v3, not "final" or "new"
- Never overwrite; a change creates the next number
- One file marked current, and only one
- A one-line note on what changed
- Older versions kept but out of the working folder
- The version number in the filename
The one-line note costs seconds and answers most later questions. "v3 — sponsor logo added, date changed to 2026" tells anyone at a glance whether v3 is the one they want, without opening three files to compare.
Where this lives matters as much as the scheme. Versions in one person's folder are versions nobody else can use, which is why artwork belongs against the customer rather than in a personal directory.
Tie the approval to a version
The approval record must name the version. That single detail converts a vague agreement into evidence.
The approval should capture
- The version number approved
- Who approved it, by name
- The date and time
- The proof they were looking at, retained
- The stated print size and placement
Attached to the job rather than sitting in an inbox, that becomes reachable by whoever handles a later query — which is the whole practical case for treating a proof as a record. In a system that stores proofs against the order, most of this is captured automatically; on a shared drive it needs a convention everyone follows.
Changes after approval
They happen, including after production has been scheduled. The rule is simple and worth holding to: a change creates a new version, and a new version needs a new approval.
Skipping the second approval because the change was small is how shops end up printing something nobody agreed to. "Just make the logo a bit bigger" is a specification change, and how much bigger is exactly the thing that will be disputed.
| Change | New version | New approval |
|---|---|---|
| Any artwork edit | Yes | Yes |
| Size or placement change | Yes | Yes |
| Colour change | Yes | Yes |
| Different garment | Usually | Yes |
| Quantity only | No | No |
Charge for changes past a reasonable point. One round is normal; a fourth is a customer designing rather than buying, and it belongs in the same art time policy as everything else.
Reorders
A repeat should state which version to run, and the answer is the one approved for the original order unless the customer has explicitly asked for the newer one.
That sounds obvious and it is routinely got wrong, because the natural instinct is to use the latest file. If the customer approved v2 for their first run and v3 exists because of a change they later abandoned, a reorder from v3 is a garment they did not order.
Record the version against the completed job, not just against the artwork. Then a reorder starts from what was actually produced, which is the same discipline as storing the ink mix and the mesh counts.
A workable habit
None of this needs a system to begin with. It needs a convention everyone follows, which is mostly a matter of deciding once and writing it down.
The minimum viable version control
- Filenames end in _v1, _v2, _v3
- A single line in the job notes when a version is created
- The proof filename matches the artwork version
- The approval note states the version
- Superseded versions moved to an archive folder
- The version used recorded against the finished job
Six habits, none taking more than a few seconds. What they buy is the ability to answer, months later, exactly what was agreed and exactly what was printed — which is the difference between a complaint that resolves in one message and one that becomes an argument neither side can win. The rest of the artwork archive assumes the approval names a version.
Who is allowed to create a version
In a shop of two this never comes up. Past that it does, because two people editing the same artwork separately produces two files that both look current and neither is.
Decide who owns artwork changes — usually whoever does the art — and route requests through them rather than letting anyone edit. That is not bureaucracy; it is the same reason a master file should be read-only to most people.
Where somebody else genuinely needs to make a change, the rule is the same as everywhere else: take a copy, number it, note what changed. What must not happen is an edit in place, because the version that was approved has then quietly stopped existing.
Across two sites this matters more again, since the informal check of somebody noticing does not happen at a distance. A shared artwork store with a single current version per design is what keeps two locations producing the same garment.
