Campaign File Naming: A Simple System for Small Teams
By Réson
4 min read
In this article
- Start with one campaign identifier
- Keep the campaign file naming pattern short
- Separate version from approval
- Approve the package, not just the picture
- Keep working files away from release files
- Make a three-minute release check
- Decide what counts as a new version
- Introduce the system without a cleanup project
- Record what actually went live
- Related reading
Campaign file naming should help a teammate answer one question quickly: “Is this the right file for the job I am about to do?”
A name such as “final-final-2” cannot tell them what was approved or whether the caption changed afterward. A useful convention connects the file to its campaign and version, while a separate record explains its approval status.
You do not need to reorganise the entire archive to begin. Apply a small, consistent system to the next campaign and improve it when a real ambiguity appears.
Start with one campaign identifier
Choose a stable identifier for the campaign, not for every individual idea.
For a hypothetical winter mug launch, that might be:
2026-11-winter-mug
The date refers to the campaign’s planning period. It is not proof of publication. If a launch moves, you can keep the identifier and update the schedule rather than breaking links and references.
Avoid including personal information, confidential project details or uncertain claims in filenames. Files often travel further than expected.
Keep the campaign file naming pattern short
Use this pattern:
campaign_channel_format_subject_language_v01.ext
For example:
2026-11-winter-mug_instagram_reel_handle-demo_en_v03.mp4
A teammate can identify the campaign, destination, format, subject, language and version without opening the file.
Keep the vocabulary small. Decide whether the team uses instagram or ig, then use one consistently. The exact abbreviation matters less than consistency.
Do not put every production detail in the name. Lens settings, model prompts and editing notes belong in the asset record or production brief.
Separate version from approval
Version numbers describe sequence. They do not describe permission.
v03 means the third saved version. It does not mean the file is approved, published or better than v02.
Keep a simple manifest alongside the assets:
| Asset | Version | State | Approved by | Approved for |
|---|---|---|---|---|
| Handle demonstration reel | v03 | Approved | Campaign owner | Instagram reel with caption C02 |
| Product carousel | v02 | In review | — | Not yet approved |
| Website banner | v01 | Working | — | Not yet approved |
Record the approval date and the destination link after publication. If the team has a system that maintains this information, use it rather than maintaining a competing spreadsheet.
Approve the package, not just the picture
An image may be harmless with one caption and misleading with another. A video may require a specific disclosure or a destination that explains the offer.
Treat the release package as:
- The visual or video.
- The caption or accompanying text.
- Alt text or captions where applicable.
- The destination URL.
- The intended channel.
- Any required disclosure.
Give the package its own identifier, such as release-01. When the caption changes after approval, record the change and decide whether the package needs another review.
This is especially useful when an AI tool produces several attractive alternatives. The approved choice must be unambiguous.
Keep working files away from release files
A minimal folder layout is enough:
2026-11-winter-mug/
01-brief-and-sources/
02-working/
03-review/
04-approved/
05-publication-record/Do not place unapproved exports in the approved folder “temporarily.” That shortcut weakens the meaning of the folder.
Preserve source files and editing projects when they are needed for future changes. Avoid overwriting an approved version with a new export under the same name.
Make a three-minute release check
Before posting, the publisher checks:
- The file matches the manifest’s approved version.
- The caption and destination match the approved package.
- The product, offer and dates are still current.
- The correct channel and account are selected.
- The published URL is recorded after posting.
In Réson, drafts, revisions and approval states provide useful context inside the workspace. Apply the same discipline to downloaded files so the handoff to an external channel does not lose that context.
The best system is the one your team can maintain on a busy day. Start with one campaign, document the convention in a few lines and refine it only when a real ambiguity appears.
Decide what counts as a new version
Write down a simple rule before the team starts exporting. Any change that could affect the published result should create a new version: revised wording, a different image, a changed destination, corrected captions or a new crop that alters what the viewer sees.
A file-format conversion may be an export of the same creative version, but it still needs a distinguishable name. For example, keep the creative version at v03 and add an export label such as “1080x1920” or “web”. Do not use the same filename for a large master and a compressed delivery copy.
If two people are working on alternatives, label the branches by a useful description, such as “product-closeup” and “in-use”. Avoid both collaborators independently calling their file v04. The campaign owner can select the preferred direction before the next shared version is assigned.
Introduce the system without a cleanup project
Pick one active campaign. Name its approved assets consistently, create the manifest and add a short note explaining the rules. Leave historical folders alone unless a file is being reused or creates a real risk of confusion.
During the first handoff, ask a teammate to find the approved package without help. Watch where they hesitate. If they cannot tell whether the caption belongs with the video, improve that relationship in the manifest. If the filenames are too long to scan, remove information that is already recorded elsewhere.
Keep one person responsible for changing an asset’s approval state. Other team members can propose corrections, but a clear owner prevents conflicting decisions.
Record what actually went live
After publication, record the destination URL and the released package version. If the platform changes a crop, removes formatting or fails to display captions, note that difference and correct it through the normal review process.
The publication record should describe the customer-facing result, not merely say that someone clicked “Post”. This closes the gap between campaign file naming on your computer and the asset people actually encounter.
Explore Réson’s campaign workflow.
Related reading
Frequently asked questions
Should approval status be part of the filename?
It can be a helpful cue, but do not rely on it alone. A separate manifest or workspace record should identify the approved version, caption, destination and reviewer. Renaming a file does not create approval.
Do I need to rename every existing campaign file?
No. Start with the next active campaign. Update older files when they are reused or when an ambiguous name creates a genuine publishing risk.
What should happen when an approved caption changes?
Save the changed caption as a new version and assess whether the package needs another review. A seemingly small wording change can alter the claim made by the accompanying image or video.
About the author
Réson
Réson is an AI marketing workspace for small businesses. It learns your business from your website, drafts posts, campaigns and articles, and waits for your approval before anything goes out.