Quick answer
A perfume OEM deliverables register is a buyer-side list of the files, samples, answers and other project outputs that a team has requested, received or still needs to review. It gives every item a purpose, current reference, owner and status so a project does not rely on email subjects or a shared folder as its only record.
The register does not say that a requested document, sample, component or service is available for every project. It does not replace a quotation, technical assessment, market review, approval record or production instruction. It simply makes the request and its current evidence easier to find.
Why a request list needs more than a filename
In a perfume project, a buyer may ask for a quotation, a sample, an artwork proof, a component reference, a document or a response to a question. Those items often arrive in different channels and at different times. A filename by itself does not show why the item was requested, which product or packaging version it relates to, or whether the buyer still needs another response.
That gap can create avoidable confusion. A team may treat an attachment as the final version when it was sent only for discussion. A supplier may receive the same request twice because the earlier response was not linked to the request. A new colleague may see that a file exists but not know which current product scope, sample or artwork revision it supports.
A compact register keeps the record practical. It should make it possible to answer four questions quickly: what was requested, why it matters, which exact reference was received, and what still needs to happen.
Start with the project reference
Give the register a clear project label and keep the scope close to the top. Use the buyer’s own project code, product or SKU description and the current product or packaging references where those are available. Do not use a broad label such as “new perfume project” when several options are under discussion.
The register can point to other project records, but it should not duplicate their decisions. A quotation belongs in the commercial record; feedback on a received sample belongs in the sample feedback tracker; an artwork outcome belongs in the artwork approval log. The deliverables register tells the reader where the request and response sit in the wider project map.
A practical deliverables register
| Deliverable requested | Purpose of the request | Exact scope or reference | Requested from / owner | Current status | Where the response or outcome belongs |
|---|---|---|---|---|---|
| Quotation response | Compare the defined commercial scope | Current quotation request reference | Buyer commercial contact / supplier contact | Requested, received or needs clarification | Quotation correspondence or query log |
| Sample or sample update | Identify the item being reviewed | Sample ID and the stated feedback scope | Buyer project lead / supplier project contact | Requested, received, under review or superseded | Sample receipt record and feedback tracker |
| Artwork proof or file | Review the stated visual reference | Artwork filename and revision | Buyer design contact / artwork contact | Requested, received, comments recorded or replaced | Artwork approval log |
| Packaging component reference | Connect a component discussion to one identifier | Component description, code or image reference | Buyer packaging contact / supplier contact | Requested, received or needs clarification | Packaging component register |
| Project-specific question response | Keep an open question traceable | Query ID and source question | Named question owner | Open, answered or routed for review | Query log |
| Requested documentation question | Record what was asked without presuming availability | Exact product, pack and destination context | Named project contact | Open, response received or needs review | Query log and the relevant project record |
These rows are examples of a buyer-side record structure, not a statement that every deliverable can be supplied, accepted or relied on for every project. Replace each row with the actual scope and source reference before sharing it.
Separate a request from a received item
One request can produce several responses. A buyer might receive an initial artwork proof, comments, a revised proof and a final buyer-side outcome. Do not replace the original request with the newest attachment. Instead, keep the request ID or request line and add each received reference with its date and status.
This distinction is useful when a project changes direction. The register can show that a previous item was superseded without presenting the newer item as approved. A status such as “received for review” is more precise than “complete” when the buyer has not recorded an outcome in the appropriate approval or decision record.
Make the scope visible in every row
The most useful column is often the scope or reference column. It should identify the exact item under discussion rather than a general category. For example, “carton artwork, revision C” is more useful than “carton file.” “Sample S-04, feedback on opening notes only” is more useful than “perfume sample.”
When the scope has changed, open a new row or clearly mark the earlier one as superseded. Do not carry an old sample ID, artwork version or commercial question forward just because the subject line looks similar. A clear reference lets the buyer and supplier discuss one item without implying that related items have the same status.
Use statuses that describe evidence, not outcomes
Choose simple status labels that say what the register can actually support:
- Requested — the buyer has asked for a defined item or response.
- Received — an item or answer has been received and linked to the request.
- Under review — the identified item is being considered in the relevant buyer-side process.
- Needs clarification — the response does not yet match the stated request or scope.
- Superseded — a later identified item has replaced this version for the current discussion.
- Closed in another record — the outcome is recorded in the named approval, decision, feedback or commercial record.
Avoid labels such as “approved,” “production-ready,” “compliant” or “confirmed” unless the supporting record, exact scope and authorized owner are identified elsewhere. The register is an index of project movement, not proof of a technical, legal, commercial or production conclusion.
Keep ownership and the next action explicit
Every open row should have one clear next action. That does not require a promise about timing. It can be as simple as “buyer to consolidate feedback in the sample tracker,” “route the question to the named owner,” or “link the current artwork revision to the approval record.”
Avoid assigning an outcome to a person who only passed along a file. The person who sends an attachment may not be the person authorized to approve it, assess its suitability or answer a destination-market question. Record the communication route separately from the decision owner when they are different.
Review the register at project handoffs
Review the register before a buyer changes project owner, sends a focused supplier meeting agenda, issues a revised request or prepares a project status update. The aim is to prevent the next person from reopening an already answered question or using an older reference by mistake.
At each review, ask:
| Check | Buyer question |
|---|---|
| Identity | Does each row identify the correct project, SKU, file, component or sample? |
| Purpose | Does the register explain why the item was requested? |
| Source | Is the received file, sample or response linked to the request? |
| Status | Does the label describe evidence rather than an unsupported outcome? |
| Ownership | Is the next action assigned to the appropriate role or record? |
| History | Are earlier versions retained as history and clearly separated from the current item? |
If an item needs specialist assessment, commercial confirmation or destination-market review, use the register to point to the exact question and current reference. Do not use a blank status field or a generic “complete” label to hide that the relevant review has not happened.
Related reading
- Define the current buyer-side inputs in a perfume OEM project scope summary.
- Track open questions and documented responses in a perfume OEM query log.
- Identify packaging references in a perfume OEM packaging component register.
- Record sample identity before feedback in a perfume sample receipt log.
- Preserve evidence routes with a perfume OEM approval evidence index.
FAQ
Is a deliverables register the same as an approval log?
No. A deliverables register shows what was requested, received and routed. An approval log records the authorized outcome for a defined reference. Link the two records when they concern the same item, but do not treat receipt of a file or sample as approval.
Should the register include every email attachment?
No. Include the attachments, samples and responses that affect the current project record or need a follow-up. A register works best as a concise map to defined project evidence, not as a duplicate inbox.
What if a supplier response does not match the request?
Keep the received reference linked to the original request and mark the row as needing clarification. State the specific gap in the query log or other relevant project record so the next response can be tied to the same scope.