Quick answer
A perfume OEM file name should tell both teams what the file is, which project it belongs to, which item or workstream it covers and whether it is the current revision. A short, repeatable naming system makes it easier to connect a sample comment, packaging artwork, quotation or pack-out document to the same configuration without relying on messages labelled “latest.”
The name does not prove that a file is technically feasible, commercially accepted, compliant or ready for production. It gives the team a shared reference for asking the right project-specific questions and recording the answer against the right version.
Why file names matter in an OEM project
One perfume project can create many moving records: a buyer brief, a sample code, bottle drawings, cap or pump references, artwork proofs, a carton layout, quotation versions and pack-out instructions. If an email says “please use the attached final artwork,” a supplier or a new buyer-side owner may not know which product, format or revision that attachment replaces.
Clear names reduce that ambiguity. They let a buyer point to one reference in a meeting, a feedback round or a request for a revised quotation. They also make older material easier to retain as background rather than accidentally treating it as the current instruction.
Use the same core fields every time
Choose a project code that the buyer and supplier can both recognize, then keep the same order of fields across the project. The system can stay simple.
| Field | Purpose | Example |
|---|---|---|
| Project code | Connects the file to one buyer project or SKU family | NORTHWIND-01 |
| Workstream | Shows whether the file concerns a sample, packaging, artwork, quote or pack-out | ARTWORK |
| Item or scope | Identifies the component, format or document purpose | CARTON-50ML |
| Revision | Distinguishes a controlled update from an earlier reference | REV03 |
| Date or issue marker | Helps people sort a named release or feedback round | 2026-10-22 |
| File type | Keeps the asset format visible where useful | PDF or AI |
For example, NORTHWIND-01_ARTWORK_CARTON-50ML_REV03_2026-10-22.pdf is easier to discuss than carton-final-v2-new.pdf. It identifies a project, a workstream and a revision, without claiming that the file is approved for every purpose.
Keep a short naming rule for each workstream
The same core fields can serve different project records. Add only the details that help people distinguish one reference from another.
| Workstream | Helpful identifier | Example filename |
|---|---|---|
| Buyer brief | Product format or SKU | NORTHWIND-01_BRIEF_EDP-50ML_REV01_2026-10-22.pdf |
| Sample feedback | Sample code and feedback round | NORTHWIND-01_SAMPLE_SMP-A12_FB02_2026-10-22.pdf |
| Bottle or component | Component reference and finish | NORTHWIND-01_COMPONENT_BOTTLE-B_CLEAR_REV02_2026-10-22.pdf |
| Artwork | Panel or component being designed | NORTHWIND-01_ARTWORK_LABEL-50ML_REV03_2026-10-22.pdf |
| Quotation | Scope and quote version | NORTHWIND-01_QUOTE_EDP-50ML_Q02_2026-10-22.pdf |
| Pack-out | Configuration and pack-out revision | NORTHWIND-01_PACKOUT_GIFTSET_REV01_2026-10-22.pdf |
Avoid using a date by itself as the version control method. Two files can be sent on the same date, and a later date does not explain what changed. A revision label, feedback round or quote version gives the conversation a stable reference; the date simply helps with sorting and traceability.
Make the current reference visible without deleting history
Do not rename an old file to remove it from view or erase the earlier version when a revision arrives. Keep it available, then mark the new item as the current reference in the project register, decision log or accompanying message. The message can state what the new file replaces and what it is being used for.
For example: “Please review NORTHWIND-01_ARTWORK_LABEL-50ML_REV03_2026-10-22.pdf. It replaces REV02 for this label layout. Please identify any project-specific inputs still needed before the next proof.” That is clearer than “use the final file,” and it does not turn an artwork revision into a production instruction.
Reference the exact file in every request and response
Put the complete filename in the subject line or first sentence when the discussion depends on a particular record. If several files are affected, list them separately instead of using a general folder name. A compact message can include:
- The project code and current purpose.
- The exact file or sample reference being discussed.
- What the buyer would like reviewed, changed or quoted.
- The decision owner or person who will consolidate feedback.
- The next response needed, without assuming the answer.
This approach is especially useful when a quotation, sample comment and artwork proof refer to the same product configuration but have separate revision cycles. Each file remains identifiable, while the buyer can ask the supplier which other records may need to be compared.
Set a boundary for “final” and “approved”
Words such as “final,” “approved” and “production file” can mean different things to design, procurement and manufacturing teams. Use them only with a named purpose. A file may be approved for buyer-side design review, sent for a quotation update or selected as the current artwork direction while technical, commercial or destination-market questions remain open.
If a project needs a production release or another formal approval, use the project’s actual review process and cite the exact configuration. A tidy file name supports that process; it does not replace it.
A practical file-naming checklist
- Assign one concise project code before files start circulating.
- Use the same workstream labels across buyer, design and procurement records.
- Name the component, sample code, product format or quote scope that distinguishes the file.
- Add a clear revision or feedback-round label before using a date.
- Keep the full filename when attaching or discussing the record.
- State what a new revision replaces and what it is being reviewed for.
- Retain superseded files as traceable background rather than deleting them.
- Keep a buyer-owned register that identifies the current reference and open questions.
- Do not treat a filename or folder label as evidence that project-specific reviews are complete.
Related reading
- Start the record set with a clear custom perfume manufacturer brief.
- Structure comments around the exact sample with perfume sample revision feedback.
- Coordinate packaging assets through private-label perfume packaging version control.
- Keep named questions and decisions together in a perfume OEM decision log.
FAQ
Should every perfume OEM file use the same long filename?
No. Use a shared core order, then add only the fields that distinguish the file. A sample feedback record may need a sample code and feedback round, while a quotation needs its quote version and stated scope.
Is a date enough to identify the latest artwork or quote?
No. A date can help sorting, but it does not say which revision or purpose the file represents. Add a revision or quote label and state in the message which earlier reference it replaces.
Does a file marked “approved” mean it is ready for production?
Not necessarily. Approval should name its purpose and the exact configuration. Project-specific technical, commercial, documentation and destination-market reviews may still be needed before a production instruction.