Practical guide

Write a delivery manifest that makes omissions visible

Last materially reviewed 2026-09-29

Quick answerList what the release contains, what it excludes and how the client should use it; a folder count is not a manifest.
What to know

Keep it short and specific

A manifest is a plain-language description of the release. Include the project reference, release identifier, date, purpose and expected files or groups. For each group, explain the intended use and any required software. Avoid documenting every temporary production file. The goal is to help a recipient recognize a complete usable delivery, not to export your internal task history.

What to know

Include deliberate exclusions

Name important items that a reasonable client might otherwise expect, such as editable sources, alternate languages or draft concepts. Refer disputed scope questions back to the agreed project record. A manifest records the intended package; it cannot unilaterally change the contract or establish that a client accepted an exclusion. Keep factual delivery notes separate from legal conclusions.

What to know

Use the manifest in checking

Compare the package against the manifest before sending and use it again when a client reports a missing item. Counts can help identify an omission, but equal totals do not establish that the right files are present. Keep version labels aligned across the note, folder and message so the recipient is not forced to decide between three different apparent release numbers.

What to know

A fictional manifest excerpt

Release 02 contains Print/poster.pdf for the printer, Screen/poster.jpg for approved digital placement and Readme.txt with size notes. Working drafts and stock-license documents are not included. One corrected export supersedes the previous poster PDF. This tells the client what to retrieve and what changed without claiming that a download, a checksum or the manifest itself constitutes approval of the creative work.

What to know

Put the decision into practice

Keep the manifest inside the delivered package as well as referenced in the message where practical. Otherwise a downloaded folder can lose its explanation when the email is unavailable. Check that the manifest itself names the same release as the actual files and does not describe an earlier draft.

Continue when useful

Next: Large packages

Organize large deliveries by meaningful use and explain their size; splitting a package randomly can create more confusion than it solves.

Open Large packages →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. pCloud file transfer and organization — Merchant documentation · help.pcloud.com · Merchant-controlled · checked 2026-09-29
  2. pCloud shared links — Merchant documentation · help.pcloud.com · Merchant-controlled · checked 2026-09-29
FICTIONAL RELEASE TICKET

Make “final” mean something.

A small manifest can be more useful than another download button.

Build your manifest →
Release
Cedar / 03
Inside
Print exports · screen assets · readme
Not included
Drafts and editable sources
Next action
Retrieve the package; confirm intended use

Illustrative structure only. Not a real customer delivery or acceptance record.