Create a File Manifest for a Multi-File Customer Delivery

Write for someone opening the package cold

The buyer does not know your production folder conventions. A manifest should explain the files in plain language, not repeat a directory listing without context. Put it at the package root and use a recognizable name such as README.txt or an accessible equivalent suited to the customer.

Include only the information needed to use the delivery. Avoid internal staff comments, private customer background, or credentials. If a file requires particular software, state the requirement that you have actually verified or direct the buyer to the relevant official instructions.

Copyable README template

PACKAGE TITLE:
ORDER REFERENCE:
PACKAGE REVISION:
PREPARED DATE:

START HERE:
Explain the customer's first useful action.

FILES:
Filename | Purpose | Version | How to open/use

INCLUDED SCOPE:
List the outputs purchased and supplied.

NOT INCLUDED:
Clarify source files or alternatives excluded from this package.

CHANGES FROM PREVIOUS DELIVERY:
Describe changes, or state first delivery.

HELP:
Quote the order, package revision, and affected filename.

Fictional completed example

Demo order 5165 contains a logo package. The “start here” instruction says to open the preview sheet to identify the primary and alternate marks. The file list describes the screen image and the agreed vector export separately. The scope note explains that unused concepts are excluded. This is more useful than naming the archive “final-assets.zip.”

If the customer later reports a missing transparent image, support can compare the purchased scope, manifest, and archive contents. The manifest does not prove the file was present unless the package was actually checked; it supplies the checklist for that verification.

Keep the manifest synchronized

1. Assemble the final package in a clean folder.
2. Write or update the manifest from that folder's actual contents.
3. Open each listed file and confirm its revision and purpose.
4. Remove any unlisted drafts or obsolete alternatives.
5. Create the archive or hosted destination.
6. Download or extract a fresh copy and reconcile it again.

When replacing one component, decide whether the whole package revision changes and update the manifest accordingly. A stale README can be more misleading than no README because it looks authoritative.

Deliver the package through the QuickAttach file-or-link workflow after checking the upload constraints. The manifest is a document your team prepares; it is not an automatically generated QuickAttach feature or a guarantee of compatibility.