You manage multiple versions of client work by giving every revision a clear, sortable name, keeping old versions instead of overwriting them, and attaching the client's approval to the exact version they reviewed. The test is simple: anyone on the project should be able to open it and know, in seconds, which file is current and which one was approved.
Why overwriting files creates approval ambiguity
Most version chaos starts with the "save over" habit. A designer updates a homepage file, exports a PDF, and sends it off. The client approves it. Two days later someone asks for "one small tweak," the designer edits the same file, and now the approved version no longer exists. Only the new one does.
That ambiguity costs you three ways. First, you can't prove what was approved, because the approved file is gone. Second, the team can't see what changed between rounds, so feedback gets re-litigated. Third, "final" stops meaning anything, because every version is called final until the next one replaces it.
A versioning convention agencies can copy
1. Keep one current version, plus its history
Treat each deliverable as a single current version with a history behind it. The current version is what the client reviews now; the history is what came before. Nothing gets deleted, and nothing gets edited in place after it has been sent.
2. Name versions so they sort correctly
Use short, sequential labels that sort the same way everywhere: v1, v2, v3, never final, final-revised, or FINAL-final-2. The point is that "which is newest" should be obvious from the name alone.
3. Create a new version for every round
Every round of feedback produces a new version. Upload the revision as v2, and keep v1 in the history. This is what lets you answer "what changed since the last review?" and "did we already address that comment?" without archaeology.
4. Attach approval to the exact version
A client approval is only meaningful when it names a version. "The homepage is approved" is a conversation; "homepage v4 is approved" is a record. When the client approves, the approval should stay attached to v4, not float in an email.
5. Keep the history with the work
Version history belongs next to the work, not in a folder named "old versions" on someone's desktop. When a scope question or billing dispute comes up, the history is your evidence.
A versioning checklist
- Every deliverable has one current version and a visible history
- Versions use short, sequential labels that sort correctly
- A new round of feedback always creates a new version, never an overwrite
- Approval names the exact version reviewed
- The full history stays attached to the work
Where version tracking usually breaks
Version tracking breaks at exactly two moments. The first is when a revision overwrites a file that was already sent, so you lose the record of what the client saw. The second is when the approval isn't tied to a version, so two weeks later nobody knows whether "the homepage" means v2 or v4.
The fix is convention, not software: never overwrite after sending, and always name the version in the approval.
How ApproveLite fits
ApproveLite makes this convention the default rather than a discipline the account manager enforces. Each piece of work lives in a request with unlimited versions, so a new round of feedback simply adds the next version while the earlier ones stay in the history. The client reviews the current version through a link and approves or requests changes against it, and the approval history keeps every decision attached to the version it refers to. The result is a clean, auditable record of what was reviewed and approved, in order. For the workflow that surrounds versioning, see the client approval workflow guide, or how to keep client feedback in one place.
Frequently asked questions
How do I name versions consistently?
Use v1, v2, v3 for the deliverable itself, and only add a date or descriptor if two versions would otherwise collide. The rule is that the newest version must be identifiable from its name alone.
Do I really need to keep every old version?
Keep at least everything that was sent to the client. That's the record of what the client saw and reacted to. Old working files that never left the studio are less important, but anything reviewed externally should be retained.
What if the client approves, then asks for a change?
That's a new round: the change creates a new version, and the client reviews and approves that new version. The earlier approval remains on record, and the new approval supersedes it, with both clearly attached to their own versions.
Keep versions and approvals together
Version control for client work doesn't have to be complicated: name versions clearly, never overwrite after sending, and tie every approval to the version it refers to. ApproveLite keeps the version history and approval record together in one place.