A photography delivery becomes difficult to use when files are named final-1, final-new or image-copy. The problem grows with bedding sets, fabric colorways and towel bundles because similar images can easily be attached to the wrong SKU.
A practical handoff system does not need complex software. It needs stable identifiers, a documented view vocabulary, controlled versions and a manifest that lets an overseas buyer, catalog designer or ecommerce team understand the delivery without guessing.
Choose stable identifiers before the shoot
Use the buyer's approved SKU as the primary product key, with a supplier reference in the manifest when it helps coordination. Create unambiguous codes for color and size rather than shortening them differently in every folder. Avoid customer names or confidential launch details in filenames when a neutral project code is sufficient.
Define a compact view vocabulary such as overview, contents, detail-seam, detail-label, package-front or scene-one. Document the vocabulary instead of expecting recipients to decode abbreviations. Add sequence numbers only when order matters, such as an unboxing series.
Build a filename that remains useful outside its folder
A useful pattern is project_SKU_color_view_version.ext, adapted to the team's system. Keep separators and capitalization consistent, remove unsafe punctuation and avoid putting changeable marketing titles into the technical filename. The name should still identify the asset if someone downloads it alone.
Do not use dates as the only version control or append repeated words such as latest and final-final. Choose a clear revision marker, record release status in the manifest and never assign the same filename to visually different active assets without an explicit replacement process.
| Field | Example | Rule |
|---|---|---|
| Project | CAT26 | Neutral code agreed for the delivery |
| SKU | BED104 | Exact approved product identifier |
| Color | SAND | One controlled code per physical colorway |
| View | DETAIL-SEAM | Term from the documented view list |
| Version | V02 | Increment only when the asset changes |
| Filename | CAT26_BED104_SAND_DETAIL-SEAM_V02.webp | Fictional example, not a client file |
Use folders for navigation, not for missing metadata
A simple structure can separate masters, delivery exports, previews and localized derivatives, then group product files by SKU. Do not mix internal contact sheets, arrival records and final customer-facing images. Make the released folder self-contained enough for a recipient who does not have studio working files.
For shared assets, keep one controlled source and list every applicable SKU in the manifest. Copying the same close-up into many folders creates drift when one version is updated. If each recipient requires a complete folder, automate or document the copies and preserve their source relationship.
Deliver a manifest alongside the images
For each file, record filename, SKU, color, view, file type, dimensions, version and status. Add notes for shared assets, concept images, composites or approved exceptions. The manifest is also the place to identify which requested shot was deferred rather than leaving a silent gap.
Include the agreed delivery scope and a contact for discrepancies, but do not place secrets, passwords or private access tokens in the manifest. If a transfer link expires, share access through the agreed secure channel and keep the file list independent of that temporary link.
- Every filename contains the product key and view role.
- Every delivered file appears once in the manifest.
- Dimensions and formats match the agreed outputs.
- Concepts, composites and shared images are labelled clearly.
- Superseded files are outside the active release folder.
Run a recipient-side acceptance check
Ask the receiving team to open the package on its normal system, filter by a sample SKU and locate each required view. Check that files are readable, names remain intact and the manifest matches the actual count. Spot-check color labels, contents and localized variants against the brief.
Record missing, duplicate or corrupt files as delivery issues and resolve them before the library is distributed further. File acceptance confirms the handoff package; it does not approve the physical product, production goods or channel publication. Keep those decisions in their own workflows.
