File naming standards for SMEs: the end of ‘quote_final_v3_FINAL_ok.docx'

· 8 min read · SilverData team

In most companies we visit, the wrong version of a file goes out to a client every so often. Not because someone is incompetent — it's just that the folder holds quote_ACME_final.docx, quote_ACME_final_v2.docx and quote_ACME_final_v2_FIXES_MK.docx side by side, and the sales rep has four minutes before hitting send.

This isn't an expensive problem to solve. You don't need a hundred-thousand-euro DMS, a new cloud platform, or a migration project. You need one A4 sheet of naming rules that everyone in the company actually starts using. The rest is self-discipline — which the standard enforces on its own, if it's designed well.

In this post we show what standard actually works in Polish SMEs, why certain things (spaces, national characters, version numbers in filenames) always come back to bite you, and how to roll new rules out without a team revolt.

Why this isn't cosmetic

Try one thing on Monday morning. Ask someone in sales how long it usually takes them to find the right version of a quote for the client they're about to call. The answer is typically somewhere between 3 and 15 minutes. Multiply that by the number of such moments a day and the number of people in the team.

At one of our clients — a 30-person wholesaler of technical parts — we measured this in the 6-person quoting team. Average search time was 12 minutes per resumed customer conversation. Three months after we rolled out a simple naming standard and remapped the SharePoint folder structure, the average dropped to 45 seconds. It wasn't a new application or AI — it was one page of rules and two days of file cleanup.

On top of that come the things that are harder to measure but painful:

File naming is one of those "boring foundations" we wrote about in our post on preparing your company for AI. Without it, every layer on top sits on sand.

Rule 1 — one convention across the whole company

The biggest mistake we see: every department has "their own way". Accounting dates files one way, sales another, production doesn't date them at all, and marketing throws the campaign and an emotion into the name (NEW_OFFER_SPRING_TOP.pdf). When a file crosses department lines — which in a healthy company it does — nobody knows what it is.

The standard has to be one, for everyone. Even if it feels 20% wrong to HR and 20% wrong to production, it's still better than five different ones. File naming is not the place for individualism.

A simple recipe we recommend as a starting point:

`` YYYY-MM-DD_[client-or-project]_[document-type]_[short-description].extension ``

For example:

The name reads like a sentence. Sorting by name gives chronological order for free. The client jumps out at first glance.

Rule 2 — dates in ISO format

Always put the date first, always in YYYY-MM-DD. This isn't about aesthetics — it's the only format where files sort chronologically when the operating system sorts alphabetically.

Writing 08-08-2026 or 8.8.2026 shoots you in the foot: the system will place 08-08-2026 between 08-07-2025 and 08-09-2020 and you'll get an unusable mess. The ISO 8601 format (YYYY-MM-DD) is an international standard precisely because it solves this problem once and for all.

Rule 3 — no spaces, no national characters

This is the rule that meets the most resistance, so let me say it plainly: it's not about aesthetics, it's about the fact that spaces and non-ASCII characters in filenames still break half the tools out there.

Spaces in filenames:

National characters (Polish ą, ć, German ä, ö etc.):

The conclusion is simple: replace spaces with dashes, replace national characters with their ASCII equivalents. Cooperation Agreement 2026.docx → 2026-01-15_ACME_agreement_cooperation-2026.docx. It looks less pretty, but it doesn't cause problems three years from now.

Rule 4 — versioning belongs to the system, not the name

This is where the most companies die. Save as… and appending _v2 to the name is the worst possible way to version — because six months later you have _v2, _v3, _final, _final_v2, _definitive and _MK_really_final.

Versioning belongs to a system that has it built in:

If you really must have some lifecycle marker in the name, make it a status, not a version number: _draft, _review, _approved. Three states, each unambiguous. There is no state called "final_v2".

Folder structure — shallow, not deep

A tidy filename loses its point if the file is buried inside Company/Shared/Sales/2026/Q3/Clients/A-K/ACME/Quotes/Drafts/. Deep folder nesting doesn't help anyone in practice — by the third level, people don't remember where to put things anyway.

Our recommendation:

Rollout without a revolt

The standard itself is 20% of the work. 80% is convincing the team to actually use it, and translating it onto the existing files without paralysing the office for a week.

What works in practice:

  1. Write the standard on one A4 page. Not a 30-page document — one sheet with five rules and five examples. People won't read it if it's longer.
  2. Don't migrate the old files. Set a cutoff date ("from 1 September, new files follow the standard") and leave the archive alone. Old files get renamed on the fly the next time someone opens them. A weekend "big-bang" migration always ends badly.
  3. Ask one team lead in each department to enforce the rule. Not IT. Salespeople listen to the head of sales, not to the sysadmin.
  4. Add a short checklist to onboarding. A new hire gets the standard in their first week, alongside passwords and access.
  5. Do a review after one month. Pick 20 random new files. Which ones don't follow the standard? Talk to the authors — usually it turns out one rule was unclear. Fix the A4 sheet.

The list is short because it has to be. Every extra step lowers the odds of adoption.

When the standard won't roll itself out

There are two scenarios where plain "let's write down rules and stick to them" won't work. One — the company has multiple offices and each has its own digital history. Two — the file structure has ten years of legacy on top and a real migration is needed, because new files keep landing in the old folders.

In both cases it's worth talking to someone who has already been through this in other companies — folder-migration mistakes can cost weeks of team time. The first call is free and takes half an hour.

File naming is a boring foundation — but without it, no search, no AI and no Copilot will ever start working sensibly in your company.

← Back to blog