Back to blog

How to organize client files: 7 folders, one name rule

Organize client files with one folder per client, seven numbered project folders, a five-field filename rule, one intake channel and a 10-file retrieval test.

Kristian Hoffmann

SaaS founder and operator

How to organize client files: 7 folders, one name rule

To organize client files, give every client one top-level folder, give every project inside it the same seven numbered subfolders, name each file with a fixed five-field pattern (date, client, project, asset, version), route every incoming file through one intake channel, and archive closed projects on a set schedule. That combination is what makes a folder system survive a busy month. Most systems that fail do so at the edges: files arriving by five routes, filenames ending in "final2", and finished projects that stay mixed in with live ones.

The rest of this guide gives you the exact skeleton, the naming rule, a permissions table for teams, and a ten-minute test that shows whether your structure works before a client asks for last year's logo.

The skeleton: client, project, seven numbered folders

The shape is three levels deep and no deeper: Clients / Client name / YYYY-MM_project-name / numbered folders. The project folder starts with its start month, so a client's projects sort chronologically without you renaming anything.

Folderit describes the same principle from the office-records side: sort into larger containers first, then into folders and sub-folders. What client work adds is a fixed set of subfolders that matches how a project actually moves.

FolderWhat goes inWho writes to it
00_adminProposal, contract, scope, invoices, signed approvalsOwner or project lead
01_briefCompleted brief, meeting notes, sitemap, goalsProject lead
02_client-suppliedLogos, copy, photos, logins handed over by the client, untouchedIntake only
03_workingDesign files, drafts, exports in progressWhole team
04_reviewExactly what was sent to the client for feedback, datedProject lead
05_approvedThe versions the client signed offProject lead
06_handoffFinal deliverables, credentials sheet, documentationProject lead

Why the numbers matter

A file browser sorts alphabetically. Without the 00–06 prefix, "approved" lands above "brief" and "working" lands at the bottom, out of project order. With the prefix, every project in every client folder opens in the same sequence, so a colleague who has never touched the account still knows where the brief is.

Why 02_client-supplied stays untouched

This is the folder people break first. A designer crops the client's logo, saves over the original, and three months later nobody has the source file. Treat the folder as read-only after intake: copy what you need into 03_working, edit the copy. If a client resends a corrected file, add it with a new date in the name instead of overwriting the old one. You then have a record of what the client actually gave you and when, which settles most "we sent that weeks ago" arguments in a minute.

Name files so search does the work

Folders help you browse; filenames help you search. A designer in the r/Design thread on file habits describes a key name, the date and the version in every filename. That is the right instinct. Make it stricter so a whole team produces identical names.

Five fields, in this order

2026-11-18_acme_relaunch_homepage-hero_v03.fig

1. Date in ISO format (YYYY-MM-DD). It is the only common date format that sorts chronologically as plain text. 18.11.26 and 11-18-26 do not. 2. Client short code. Three to six letters, lowercase, agreed once and written in 00_admin. 3. Project short name. Matches the project folder name without the month. 4. Asset. What the file is, in plain words: homepage-hero, logo-horizontal, copy-about. 5. Version, zero-padded. v03, not v3. Without the zero, a text sort puts v10 before v2, and someone sends the wrong file.

Use hyphens inside a field and underscores between fields. That gives you a name a script, a search bar and a person can all split the same way.

Words to keep out of filenames

"Final", "new", "latest", "updated", "use-this" and a person's initials as the only identifier. Each of them describes the file's status at one moment, and that status changes. Status belongs to the folder: a file in 05_approved is approved; a file in 03_working is not. Once the folder carries the status, the name only has to describe the content.

One way in: the intake rule

Client files arrive through email attachments, expiring transfer links, chat messages, shared drive invites and USB sticks at meetings. Every extra channel is a place a file can sit unfiled. The failure is predictable: the file exists, someone saw it, and nobody can find it when the build starts.

The rule that fixes this is simple: every inbound file lands in `02_client-supplied` within one working day, with a row in the intake log. The log is a small table in 01_brief with six columns:

ReceivedSenderChannelOriginal nameSaved asUsed in
2026-11-04Marketing leadEmailLogo NEW.png2026-11-04_acme_relaunch_logo-primary_v01.pngHomepage header

The "Original name" column matters more than it looks. When the client says "the file I called Logo NEW", you can match it in seconds.

Fewer channels, fewer misses

