Decide what each label means
A file called “final” is easy to create and hard to trust when a project is still changing. Before work begins, agree on a small set of labels and what each one permits. For example, WORKING can mean an editable file in progress, REVIEW can mean a copy ready for comments, and APPROVED can mean the version the reviewer has accepted. DELIVERED can mark the copy actually sent or uploaded for handoff. These labels describe different events; a file does not become approved simply because someone exported it.
Keep the labels consistent across the project. A student preparing a presentation, a freelancer designing a logo and a small team producing a campaign can all use the same basic distinction: still changing, awaiting feedback, accepted and handed over. If no formal approval is needed, say so in the brief and define which person makes the final delivery decision.
Build file names that answer the obvious questions
A useful file name identifies the project, the item, its version and its state. One workable pattern is Project_Item_v02_REVIEW.ext, such as HarborClub_Poster_v02_REVIEW.pdf. Keep the parts in the same order so related files sort and scan easily. Use short, recognizable project and item names; a long description belongs in the project notes, not in every filename.
Increase the version number when you make a new reviewable iteration. Small changes within an unfinished working session may not need a new number, but a copy sent to someone for feedback should have an identity you can refer to later. Avoid names such as final2, final_new or use_this_one. They describe your intentions at one moment, not the file’s place in an agreed process.
For projects with several deliverable formats, include the format’s purpose when it is not obvious from the extension. HarborClub_Poster_Print_v03_APPROVED.pdf and HarborClub_Poster_Social_v03_APPROVED.png are easier to distinguish than two exports both called poster_final. If a platform changes filenames on download, include the intended names in a delivery note as well.
Separate review copies from delivery copies
Folder structure can reinforce the labels. Keep working files in one location, put copies awaiting comments in a Review folder, and place only handoff-ready items in a Delivery folder. A folder named Delivery is not a substitute for checking its contents, but it reduces the chance of attaching an unfinished export while browsing a crowded project directory.
Treat approval and delivery as separate steps. After approval, export the required formats from the accepted source file, then inspect those exports. The source might be correct while a PDF is missing a page or an image has the wrong dimensions. If an approved item changes afterward, give the changed version a new number and seek any approval the project requires. Do not quietly replace an approved file under the same name.
Shared documents need the same discipline even when their platforms keep revision histories. Set a clear review point, such as “comments on v03 REVIEW,” and record which version was accepted. A link to a live document alone may not tell the recipient whether the content they open is the content they approved. When a fixed record matters, save an appropriately named snapshot or export.
Make feedback easy to trace
Ask reviewers to refer to a version number when giving feedback. If several people comment, gather their responses against the same review copy before starting the next iteration. A short note can record what changed: “v03: updated headline and replaced the second image.” This is not a full project diary; it is enough context to explain why two similar files exist.
Use a single place for the current status, such as a project board, shared checklist or delivery note. Record the item, latest version, state, reviewer and next action. For a team, this prevents one person from preparing a handoff while another is still incorporating comments. For a solo freelancer, it makes it easier to resume a paused project without relying on memory.
Check the handoff before calling it done
Before sending anything, compare the delivery files with the brief or agreed deliverable list. Open each file, confirm its contents and format, and check that its version matches the accepted one. Remove superseded drafts from the handoff folder or leave them clearly outside it. If the recipient needs editable sources as well as exports, label those separately so they know which files are meant for use and which are meant for further editing.
A concise delivery message should name what is included and which version it represents. For example: “Attached: poster print PDF and social image, both v03, approved for delivery; editable source included separately.” If a file is still awaiting approval, say that instead of calling it final. The aim is not to create an elaborate naming system. It is to make the right file identifiable at a glance and to ensure its label reflects what actually happened.
