A good client delivery makes three things obvious: which files to use, what they are for, and when they must be downloaded. Before sharing a link, prepare a delivery copy that a person outside your project can understand without a call.
This checklist works for design assets, documents, photography, and other finished files. Use the application's packaging tools as well when handing over an editable project with linked assets.
Start with the agreed deliverables
Compare the package with the scope you agreed with the client. Separate final outputs from source files and previews. Do not include unfinished alternatives just because they happen to be in the working folder.
A practical structure is Delivery_v03 with subfolders named Final, Source, and Reference, using only the folders the client needs. Add a short README describing each folder. If the client expects a single PDF, avoid making them search through an elaborate directory tree.
Use consistent version names
Choose a naming pattern such as Client_Project_Deliverable_v03.ext. Use the same version across the delivery note and package. Dates in YYYY-MM-DD order help with sorting, but a date alone may not distinguish multiple revisions made on the same day.
Avoid names like final_final_revised. When replacing a delivery, say which version is superseded and whether every file changed. For example: “v04 replaces v03; only the brochure PDF changed, and the approved logo assets remain the same.”
Check the files as a recipient
- Open final documents outside the source application when possible.
- Check page counts, image dimensions, audio playback, or other relevant outputs.
- Confirm that linked resources needed for editing are included.
- Remove unrelated notes and unintended personal information from the delivery copy.
- Check that filenames match the list in the README.
Then test the recipient link in a separate browser session. Download at least one file from each important category. Do not send a management link that can change or delete the transfer.
Write a delivery message people can act on
Include the project name, version, link, package size, contents, and exact download deadline with a time zone if relevant. Tell the client whether they are reviewing the work or receiving approved final files. If access requires a password, communicate it through a separate appropriate channel.
Project delivery v03 is ready. The package contains the approved print PDF and editable source files. Please download the package before the stated expiry and confirm that both folders open. Reply with any missing-file issues, quoting the filename.
This example deliberately separates receipt from approval. Downloading the files does not necessarily mean the client has reviewed or accepted the work.
Keep a recovery path
Retain the delivered version and your working source according to your agreement. Record which link and package you sent. If a link expires, you can recreate the same delivery rather than guessing which files belonged to it.
Common questions
Should I replace files behind the same link?
Only if the service supports it and the client can clearly distinguish the new version. A new package name and an explicit change note reduce ambiguity.
Is a download notification enough?
No. It may show activity, but it does not prove the intended recipient opened the correct files successfully. Ask for a short receipt confirmation when the handoff matters.
When choosing a WeTransfer alternative for client deliveries, consider how clearly the recipient can identify, download, and verify the final package.
← All articles