File Naming Conventions for Photo Teams That Survive

Why solo naming habits fail the moment a team joins

When you are the only person touching files, your naming scheme lives in your head, and the head fills in the gaps. final means "the one I exported last." IMG_0412 copy 2 means "the one before the crash." None of that is written down, so none of it transfers.

A team breaks the scheme in three ways. First, a second person needs to answer a question you never had to ask: which of these two files is current? Second, people export from different tools, and each tool has its own idea of what to append on a name collision. Third, a client who downloads a file and sends it back will rename it, usually by adding their own words in front.

A convention for a team therefore has to do two jobs. It has to make the right file findable by someone who was not at the shoot, and it has to stay readable after other people and other software have added to it. That second job is why the rules below are strict about order and separators.

The five fields, and why they are in this order

Use these five fields, separated by underscores, with hyphens only inside a field:

Date first, in ISO form. 2026-03-14 sorts correctly as plain text. 03-14-2026 and 14.03.26 do not, and a team that spans the US and Europe will read half of them wrongly. Year-month-day is the only order that is both unambiguous and self-sorting.

Client and job second. Keep it to one or two words in lowercase with hyphens. The reason to avoid spaces is practical: a space becomes %20 in a URL, and some scripts split on it.

Frame number from the camera, not renumbered. The original sequence number is the one thing that ties the delivered file back to the card. Pad it to four digits. If your camera rolls over at 9999, add the card or body letter before the number (a0412) so two cameras on one shoot cannot collide.

Version last, before the extension. This is the rule that matters most, and the next section is about it.

One rule for versions: r1, r2, r3, never "final"

A version token needs to be machine-sortable, human-obvious and impossible to outrank. final, final2 and FINAL_v3_use-this fail all three, because there is always one more round and nothing sorts them. Use r1, r2, r3, with r for round, and treat the number as the review round the file was delivered in.

Two details keep this honest. The raw export from the camera has no version token at all; the first retouched delivery is r1. And a version number is only ever incremented by a delivery, never by a save. If you saved twelve times while working, that is still r1 when it goes out.

This is a naming-level fix for a problem that is bigger than names, and a filename can only carry the answer, not enforce it. We cover the broader question in version stack vs folder names, and the quick diagnosis of why a team ends up with five candidates for "current" in how to find the current edit.

What breaks when files cross hands

A convention is only tested at handoffs. Here are the renames that actually happen, the mechanism behind each, and what the convention does about it.

The pattern is that software appends and humans prepend. Putting the identifying fields first and the version last means a prepended client note pushes the file out of sort order, which is visible, and an appended (1) lands after the version, where it is easy to strip. A name that fails visibly is much better than one that fails silently.

Tools that match files to records have the same problem in miniature. Appruva's Photoshop panel works out which frame an open document is by an XMP stamp first, then by filename (folder-aware and tolerant of suffixes), and it asks you rather than guessing when neither is conclusive. A clean convention makes that second path reliable, and the stamp makes it survive a rename.

Folders: two levels, and no meaning in the folder name alone

Names live in folders, and folder structure is where teams over-engineer. Use two levels: the job, then the stage. For example 2026-03-14_acme-spring/ containing 01-raw, 02-selects, 03-retouch and 04-delivered.

Number the stage folders so they sort in workflow order. Do not put the round in a folder name such as retouch-v2; the round belongs in the filename, where it travels with the file. A file that moves from one folder to another with its version still attached is self-describing. A file whose only version information is the folder it happened to sit in loses it the first time someone drags it to the desktop.

Repeat the job name in the filename even though the folder already says it. Files leave folders constantly: they are attached to emails, dropped into chat, opened from a recent-files list. The redundancy is the point.

The cost of not doing it, with the arithmetic shown

Nobody has measured how long a typical photo team loses to ambiguous filenames, so here is a model you can run with your own numbers rather than a figure to quote. Assume a team member searches for or confirms a file version 10 times a week, takes 3 minutes each time, and works 48 weeks a year.

The assumptions are the weak part: change 3 minutes to 1 and the total is 24 hours for three people. The shape of the calculation is the useful part. The cost scales with team size, because every additional person is another reader of the names. A convention costs one afternoon to agree and nothing to maintain once it is a habit.

The larger cost is the wrong-file delivery, which is not modelled here because it does not have a time cost; it has a trust cost. Sending r1 when the client approved r2 is the kind of mistake the convention exists to make visible before the email goes out.

Rolling it out without a fight

Conventions fail socially before they fail technically. Four steps make adoption stick:

1. Write the example, not the rule. One real filename on a one-page doc teaches faster than a paragraph about separators.
2. Rename at export, not afterwards. Set your export preset to produce the pattern. Renaming a finished batch by hand is where typos come from; Lightroom can build names from tokens at export time.
3. Apply it to new jobs only. Do not rename the archive. Retroactive renaming consumes a week and breaks every existing link and reference.
4. Let the review tool own the status. Names say what a file is. They should not say whether it is approved. Keep approval state in whatever you review in, not in the filename, or you will be renaming files every time a client changes their mind.

That last point is where the limits of naming show. A filename can carry shoot, frame and round; it cannot carry "client approved this on Tuesday." Keep the two jobs separate and the convention stays small enough that people actually follow it.