Start with one agreed working location
Project files can end up in email attachments, personal drives, chat messages, and shared folders. The problem is not just clutter: people may spend time searching for an asset or editing a copy that someone else has already replaced. Before work begins, choose one working location for files the team needs to use. It could be a shared drive, a project workspace, or another tool everyone involved can access reliably.
Make it clear which location holds the working files and which channels are only for discussion. A client may still email an attachment, for example, but the person receiving it can place it in the agreed location and point collaborators to that copy. If the client must use a separate system, decide who transfers approved material between the two. This small ownership decision helps prevent competing “final” files from developing.
Build folders around how people retrieve work
A useful folder structure should answer common questions quickly: Where is the brief? Which assets did the client provide? What is ready for review? What has been approved? Start with a small set of folders, such as 01 Brief and inputs, 02 Working files, 03 Client review, and 04 Approved deliverables. Numbering keeps the sequence visible when a tool sorts folders alphabetically. Add subfolders only when a folder becomes difficult to scan.
Keep source material separate from work your team has changed. For instance, an original client logo belongs with inputs, while resized or adapted versions belong with working files. This makes it easier to tell what was supplied and what was produced during the project. If the work includes sensitive information, limit access to people who need it rather than assuming everyone with a project link should see every folder.
Write a short folder guide in the project workspace if names alone might be ambiguous. It can explain where meeting notes go, where reviewers should leave comments, and who moves a deliverable into the approved folder. A few clear rules are more likely to be followed than an elaborate structure that requires constant maintenance.
Use file names that explain status without guesswork
File names should help someone recognize a document without opening several copies. A simple pattern is project name, deliverable, stage, and version: Northstar_WebCopy_Review_v02. Use terms the team understands consistently. A version number identifies a particular copy; a stage such as Draft, Review, or Approved explains what people should do with it. Avoid relying on names such as final, final-new, and final-really-new, which become confusing as soon as another edit is needed.
Agree on what triggers a new version. Minor edits inside a shared working document may not require a renamed file, especially if the tool preserves earlier versions. A copy sent for formal client review usually does: it provides a stable reference for comments and decisions. If a deliverable has multiple components, consider a short index listing each component, its latest review version, and its approval status.
Dates can be useful in file names when they clarify a handoff or a time-based asset. If you include them, use one consistent format so files sort predictably. Dates should not replace version or stage labels when several rounds might happen close together.
Control review copies and close the project cleanly
When sending work for review, identify the exact file or folder and ask for feedback on that copy. Set a clear way to collect comments, such as notes in the shared document or one consolidated response from the client. If comments arrive across several channels, assign someone to bring them together before edits begin. That person can flag conflicting requests instead of asking the team to guess which instruction takes priority.
After a review round, keep the reviewed copy available for reference and create the next version in the working area. Move a file to Approved deliverables only when the relevant client contact has confirmed it meets the agreed requirements. That folder should contain what people can use or hand over, not every draft produced along the way.
At closeout, check that the approved folder contains the correct files in usable formats and that the client knows where to find them. Then archive working material according to the agreement and any applicable retention requirements. Remove unnecessary access where appropriate. The goal is not a perfect filing system; it is a dependable path from inputs to working files to reviewed and approved work.
