Deliver a Clean Client File Handoff
A creative project is not fully useful if the client cannot find the final file, open it or understand what they may change. Handoff deserves a deliberate place in the project plan. The goal is a small, intelligible package that another person can use without a long rescue conversation. This guide follows a simple design-and-document assignment; adapt the folder structure and checks to your actual agreed deliverables, software and permission arrangements.
Photo: Edmond Dantès · License. Illustrative stock photography.
Match the package to the agreed deliverables
Start with the confirmed scope and make a delivery checklist. If the package includes a print PDF, a screen PDF and an editable source file, check all three individually. Do not substitute a screenshot for an editable file or assume that an export includes its linked assets. Name which files are final and which are references. If a final factual approval is outstanding, make that status visible and discuss whether delivery should wait. A folder containing every draft creates confusion rather than demonstrating extra value.
Use a folder structure that explains itself
For a modest assignment, try 01-final-exports, 02-editable-source and 03-readme-and-credits. Add a references folder only when it is useful and permitted. Name files by project, purpose and version, such as repair-workshop-handout-print-v1.pdf. Avoid final-final-new or personal abbreviations that only you understand. Keep internal notes and rejected concepts outside the client package. Do not include hidden temporary files, unrelated assets or another client's material when copying folders. A small tidy package is easier to inspect and safer to share.
Check the receiving environment
Ask which application the client will use to edit the source and whether they have access to the required version or fonts. Test the delivered copy from the delivery folder, rather than relying on the working file that still sees assets elsewhere on your computer. Open PDFs, play videos and inspect exported images. For a document, check page breaks, selectable text and links. For a video, compare dialogue and captions. If a feature cannot transfer cleanly between applications, explain the limitation and provide an agreed alternative.
Write a short, practical readme
A useful readme begins with the file to open first, then explains each output, any editing requirements and the location of credits. Example: use the screen PDF for email; use the print PDF for the agreed printer setup; update dates in the editable document and re-export before circulation. Include a known-issues section even if it simply says no known issues at delivery. Keep instructions in ordinary language. Avoid describing routine export settings as if they guarantee compatibility with every printer, platform or future software release.
Carry permissions into the handoff
Separate assets you created from licensed material and client-supplied files. Record source links and relevant usage notes, and clarify whether the client must obtain their own licence for editing or reuse. Do not redistribute a font file merely because it was installed on your computer. The Copyright Office identifies photographs, illustrations and software among works that may be protected; your handoff should preserve the practical permission information instead of assuming ownership of everything in the project folder. Ask for specialist advice when rights are disputed or unclear.
Confirm receipt and define support
Send one delivery message with the folder link, deliverables list and a request to confirm that files open. Use a controlled sharing method appropriate to the material and verify the recipient. Tell the client how to report a delivery defect and what support was agreed; a handoff should not imply indefinite updates. Keep your own dated archive according to the project arrangement and remove unnecessary personal information. Once receipt and outstanding items are resolved, mark the project complete in your log so it does not remain an ambiguous open task.
Your working checklist
Checkmarks stay in this browser when storage is available. They do not submit a form or complete a booking.
Put it into practice
- Compare the delivery folder with the agreed scope and remove internal drafts. Confirm that every promised variant is present and that outstanding approvals are clearly recorded.
- Open each file from the actual delivery location. Check links, page breaks, playback and source dependencies using the environment the client plans to use where practical.
- Add a concise readme and asset-credit record. Explain which files serve which purpose, what the client needs to edit them and any known limitations.
- Send the package through the agreed channel, verify the recipient and request confirmation that it opens. Record completion and the boundaries of any remaining support.
Before you finish
- Final files are distinguishable from reference and source files.
- The package contains no other client's data or internal notes.
- Editable files include permitted dependencies or clear alternatives.
- The readme explains which output to use first.
- Receipt, unresolved items and agreed support are recorded.
Common questions
Should I include every draft?
Usually no. Deliver the agreed final files and useful supporting material. Keep your internal archive separately unless the project specifically includes drafts or process work.
What if the client cannot open my source format?
Resolve the receiving application before delivery where possible. Offer an agreed alternative and explain what editing capability is preserved or lost rather than renaming a file extension.
Can I include third-party fonts in the folder?
Only when the relevant licence permits that distribution. Otherwise provide the font information and appropriate source, or use an agreed alternative that the client is authorised to access.