What to include in a client project handoff

The last delivery email should help a client take responsibility for the work. A folder link on its own rarely explains which file is final, who pays for an account, or what remains unfinished. A useful handoff gives the recipient a route through those questions. This guide offers a practical structure for a small website or design project. Adapt it to the agreed scope, and ask the people receiving the work what they need to operate it. The aim is a document someone can use after the project conversation has faded from memory.

1. Write a short delivery summary

Start with the project name, delivery date, version, and the person responsible for answering handoff questions. Describe the work delivered in a few sentences. Identify the agreement or scope document that defines the project, then link to it if the recipient already has access. Keep the summary understandable to someone joining the client team later. An internal nickname or a reference to “the second version we discussed” will not help that person identify the final work.

Add a visible list of open items. State what each item needs, who owns it, and the next agreed action. If everything in the agreed scope is complete, say so plainly. Avoid implying that approval has occurred if the client still needs to review the package. Delivery, review, and acceptance can be separate events. Your document should reflect the actual state of the project rather than making the closing email sound more final than it is.

2. Build a file index with useful labels

List the main deliverables by their intended use. A design project might include editable source files, print exports, screen exports, and a usage guide. A website might include the code repository, content inventory, image library, and editing instructions. For each group, provide a link, a description, and any relevant version information. Test the links from an account with the recipient's permissions. Access that works for the project creator may not work for the client.

Choose names that help someone select a file without opening five alternatives. “Logo for dark backgrounds” is more useful than “logo-final-new-2.” Keep working drafts separate from approved exports. If the client needs historical versions, place them in a clearly labeled archive and explain why they are retained. A clean index can sit above an existing storage system; you do not have to move every file into a new service to make the delivery understandable.

3. Record account ownership and access

Create an account inventory for the services included in the project. Record the service, account owner, billing contact, administrative contact, and the action needed to complete any transfer. Keep passwords and recovery codes out of the handoff document. Use the service's supported invitation or ownership process and an appropriate secure method for any sensitive material that must be shared. Confirm the recipient can sign in independently before you remove access that is still needed for the transfer.

Be precise about the difference between access and ownership. A person who can edit a website may not control the billing account. Someone who receives a domain renewal notice may not have permission to manage the domain. For each important service, ask the client to identify the responsible role or person. If a future employee will take over, make the intended handover route clear. Check the current documentation for each service because its roles and transfer steps can differ.

4. Explain how to perform ordinary tasks

Write instructions around the tasks the client expects to do. For a small website, that might mean changing an opening time, adding a team member, or replacing a photograph. Use a short sequence with enough context to recognize the correct screen. Include a reminder about previewing and checking the result. Avoid writing a complete manual for features the project does not use. A concise guide to five common tasks can be more useful than a long tour of every menu.

If you record a walkthrough, provide a text alternative for the essential steps and label the recording with its date. Screens and controls may change later, so explain the purpose of the action as well as the button to click. For web content, the W3C accessibility tutorials provide references on topics such as images, forms, and page structure. Link the relevant guidance where it helps the client maintain accessible content; a link alone does not verify the accessibility of the finished project.

5. Make maintenance responsibilities explicit

Identify the recurring work that will remain after delivery. Depending on the project, this could include content updates, subscription renewals, software maintenance, backups, or checking a contact form. Assign responsibility based on the actual agreement. Do not assume that the client understands an ongoing service is excluded because it never appeared in a proposal. Put unresolved responsibilities in the open-items list and settle them before describing the transition as complete.

For each recurring task, record the owner and where the instructions live. If a maintenance provider is involved, make sure the client knows how to contact that provider and what the provider has agreed to handle. Avoid promising a response time on someone else's behalf. Where you are offering support yourself, state the agreed scope and period. Questions about a delivered file and requests for a new feature should have distinct paths so neither party has to guess what happens next.

6. Give the client a review sequence

Offer a short set of checks that reflects the delivered work. Ask the recipient to open the file index, download one relevant export, sign in to a transferred account, and attempt one ordinary task. For a website, include the important visitor paths that were part of the project. This is a handoff review, not a claim that these few steps replace all technical testing. Its purpose is to confirm that the recipient can use the package and identify missing information.

A confirmation step should show what the client is confirming. The GOV.UK check answers pattern offers a reference for reviewing information before submission. In your handoff, give the client a chance to report a correction or unresolved item. Use language aligned with the project agreement. If acceptance has legal consequences, have the relevant terms reviewed appropriately instead of improvising them in a last-minute email.

7. Try the checklist on an example

Imagine delivering a small café website. The summary identifies the five pages and the agreed editing guide. The file index points to approved photography and the site repository. The account inventory shows the café owner controlling the domain and billing, with a manager invited as an editor. The instructions explain changing opening hours and publishing a menu update. One open item remains: the café must supply a replacement photograph for a seasonal promotion.

The walkthrough then asks the manager to change a draft opening time and preview it. If the manager cannot find the correct page, improve the guide while the project context is still fresh. Record the agreed next action for the photograph and the support contact for questions. The final acceptance record can refer to the package that was actually reviewed. That is more useful than a broad statement that “everything has been sent,” which leaves ownership and remaining work unclear.

Keep the template short enough to maintain

Turn these sections into a reusable document, then remove the parts that do not apply to the current project. Review it before the delivery date, while there is still time to resolve access problems. Keep sensitive information separate and limit access to the people who need it. After the client has used the package, ask which instruction or link was missing. Add that improvement to the template. A handoff checklist earns its place by helping the next person work independently, one specific task at a time.