Where client files should live, and why yours are scattered

A client you finished with in the spring emails asking for the print-ready files. You check the shared drive, then Slack, then your sent folder, then the designer's personal Dropbox, and you turn up four versions whose names are all some variation of "brochure-final." None of them carry a date. You send one, and the client is the one who notices it is the wrong one. Nothing here was caused by carelessness. It was caused by not deciding, up front, where things live.

Why client files end up scattered across five tools

Files scatter because every tool you use is willing to become a file store, and none of them was built to be one. Email accepts attachments. Slack accepts drags. Your project tool accepts uploads. The form on your site drops PDFs into a folder nobody opens. Your design app has cloud storage of its own. Each one is a perfectly reasonable place for a file to arrive, so the file stays where it arrived.

The unspoken default becomes "where it landed is where it lives." That rule feels free on the day the file arrives and costs you real time eight months later, usually on a day when the client is on the phone.

Working files versus client deliverables

Every file your agency touches is either a working file or a client-facing deliverable, and the two should never share a folder. A working file is anything mid-process: layered source documents, scratch exports, a staging database dump, a rough cut, notes from a call. A deliverable is anything a client has received, will receive, or would need in order to keep operating without you.

The moment of transition is specific. A file becomes a deliverable the second you would be comfortable sending it. At that moment you copy it (never move it) into the deliverables area under a stable name. The working copy stays where it was so the designer can keep working. The deliverable copy stops changing.

A lot of file chaos is one team treating one folder as both. Somebody edits the file that was already sent, and now the version the client has and the version you have are different, and nobody can say which is right.

A client folder structure you can set up in ten minutes

Use the same five folders for every client, in the same order, forever. Numbering them forces the sort order and makes the structure learnable in one look.

• 00-inbound. Everything the client sends you, in whatever state it arrives. Never renamed, never edited in place. This folder is evidence. When a client says "I sent you that in April," this is where you look.
• 01-working. Your process. Subfolders by workstream, not by person.
• 02-deliverables. Only things that have gone out or are about to. Versioned.
• 03-admin. Signed contract, scope, change orders, invoices, a list of which accounts exist and who owns them. No passwords in any document, ever. Credentials belong in a password manager.
• 04-archive. Superseded rounds and dead directions. Archive rather than delete, because the direction you killed in month two is the one they ask about in month nine.

The discipline that makes this hold is the copy step out of 00-inbound. If someone edits the client's original spreadsheet in place, you have lost the original, and you will need it during a dispute.

How to name client files

A file name should answer three questions without being opened: what it is, who it is for, and when it was fixed. Use one template everywhere.

YYYY-MM-DD_client-slug_project_asset_vN.ext

2026-03-14_northside-dental_rebrand_logo-primary_v3.pdf

The rules behind it:

• Dates always YYYY-MM-DD, so alphabetical sorting and chronological sorting are the same thing.
• Lowercase throughout. Hyphens inside a group, underscores between groups. No spaces, because spaces break links and some servers.
• One client slug, chosen once, used in file names, folder names, and project names.
• Never the word "final." It is a promise you cannot keep, and it always produces final-v2, final-real, and final-USE-THIS.

How to version files a client sees

Version numbers should count rounds the client saw, not times you hit save. v1 is what you sent first. v2 is what you sent after their feedback. The forty saves in between live in 01-working and get overwritten without ceremony. This matters beyond tidiness: your contract probably promises a number of revision rounds, and if version numbers track rounds, your file names are also your scope record. When a client asks for changes on v4 of a three-round engagement, the file name is the conversation.

Why email attachments are a bad file system

Email is a delivery mechanism, not a storage system, and treating it as storage puts your project history inside mailboxes you do not control. An attachment creates as many copies as there are recipients, and every copy drifts. Search is per mailbox, so when your account manager leaves, the March thread leaves with them or lives on in a suspended account you keep paying for. Size limits push people to expiring transfer links. Worst of all, an inbox gives no signal about which version is current, so the client opens whichever one sits higher in the thread.

You do not fix this by telling clients to stop emailing you. You fix it with an asymmetry: inbound flexible, outbound disciplined. Clients may send you anything by any channel. You always deliver from one location you control, as a link, with the version and status stated in the message, which is the same discipline behind getting client communication into one place. This is exactly why we built email replies into Client Atrium, our client portal, so a client can answer a notification from their inbox and the reply lands in the right thread with the file beside it. You can get most of the same result with a shared drive and a rule you actually follow. The principle is what does the work.

Plenty of clients will never open the thing you built for them, so the filing has to work without their participation, and the email versus portal comparison walks through that tradeoff honestly.

When the problem is status, not storage

File chaos is often a status problem wearing a storage costume. The document everyone is hunting for is not lost. It is sitting exactly where it should be, and nobody knows it is still incomplete because the status lives in one person's head. That is an approvals problem rather than a filing problem, and it is worth reading how to stop chasing clients for approvals before you reorganize a single folder.

How to hand a client their files at the end of a project

Do the handoff continuously so the final handoff is a link and a manifest, not a project of its own. Work this checklist:

1. 02-deliverables contains only what actually shipped, each at its highest version. Everything else moved to 04-archive.
2. A manifest at the top of the folder: one line per file with what it is, what it is for, and what it depends on (fonts, source application, plugins).
3. Source files for anything they paid to own, and a plain statement of what they are not getting, such as your internal templates or licensed assets you cannot transfer.
4. Credentials handed over through a password manager, with a list of every account and its billing owner.
5. Font and stock licenses listed with the license holder named. This is the item most likely to come back and bite someone two years later.
6. Signed documents exported as PDFs with whatever certificate or audit trail your signing tool produces.
7. Decisions written down: what was approved, on what date, by which named person.
8. A dated snapshot delivered by link, plus a sentence stating how long you will keep your copy.

If your tooling can produce most of that in one action, use it. Ours can: Client Atrium exports transcripts, files with a manifest, and signed PDFs with their certificates, though direct messages are not in the export yet. Several other tools do a version of this too. If yours does none of it, the checklist above is a manual job you can work through in one sitting per client, which is still cheaper than the scramble.

The one hour that will help most, even if you change nothing else

Pick your two most active clients and spend an hour. First, create 00-inbound for each and dump everything you can find into it without sorting or renaming, just to stop the bleeding. Second, rename the five most important deliverables using the template and see what links break, because that tells you where those files were actually being served from. Third, write the manifest for each client, one line per shipped file, so the next person to ask for something gets an answer instead of a search.

None of that requires new software, a migration, or a team meeting. It requires deciding once where files live and then being boring about it. The agencies that never lose a logo are usually not better organized by temperament. They made the decision earlier than you did, and you can make it today.