Before closing a client project, list what you are delivering, who will receive it and what remains unresolved. Confirm that the recipient can use the agreed files, explain any required training and record who handles the next step. Sending a folder is one action; transferring responsibility for the finished work needs a clearer record.
For a solo service founder, the final week can feel like a sprint toward “done.” The files are ready, another project is starting and a short delivery email seems enough. But the client may still need to know which version is final, where the instructions are and whom to ask about an open issue.
In its guide to managing large design projects, AIGA recommends formalizing the handover of responsibility, preparing the client to use the work and holding a wrap-up discussion. Its guidance dates to 2007; the checklist below applies those project-management principles to a small service business. It is an editorial working tool, not a contract or an industry certification.
Key takeaways
- Match the delivery list to the actual agreement and approved changes.
- Identify a recipient and a usable version of each deliverable.
- Give every unresolved item a status, owner and next date.
- Keep delivery, acceptance, payment and future support as separate records.
Start with the agreed finish line
Open the agreement and any approved changes. List the deliverables, formats and handover requirements you actually agreed to provide. Do not build the final list from memory or from everything that happens to be in your working folder.
If the agreement is unclear, mark the uncertainty and discuss it before claiming completion. A folder containing many files is not evidence that every required item is present. Nor does a client request at handoff automatically become an included deliverable.
For an unclear additional request, use the revision-versus-scope-change worksheet to compare it with the current agreement. Keep a correction to agreed work distinct from a new request.
Make a delivery manifest the client can use
The manifest is a small index, not a second copy of every file. One row per deliverable is usually enough to start.
- Deliverable (What to record: A clear name tied to the agreed work)
- Final version (What to record: Filename or version identifier and date)
- Location (What to record: The agreed delivery route or restricted link)
- Intended recipient (What to record: The person or role receiving responsibility)
- Format and use (What to record: What the file is for and what is needed to open or use it)
- Check (What to record: Whether delivery and access have been confirmed)
- Open item (What to record: Any unresolved issue and its next step)
Use a naming scheme the recipient can follow. If source files, drafts and exports have different purposes, explain the distinction rather than putting them into one undifferentiated folder. Include only what the agreement and applicable rights allow you to deliver.
A file transfer does not by itself settle intellectual-property ownership, licensing or the right to reuse third-party material. Check the applicable terms rather than treating the manifest as a rights-transfer document.
Check access without making everything public
Use the agreed recipient and delivery method. Confirm that the intended person can open the final materials and knows which files to use. A link that works for you may depend on your own login or permissions.
Do not solve an access problem by making confidential client work public. Resolve the specific recipient’s access through the approved system. Keep passwords, recovery codes and other secrets out of the manifest and ordinary email attachments; use an appropriate secure handover method if account access is part of the agreed work.
If a service account, subscription or third-party approval is needed, record the dependency and who is responsible for it. Do not silently transfer billing, ownership or permissions in order to mark a checklist complete.
Give unfinished work an owner, not a vague promise
An unresolved item should say what is known and what happens next. “Will fix later” leaves the client carrying the follow-up.
Record the issue, whether it concerns agreed work or a proposed addition, the person responsible for the next action and the date to check it. If timing depends on client input, name that input. Keep estimates separate from confirmed commitments.
In a hypothetical handoff for a set of presentation templates, the final files may be delivered while the client’s nominated user still needs training. The manifest can show that delivery is complete, training remains scheduled and a named person will confirm the session. It should not label the whole project accepted merely because the download link was sent.
AIGA recommends a client wrap-up discussion to assess satisfaction and identify defects or corrections. Follow your own project’s acceptance process. Delivery, receipt, acceptance and payment can have different meanings under the agreement; a checklist does not make them interchangeable.
State where this project ends and support begins
Tell the client where to report a problem with the delivered work and what support, if any, is included under the agreement. Keep that separate from future enhancements or a new service offer.
If continued support is not yet agreed, describe it as an option to discuss, not something already booked. Do not use a closeout note to promise open-ended revisions or to invent a cutoff that contradicts the original terms.
Finally, keep an internal record of the delivered version, approvals and unresolved decisions. AIGA also recommends an internal review of what went well, what did not and which improvements need an owner. That review is different from the client-facing manifest. Do not accidentally share internal costs, unrelated client information or private discussion notes with the delivery folder.
Frequently asked questions
Does sending the final folder mean the client accepted the work?
Not necessarily. Follow the acceptance process in the applicable agreement and keep delivery, receipt and acceptance distinct.
Should the client receive every working file?
Check the agreed deliverables and relevant rights. Do not assume every draft, source file or third-party asset is included.
What if the client cannot open a link?
Resolve access for the intended recipient through the approved delivery method. Do not make confidential work public as a shortcut.
What should happen to an unresolved issue?
Record the issue, its status, the next action, a responsible person and a check date. Do not hide unfinished work behind an overall “complete” label.
Method: AIGA’s November 2007 project-management guidance informs the handover and review principles. The manifest and hypothetical example are GREY Journal’s editorial synthesis, not tested business outcomes or legal advice.
