A project handover template for client-service work
Short answer: a useful handover tells the receiving person what was delivered, where it lives, what is unresolved and who acts next. It records access and an actual acceptance decision. Use this template for a website, design or consulting engagement; it is not an employee exit checklist or a construction completion certificate.
Open the editable handover template and completed example. No signup required. Copy it into your document tool or save the plain-text file. The example is fictional, not evidence of a customer outcome.
What to include
| Section | What the receiving person needs | A common failure |
|---|---|---|
| Scope and version | Agreement, delivered version and accepted changes | An old proposal is treated as the final scope |
| Deliverables | File or system location and the relevant check result | A folder link without permission to open it |
| Open issues | Impact, owner, next action and target date | Unfinished work disappears when the project is closed |
| Access transfer | Named recipient, appropriate role and confirmed access | Passwords pasted into a shared document |
| Ongoing responsibility | Maintenance owner, renewals and support boundary | Everyone assumes someone else owns the next update |
| Acceptance | What the approver accepted, exceptions and actual response | Silence or a draft email is treated as approval |
Completed example: a five-page website
Juniper Studio Client commissioned five pages, two revision rounds and a training call. Alex owns delivery, Casey takes over the CMS, and Rowan approves. In this fictional packet, build v1.3 and guide v1.0 are ready for review on November 20. Rowan's acceptance is still pending.
The team photo is missing, so the About page retains an agreed placeholder. Casey owns the image request for November 23. A sixth-page request is explicitly outside the accepted scope and awaiting a separate quote. Neither item disappears behind a green project status.
Alex asks Casey to confirm the CMS invitation works. The packet names the domain and hosting account owners, links the checked files and records the actual support terms. It contains no password, access token or recovery code. Rowan is asked to accept the named build version or list changes; a lack of response keeps the approval task open.
Run the handover in four steps
- Prepare the packet. Compare the agreed scope with the actual deliverables. List every exception and remove internal notes the client should not see.
- Check the receiver's access. Ask the named receiving person to open the files and sign in using their own account. Record the confirmation, not merely that an invitation was sent.
- Request a specific decision. Name the version, exceptions and response date. Use your agreed approval and contractual process.
- Close or continue deliberately. Save the actual response. Keep disputed or incomplete work open with an owner and next action. Revoke temporary access when the remaining work permits it.
This is an operational template. It does not replace an agreement or transfer rights by itself. Replace the example's support dates and terms with those you actually agreed.
Using the packet in Flori
Keep the packet with the delivery project, track outstanding items as tasks, and publish only the material intended for the client on a Core client page. Check the actual approval response before closing the project. An assistant can draft the packet from saved records, but it cannot establish that someone accepted the work.
For the earlier stages, use the client onboarding checklist. For a handoff between assistants rather than to a client, use the distinct AI handoff guide.
FAQ
What makes a project handover complete? The receiver has the agreed deliverables and access, open issues have owners, ongoing responsibility is clear, and the actual acceptance decision is recorded. A filled-in template alone does not establish completion.
Can I use this without Flori? Yes. The downloadable Markdown file is plain text you can edit in any document tool. It includes both a blank outline and a fictional completed example.
What if the client has not approved the work? Record approval as pending, keep the relevant task open and agree the next action. Do not treat silence, an assistant's draft or a sent request as approval.
Start your workspace