How to name client files so the right version is easy to find

A file name has work to do after the handoff. Your client may save it to their desktop, forward it to a colleague or search for it weeks later. When that happens, the surrounding folder and your original email may be gone. A useful name carries enough context to identify the file on its own.

You do not need an elaborate naming policy. Choose a short pattern, use it consistently and explain any terms the recipient might not recognise. The fictional examples below use a café menu project, but the same approach works for a photo delivery, campaign package or set of approved audio files.

Start with the questions a recipient will ask

Before deciding on separators or version numbers, write down what makes each deliverable different. Usually the recipient needs to know the client or project, the item, its intended use and the revision. A format extension identifies the file type, but it rarely explains which file to choose. Two PDFs might be a print menu and a screen menu with different layouts.

Think about the person who receives the forwarded file. They should be able to recognise the project without knowing your internal job number. If you need that number for your own records, keep it alongside readable words instead of making it the entire name.

Choose one pattern for the delivery

A useful starting point is client-project-item-use-version. For example, harbour-autumn-menu-print-v01.pdf names the client, project, item, intended use and revision in that order. Keep the same order across the package so related files are easy to scan together.

• harbour-autumn-menu-print-v01.pdf — the print menu.
• harbour-autumn-menu-screen-v01.pdf — the screen menu.
• harbour-autumn-menu-social-square-v01.jpg — the square image.
• harbour-autumn-menu-source-v01.zip — the agreed editable package.

Omit fields that add no useful distinction. A small delivery does not need a department code, campaign code and job code in every name. Keep enough context for a loose file to make sense, while leaving the detailed explanation in a delivery note or readme.

Make versions mean one thing

Pick either a numbered revision or a date as your usual version marker. Numbered revisions work well when a project changes several times in one day. Dates are useful when the package corresponds to a particular event or regular delivery. Write dates in year-month-day order, such as 2026-10-08, and use the same convention throughout.

Decide whether the number belongs to each file or the whole package. If you version each file separately, the print menu might be v02 while the unchanged screen menu remains v01. Say that in the delivery note. If the client expects one coordinated release, give the package a release label and keep a short record of what it contains.

Avoid building a history into the name with words like “final”, “new” and “latest”. They become ambiguous after another revision. Approval status belongs in the handoff message or your project record; a version marker identifies the actual file the client should use.

Use recipient language for the variants

Name the purpose before adding technical detail. “Print”, “website” and “social-square” help someone choose an asset without opening every file. Include dimensions, language or colour variants when those differences matter to the work. Explain unfamiliar abbreviations in the note that accompanies the delivery.

For a multilingual menu, for example, add consistent language labels to both exports. For a photo set, keep the image identifier consistent between print and web versions so the client can find the matching image. Do not rename related files independently and leave the recipient to guess which ones belong together.

Keep folders and names working together

Organise a larger package into a few folders based on use, such as Print, Screen and Source. Keep the individual names meaningful even inside those folders: clients may download or forward only one item. A folder called Print does not make export-7.pdf a helpful file name.

Rename delivery copies before attaching them. For editable projects with linked assets, use the originating application's packaging workflow where appropriate and reopen the packaged project to check it. Renaming a linked image casually can leave the source document looking for its old name. Keep your working project and the client package separate while checking.

Check the names alongside the actual files

Read the delivery as a list, then open the files. A clear name is only useful if it describes the contents accurately. Check that each variant matches its label and that the version in your message matches the attachment. Remove temporary exports and superseded copies before sending.

In SentIt, give the delivery a readable title and use its message to explain which files to use. Review the recipient page before sharing the link. When replacing a file, attach the corrected version and remove the superseded one as needed; the delivery can keep the same link. Tell the client what changed, because an earlier download still exists on their device. See the guide to updating shared files for the revision workflow.

Save your chosen pattern and two examples in your own project template. That makes the next handoff easier to prepare and easier for a returning client to recognise. Before sending, run through the rest of the client file handoff checklist so the contents, context and access details are as clear as the names.