Translate the search question into the name
If people mainly search by project and document type, make those visible. “North-Project_Quantity-List_Draft” is one example. The specific separator matters less than consistent use. Check storage restrictions before choosing unusual characters or very long names.
Avoid personal abbreviations only the creator understands. A date helps when its meaning is clear. Establish whether it indicates creation, reporting period or approval. Without that agreement, an apparently precise number remains ambiguous.
Do not confuse status with hope
Labels such as “final”, “reallyfinal” and “new2” provide no dependable sequence. Use an agreed working state or version marker where it is needed outside the application. If the system offers version history, consider what additional information the file name must supply.
The extension should match the actual format. Do not rename it merely to make a file appear converted. Use the intended conversion feature and check the result afterwards.
Test difficult cases
Try the scheme on a template, corrected version and file with several attachments. If names become unwieldy, decide which details belong in a folder or accompanying note instead. Every property need not appear in the name.
Do not rename large amounts of existing material without checking. Links and active references may be affected. Begin with new files or an agreed small area. Keep the rule accessible with examples rather than relying on spoken explanations. Review unclear cases together so people do not quietly invent incompatible extensions to the naming scheme.
Test the naming scheme with edge cases
Try the scheme on a draft, an approved version and two similar cases. If both projects use the same name, a short stable reference may be needed. If understanding the sequence requires very long names, some information may belong in a folder or register instead.
Explicitly agree what a date means. It may describe a reporting period or the state of the work; those meanings should not be mixed. When introducing the convention, an example with its purpose explained is more useful than an abstract pattern alone.
Do not rename older material without checking active references. You may start with new files and rename important older collections selectively. The aim is better recognition, not a cosmetically uniform storage area whose existing references become confusing. Ask a colleague unfamiliar with a sample file to explain what its name tells them before making the convention standard across the team.
Keep the agreed pattern where new files are created so contributors do not have to infer the rules from older examples with uncertain history.
