Digital Filing: Folder Structure and Naming Rules That Hold Up

Why can nobody find anything on the shared drive?

Most companies at some point moved from files on individual computers to a shared repository, on a server or in the cloud. That was right. Still, in many offices you hear the same questions every day: where is the current quote? Which version of the contract is the valid one? Why are there three folders called “Customers”?

The cause is rarely disorder in the usual sense. Every employee has their own system that makes sense to them. The problem arises when these systems overlap in one repository. This leads to the guiding question of this article: What folder structure and naming rules does a small company need so that employees can also find files that others have filed?

To answer it, we first look at how people actually find files again. Then we introduce the thinking model of other people’s order and weigh two perspectives: shared or personal filing. A folder structure, a naming rule, and a guide to introducing them follow.

A filing system is not good when it looks tidy, but when a colleague finds someone else’s file on the first try.

How do people find files again?

One might think folder structures are outdated now that every system has a search function. Research shows the opposite. Bergman, Beyth-Marom, Nachmias, and colleagues (2008) examined in two studies whether better desktop search programs change behavior. Participants estimated that they found 56 to 68 percent of their files by clicking through folders and only 4 to 15 percent through search. Better search programs changed little. Search was used mainly when someone could no longer remember where a file was.

The alternative to folders, keywords or tags, has hardly caught on in daily work either. In two studies with 75 and 23 participants who could use both, the participants clearly preferred folders. When tags were used, it was usually only one per file, and in targeted retrieval, tags were slower and less successful (Bergman et al. 2013).

For a small company, the finding is practical. The folder structure is not a relic but the tool the team uses to find files. Whoever leaves it to chance relies on a search that in daily work is used only as a last resort. The studies concern personal computers and date back some years. But the same group’s later research on shared repositories explicitly confirms the importance of folders.

The thinking model: the problem of other people’s order

Research on information management distinguishes two ways of sharing files. In personal information management, everyone receives the file, for example as an attachment, and files it according to their own system. In group information management, the file sits in a shared location, and everyone works with the same order. The latter has clear advantages: a single version, no duplicate filing, joint editing.

But it has a catch that Bergman, Israeli, and Whittaker (2020) call the problem of retrieving files organized by others: in a shared repository, you mostly search for files that someone else has organized according to their logic. In an earlier study with 275 participants, searches failed in 22 percent of cases in shared repositories and in 13 percent in personal ones. The decisive finding lay one level deeper: in folders created by others, searches failed in 28 percent of cases, in self-created folders in 5 percent. Even unorganized default folders, at 17 percent, did better than other people’s order.

In their 2020 study, the authors had 289 participants search for 1,557 of their own shared files in their usual work environment. They confirmed that failure rates in shared repositories are about twice as high as in personal ones. In addition, large collections, many versions of a file, and a high workload worsened searches in shared repositories more than in personal ones. The authors conclude that shared repositories scale less well, and they explicitly point to fast-growing organizations.

Shared or personal filing? Two perspectives

From these findings, one could conclude that everyone should file for themselves again. That is the first perspective, and it has the numbers on its side. The second perspective counters: without a shared repository, there are several versions of the same file, knowledge stays on individual computers, and it is lost when an employee leaves. The article on how to reduce tool sprawl describes the guiding rule for this: one piece of information, one place.

A study by the same research group shows how the two can be combined. Massey, Lennig, and Whittaker (2014) interviewed 27 people whose teams used shared repositories and had hardly any problems. The teams were small, members knew each other’s tasks, and they used flat, simple folder structures that nobody had to learn first (reported in Bergman, Israeli, and Whittaker 2020). Oh (2026) came to a matching result in a survey of 534 researchers: those most satisfied were those whose team had explicit rules for organizing and archiving shared files and cleaned up regularly.

I therefore consider the shared repository right, but only on one condition. Its order must be so simple and so clearly written down that it becomes predictable for everyone. Then it is no longer other people’s order but a shared one. Small companies are in a favorable position for this, because they match the conditions in the study by Massey and colleagues: small teams, short paths, known tasks.

The filing charter: five rules on one page

From the findings, a tool can be derived that is called the filing charter here: a single page with five rules that applies to the entire shared repository and is visible to everyone.

