Shared drive folder structure and file naming rules for a small company

A new colleague asks where the latest price list is. Three people answer with three different places: a folder called "Sales 2", a personal drive, and an email from March. The file exists in all of them, in slightly different versions, and none is marked as final.

This is not a tooling problem. Google Drive, SharePoint and a plain file server all end up like this when nobody has agreed on a few simple rules. The rules below fit a company of roughly ten to fifty people and can be introduced in one afternoon.

Why shared drives decay

Drives rarely start messy. They become messy through small, reasonable decisions. Someone creates a folder for a single project because the existing structure does not fit. Someone saves a copy "just in case" before editing. Someone leaves, and their folder stays because nobody knows what is in it.

After a year, search is the only way to find anything, and search returns ten files with the same name. People stop trusting the drive and keep their own copies, which makes it worse. The same pattern appears in intranets: when search is broken, people stop looking and ask colleagues instead.

Structure by how people look for things

The most common mistake is organising by who owns the file, such as one folder per person or per department with free-form content inside. A new employee does not know which person made the document they need.

Organise by what people are trying to do. In most small companies that means a short top level based on areas of work, such as:

• Company: contracts, policies, finance, legal, HR documents with restricted access.
• Clients: one folder per client, with projects inside.
• Projects: internal work that is not tied to a single client.
• Templates: current price list, proposal, contract, onboarding checklist. Only final versions live here.
• Archive: finished and old material, read-only for most people.

Keep the top level to five to eight folders. If you need more, you are probably mixing areas.

Three levels, no more

A good rule is three levels of folders: area, then client or topic, then year or project. A path such as Clients / Novak Logistics / 2026 / Proposal is easy to say aloud and easy to remember.

Deeper nesting causes two problems. People stop browsing and save files at the nearest convenient place, and long paths break in some sync tools and operating systems. If you feel you need a fourth level, put the distinction into the file name instead.

Avoid folders called "Misc", "Other", "New" or "Old". They collect everything that was not worth deciding, and they grow fastest.

One file naming pattern

A naming pattern does two things: files sort in a useful order, and a file name tells you what it is without opening it. Choose one pattern and write it on one page. A simple one is:

YYYY-MM-DD_Client_Document-type_v02.ext

For example: 2026-10-22_Novak-Logistics_Proposal_v02.pdf.

A few details matter more than they seem:

• Date first, in year-month-day order. Only this order sorts correctly in an alphabetical list.
• No spaces and no special characters. Use hyphens inside a part and underscores between parts. This avoids problems with links and sync.
• Version at the end, with two digits. v02 sorts before v10; v2 does not.
• "final" is not a version. Files called final, final2 and really-final are a sign that the pattern is missing. Use the next version number, and move the approved one to the place where final documents live.
• Short and in one language. Pick the language of the company and keep to it, including for document types.

Not every file needs every part. A meeting note may only need date and topic. The point is that a reader can predict the pattern.

Who may create folders

Open creation at the top is the main reason structures grow out of control. A practical split:

• Top-level folders: created by one named person, usually an office manager or operations lead. Requests go through a simple message to that person.
• Second level (client or topic): created by the owner of that area, for example the account manager for a new client.
• Third level and below: anyone with access to the area.

This keeps the shape stable while letting people work without waiting. If a new top-level folder is requested, ask whether it is really a new area or a subfolder of an existing one. Most of the time it is the latter.

Versions and shared editing

Part of the version problem comes from habit: people save a copy before editing because they fear breaking something. Modern drives keep version history, so say so explicitly and explain how to restore an earlier version. Once people trust the history, they stop making copies.

For documents that go outside the company, a final PDF is the exception to this. Save it in the client folder with the date, since that is what the client actually received.

Also agree what happens with documents under review. A simple approach is to keep the working file in place and put the sent or approved version next to it with a clear version number, rather than making a parallel folder structure for "drafts".

Access, not hiding

Drive structure and permissions are related but separate decisions. Do not hide files by burying them deep in the tree. Set permissions at the second level, such as Finance or HR, and let everything below inherit them. Review the access list when someone joins, changes role or leaves; that is the moment permissions drift. If your company already has a routine for offboarding or handover, add drive ownership to it, in the same spirit as handing over a runbook owner and access.

The yearly cleanup

A structure needs a yearly check, otherwise it drifts back. Set aside half a day once a year, ideally in January, with the person who owns the top level and one representative from each team.

1. Move finished work to Archive. Projects and client years that are closed go to the Archive folder, keeping their path.
2. Do not delete by default. Archive first. Delete only what has a clear reason, and check legal retention rules for contracts and financial documents.
3. Empty "Misc" and similar folders. Decide for each file whether it belongs somewhere or goes to the Archive.
4. Check ownership of leavers' files. Move anything still in use to a shared area.
5. Update the one-page rules if something no longer works.

Announce the date in advance, so people can object to a move before it happens.

Introducing the rules

Do not try to reorganise the entire drive at once. Create the new structure next to the old one, move current client and project material, and leave the old drive read-only for three months with a short note in the root folder saying where things went. Most people will move on when they see that the new place is easier. Put the one-page rules where new colleagues will see them in the first week, ideally in the same place as other onboarding information. If you run an intranet, link it from the start page; see our notes on intranet adoption for how to make such a link actually used.

Common mistakes

• Folders per person instead of per area of work.
• More than three levels of nesting.
• A naming pattern that exists only in the head of the person who invented it.
• Everyone allowed to create top-level folders.
• Deleting in the cleanup instead of archiving first.
• Reorganising everything in one weekend, without a transition period.

Summary

A usable shared drive needs a short top level organised by area of work, no more than three folder levels, one naming pattern with the date first and the version last, a named person who controls the top level, and a yearly cleanup that archives instead of deleting. Start with the one-page rules and the current clients and projects; the old material can follow later.

Sources

• Our related articles linked above.
• The folder limits, naming pattern and cleanup timing are working practices for small companies, not a formal standard; adjust them to your size and tools. No client results or market figures are claimed in this article.