You will not get clients to stop emailing entirely, but you can give them a route that is easier than email. A client portal link does this if the client can upload without creating an account. In cluein.me, for example, the client opens one link, fills in the brief and uploads files into named slots, and you export the result as a ZIP with a structured JSON and Markdown brief that drops straight into 01_brief and 02_client-supplied. If you are designing the questions that go into that link, the web design template for client intake lists the fields that block work if they are missing.

Whatever tool you use, the test is the same: does the file reach its folder with a usable name, without someone retyping it?

Team access: who writes where

A shared drive where everyone can edit everything turns the structure into a suggestion. eezydocs frames the goal well: a client file system your whole team can navigate without digging through sent folders. Navigation is only half of it. Write access decides whether the structure is still there in six months.

FolderProject leadDesigners / developersClient
00_adminWriteRead or noneNone
01_briefWriteReadSees the brief they filled in
02_client-suppliedWrite (intake)ReadUpload only, via intake channel
03_workingWriteWriteNone
04_reviewWriteReadSees what was sent
05_approvedWriteReadSees what they approved
06_handoffWriteReadReceives a copy at handoff

Two folders take writes from more than one role: 03_working and, through the intake channel, 02_client-supplied. Every other folder has one writer. When something lands in the wrong place, you know whose habit to fix.

The 10-file retrieval test

You find out whether a folder system works by searching it, not by admiring it. Run this once a quarter, or before you commit to a new structure.

1. Pick ten files from the last 60 days across at least three clients: a client logo, an approved mockup, a signed scope, a piece of supplied copy, a review export, and so on. 2. Hand the list to a colleague who did not work on those projects. Describe each file the way a client would ("the hero image they approved in October"). 3. Time each search. Note whether they had to ask anyone.

ResultWhat it means
9–10 found, each under 30 seconds, no questionsThe structure works; keep it
6–8 found, or several over a minuteNaming is inconsistent; check the five-field rule first
5 or fewer, or questions on most filesFiles are entering outside the intake channel; fix the way in before the folders

The time cost is easy to underestimate. As a worked example: if a two-person studio searches for eight files a day and each search takes four minutes instead of thirty seconds, that is 3.5 extra minutes × 8 files × 2 people = 56 minutes a day, roughly 4.5 hours over a five-day week. Put your own numbers into the same formula before deciding whether a cleanup is worth an afternoon.

Close the year: the November–December archive pass

The weeks before the December break are a practical moment to clear the active list. Projects launched in autumn are handed off, clients are slower to respond, and January starts cleaner if Clients/ only shows live work. The project handoff template covers what goes into 06_handoff; the archive pass is what happens to everything else.

Archive checklist for each finished project

  • Confirm 05_approved and 06_handoff contain the final versions, and that the handoff copy reached the client.
  • Delete duplicate exports in 03_working older than the approved version. Keep the source design files.
  • Move the whole project folder to Clients/Client name/_archive/ so it stays with the client but out of the daily view.
  • Compress the archived project as a ZIP and record the date in the intake log, so you know when the folder was frozen.
  • Add one line to the client folder's notes: launch date, where credentials were handed over, and who to contact.

What to check before deleting anything

Do not clear 00_admin or 02_client-supplied on instinct. Contracts, invoices and records of what the client supplied can matter later, and how long you need to keep them depends on your contract terms and the bookkeeping rules where you operate. Ask your accountant or check your local tax authority's guidance for the retention period that applies to you, then write that period into your archive checklist so the decision is made once, not per project.

For files about to go to a developer or another studio, design handoff tools compares the ways to package briefs and assets so the receiving side gets the same structure you used.

FAQ

How can I organize files?

Start with one fixed hierarchy (client, then project, then a numbered set of stage folders) and one filename pattern that includes an ISO date and a zero-padded version. Then limit how files enter the system, because most mess comes from files saved straight from email or chat. Test the result by asking someone else to find ten files.

What is client file management?

Client file management is the set of rules for how files from and for a client are received, named, stored, shared and archived across a project. In practice it covers four decisions: where a file lands on arrival, what it is called, who can change it, and when it moves to the archive. A portal or shared drive is the tool; the rules are the system.

What are the four types of file organization?

The phrase comes from database design, where textbooks commonly list sequential, heap (unordered), hashed and indexed organization as ways records are stored. For client folders, the useful equivalent is the four sort keys you combine: by client, by project, by stage, and by date within the filename. The skeleton above uses all four, in that order.

Analytics consent

We use Google Analytics only after consent to understand reach and product usage.