• One place: Every type of file has exactly one valid location. Email attachments and copies on your own computer are not filing.
• At most three levels: Below the top level there are at most two further folder levels. Whoever wants to go deeper must justify it in the charter.
• Fixed naming rule: Every file follows the same pattern of date, customer or project, content, and version.
• One valid version: Only the current version sits in the working folder. Older versions go into an “Archive” subfolder or are kept through the system’s version history.
• One person responsible: One person maintains the charter, creates new top-level folders, and cleans up once a quarter.

The second and fourth rules address the findings directly. According to Bergman, Israeli, and Whittaker (2020), large, nested collections and many versions made searches in shared repositories particularly difficult. The fifth rule prevents what research describes as fragmentation: everyone maintains only their own part, nobody feels responsible for the whole, and the repository clogs up with files nobody dares to delete.

Folder structure and file names: what does this look like in a small company?

The top level is best organized by the company’s areas, not by people. The second level follows customers, projects, or years, the third level the type of document. The following example shows a structure for a service company with 15 employees. It is an example and must be adapted to your own company.

Two details make the difference. The numbers in front of the areas fix the order regardless of how the system sorts. And the “Organization” area contains the charter itself and the process pages as described by the one-page method. Whoever collects answers and templates for sales, as described in the article on sales knowledge management, also stores them in a fixed place.

Which file naming rule works?

A naming rule defines which parts a file name consists of and in what order. It makes files recognizable outside their folder too, for example as an attachment or in a list of search results. A four-part pattern has proven effective.

The date comes first in the form year, month, day, so that files sort chronologically by themselves. Umlauts and other special characters as well as spaces are avoided because they cause problems when exchanging files with other systems. The version gets a number instead of words like “final” or “new,” because experience shows that “final” is almost always followed by “final2.” The rule belongs in the charter and applies to all new files from a set date. Old files are renamed only when they are being edited anyway.

How do you introduce the new filing system without rebuilding everything?

1. Look at the current state (30 minutes)

   Note the top level of the repository and count how many folders are there. Ask two colleagues where they last failed to find a file.

2. Draft the charter (60 minutes)

   Write the five rules and the top two levels on one page. Have it checked by two people who use the repository daily.

3. Put the new structure next to the old one

   Create the new structure and move the old one entirely into a folder called “Legacy.” Nothing is deleted.

4. File the new way from a set date

   All new files go into the new structure according to the charter. Whatever is needed from the legacy folder is moved when it is opened.

5. Clean up after three months

   Whatever has not been opened in the legacy folder for three months goes into the archive, provided no retention obligation prevents it.

Moving files when they are opened is where many introductions save time. Instead of re-sorting thousands of files at once, only what is actually needed moves. After a quarter, the living part of the repository is in the new structure without anyone having sacrificed a week for it. The article on lean in the office counts such searching as waste through motion.

For teams working in different places, the charter is even more important, because the quick question across the desk disappears. The article on organizing distributed teams describes which further agreements are then needed. And for customer data, the same logic applies as in the CRM: rules the team actually follows rather than rules that sound good, as described in the article on CRM data quality.

Conclusion: what a filing system needs to hold up

The opening question was
folder structure and naming rules a small company needs so that employees can also find other people’s files. The answer: a shared repository with an order that everyone can predict. That means one place per file type, at most three levels by area, a fixed naming rule with date and version number, only one valid version in the working folder, and one person responsible.

As shown, people find files mainly via folders, and they fail particularly often in folders others have created. That does not argue against the shared repository but against one whose order exists only in individual heads. This leads to a simple observation: a shared repository works when its rules fit on one page and everyone knows that page.

What you can put into practice right away

1. Ask two colleagues which file they last spent a long time looking for and where they finally found it.
2. Count the folders at the top level of your repository. More than ten is a sign of missing areas.
3. Write the filing charter with the five rules and the top two levels on one page.
4. Set a date from which all new files are filed according to the charter.
5. Name the person who maintains the charter and cleans up once a quarter.

The charter itself belongs at the very top of the “Organization” folder. Whoever is new to the team gets it on the first day.