File Naming and Folders for Remote Teams

When a team shares an office, a lost file costs a quick question across the room. Remote teams can't do that. Someone is asleep, offline or on another project. So names and folders have to answer the question, and that only works if the team runs them the same way each day. This guide covers who owns what, how files move from intake to delivery, and the routines that keep a shared project tidy. The examples use a fictional client, ACM.

Who owns naming and folders

Give each job one clear owner. Ownership doesn't mean doing all the naming. It means someone keeps the rules and answers questions.

• Naming lead (studio level): keeps the written naming pattern and the template folder. Approves changes to either. Often a producer, a lead designer or the studio head.

• Project owner (per job): sets up the project folder from the template, checks names before deliveries and runs the weekly tidy-up for that job.

• Everyone else: names files when they save them, follows the template and flags anything the rules don't cover.

Write the owners at the top of the project's naming page, so a freelancer joining at 2 a.m. their time knows who to ask.

Folder and role names are examples; adapt them to your team.

From intake to delivery

A simple flow most studios can adapt:

1. Set up. The project owner copies the template folder and names it with the project code, for example ACM_Launch/.

2. Intake. Client files go into 00_In/, in a dated subfolder such as 00_In/20261104/. Leave client names as they arrived, unless your client agreement says otherwise, so you can match them to the client's emails.

3. Work. Working files live in 01_Project/ and 02_Assets/, named with the studio pattern from the first save.

4. Review. Exports for review go into 05_Review/ with the version in the name.

5. Deliver. Approved files go into 04_Out/ in a dated subfolder, named the way the client's spec asks, or your pattern if there's no spec.

6. Close. When the job ends, the project owner moves older versions into _old/ and notes where the project lives.

Handoff steps

When work changes hands between people or time zones:

1. Save as a new version. Don't hand off a file you're still overwriting.

2. Check the name. Project code, asset, description and version, in the usual order.

3. Put it in the right folder, not in a chat thread or a personal folder.

4. Write a three-line note: what the file is, what changed, and what's next.

5. Say who has it now. One person owns the next step.

One example of the difference a name makes:

Weekly hygiene routine

Pick a fixed slot, such as Friday afternoon in the project owner's time zone. About 15 minutes per active project:

• Look through 05_Review/ and 04_Out/ for names that break the pattern, and fix them before the next handoff.

• Move superseded versions into _old/.

• Clear out download duplicates like (1) and copy.

• Check for stray folders such as New folder/ or a second review/.

• Note any naming questions that came up, and send them to the naming lead.

Checklists

Starting a remote project

• Project owner named

• Folder copied from the template

• Naming page linked in the project, with owners at the top

• Client and asset codes agreed

Before each handoff

• New version saved

• Name follows the pattern

• File is in the shared project folder

• Short note sent, and the next owner named

Before a delivery

• Names match the client's spec or your pattern

• Only approved files in the delivery folder

• Versions match the project files they came from

Check your names

Prisma: file-naming and folder-structure tools for creative studios. Paste a few of your current names or folder paths into Prisma Scanner. It's free, needs no signup, and gives a score plus recommendations on where names break good practice. When you're ready to fix them, Prisma Hub, the Prisma app for Mac, suggests names based on your own rules. It's designed to fit into creative pipelines.

Open Prisma Scanner