Original editorial cover illustration — Southlake Vision. Product imagery is illustrative.
Specify the handover as an operational record
White label product photography becomes easier to maintain when the delivery is specified as a file system rather than a promise of neutral branding. Begin with the agency's publishing workflow: who receives the assets, how the product is identified, which files can be uploaded and which materials are internal. Agree the scheme before production so names and approvals do not need reconstruction at the end.
The example below uses a hypothetical agency code AG07 and product code KT204. These codes are illustrative, not actual client information. The Southlake Vision agency partnership page can support a discussion about the required operating arrangement. File naming does not itself settle confidentiality, commercial usage or portfolio permission; those remain separate agreed terms accompanying the handover.
Choose fields that have one stable meaning
Use a compact set of fields with documented definitions. A practical example is AG07-KT204-DETAIL02-EN-V03-FINAL.webp. Field one identifies the project, field two the SKU, field three the asset role, field four the language where relevant, field five the version and the final field the status. Do not include a language label on a text free photograph unless your own system requires it.
Keep optional fields optional rather than filling names with meaningless placeholders. Define the accepted role labels, such as MAIN, DETAIL, LIFESTYLE or INFO, in a short naming guide. A role describes the file's purpose, not the order it happened to be photographed. Agree character conventions with the receiving system. The exact punctuation matters less than stable definitions and the ability to map every derivative back to its source.
Separate versions, approval and delivery states
A version number tells you that something changed; it does not prove approval. Use an explicit status record that distinguishes working proof, selected, approved and delivered. A file named final should only enter the release folder after the designated agency reviewer has approved it. Avoid vague suffixes such as final-new-latest, which transfer the burden of interpretation to the publisher.
For example, KT204-INFO02-V02 could be an approved layout awaiting one factual correction, while V03 becomes the delivery version after confirmation. Retain the earlier proof in the internal archive, not beside upload-ready files. Agree how corrections after delivery are numbered and announced. The photography production team needs a visible link between feedback and the resulting file, so a renamed export cannot silently detach from its approval history.
Build the manifest around the next user’s task
A manifest is a small record of what the delivery contains. Include the final file name, project code, SKU, asset role, source reference, approval date, approving contact and intended destination. Add language, crop or model usage reference where relevant. Keep sensitive information to the agreed recipients. The manifest should help the publishing team select the correct asset without opening every file.
Number the rows and reconcile them against the release folder. If row twelve describes a portrait crop, that exact file should exist and be identified as portrait. Record missing items as pending rather than implying the delivery is complete. A plain spreadsheet or other mutually usable format is sufficient; the operational value comes from accurate fields and clear ownership, not from a visually elaborate presentation.
Maintain a source to derivative map
One approved photograph may supply a gallery export, an infographic and a thumbnail. Record that relationship so a product correction can be traced through every affected asset. The source reference can be an internal stable identifier rather than a client-visible working file name. If the agency renames deliverables before sending them onward, retain the agency to studio mapping privately.
For Amazon creative work, connect the approved copy and specification version to designed images as well as the photograph. A changed capacity statement may affect a graphic even when the source photograph remains accurate. This is why a source map is more useful than a folder of visually similar exports. It makes later corrections bounded and inspectable instead of relying on someone's memory of which layout used which picture.
Review metadata deliberately rather than deleting blindly
Inspect file properties, document comments, layer names, embedded links and accompanying messages for information that should not reach the recipient. Examples include an unrelated client code, an internal reviewer note or a draft download link. Agree which metadata is expected and which is inappropriate. Do not remove rights or attribution information without considering the permissions attached to the asset.
Where editable files are included, inspect them as working documents. Check linked resources, font dependencies, hidden layers and comments. A neutral preview does not establish that the underlying file is ready for client handover. Keep an inspection record identifying the file, issue, corrective action and checker. The requirement is controlled release, not indiscriminate erasure of useful technical data or a claim that white label means unrestricted ownership.
Run a release check against the manifest
Before sending, assign one person to reconcile three things: the approved list, the delivery folder and the manifest. Confirm that all expected files open, correct variants are represented, superseded proofs are excluded and usage references accompany relevant model or third party material. Test links using the permissions the recipient will actually have. A working studio link may still fail for an agency publisher.
Use the Southlake Vision process to agree when this release check occurs and who confirms completion. If delivery is phased, give each release a clear identifier and list the remaining items. A partial release can be useful, but it should never leave the agency guessing whether an absent file is unfinished, intentionally omitted or lost during transfer.
Acknowledge receipt and preserve the mapping
Ask the agency to acknowledge receipt and identify any missing or unreadable material against the manifest. Confirm the authoritative release version. If a correction follows, issue a replacement notice listing the affected files and what has changed. Avoid resending the entire folder without explaining which assets should replace the earlier delivery, because that creates unnecessary opportunities for outdated uploads.
At Southlake Vision, discuss your agency's naming system, file destinations and delivery preferences when scoping the project. Keep the naming guide, final manifest, approval references and agreed permissions together. For repeat work, review the scheme before reusing it with another client. A dependable white label handover is a traceable package that can be presented appropriately and maintained after the original production conversation has ended.
Frequently asked questions
Must every agency use the filename in this example?
No. The code is an illustration. Use fields that match the receiving system and document their meaning. Stable project, product, role and version references matter more than copying a specific punctuation pattern.
Should all metadata be stripped from white label files?
No. Decide what is appropriate for the agreed handover and retain information required for technical use or rights management. Review comments, links and unrelated identifiers deliberately rather than deleting everything automatically.
What if the agency renames the files before client delivery?
Keep a private mapping between the studio identifier and the agency filename. Update the manifest or accompanying register so a later correction can be traced to the correct source and derivative files.