A project handover document is the record that exists when you don't. Whether a staff member leaves mid-project, a client takes assets in-house, or a second agency picks up where your studio left off, this document is what stops three weeks of progress from disappearing into someone's head. Most creative agencies skip it entirely. That's a mistake that shows up late, in the form of confused emails, missing files, and disputes over what was actually delivered.
When a handover document is worth writing
Not every project needs one. A single-deliverable job with a clear end point, a single contact, and no moving parts rarely justifies the time. But four situations reliably benefit from a written handover record.
- A team member leaves or moves off the account before the project closes
- A client is taking production in-house after your engagement ends
- A second agency or freelancer is picking up unfinished work
- A retainer client is changing their internal point of contact
In each case, the document does one job: it makes institutional knowledge portable. Everything that lives in emails, Slack threads, and a producer's memory gets compressed into a single readable file.
What a handover document actually contains
Keep it structured, not long. A handover document that runs to 20 pages gets skimmed. Aim for clarity over completeness. Five sections cover the essential ground.
1. Project summary
Two to three paragraphs at the top covering the project's purpose, the client's core objective, and where things stand right now. Be specific. "Brand video series for product launch in Q4" is useful. "Creative project for client" tells the next person nothing.
2. Deliverables status
A simple table works best here. List every deliverable, its current status (not started, in progress, in review, approved, delivered), and who owns the next action. Don't assume the incoming person knows what was originally scoped. Reference the scope of work template if one exists for this project, and link to it directly in the handover file.
3. Key contacts and relationships
List every person the incoming party will need to speak with: the client's decision-maker, their legal or finance contact, any third-party suppliers, and any internal team members who touched the work. Include name, role, email, and one line of context. "Sarah approves all scripts but defers to Marcus on budget" is the kind of detail that prevents a wasted week.
4. File and asset location
Where does everything live? List folder paths, drive links, or platform names for every asset class: raw footage, edited cuts, scripts, client briefs, contracts, invoices. If your studio uses a project management tool, link directly to the board or workspace. Don't assume the incoming person has access yet. Note any permissions they'll need to request.
5. Outstanding issues and known risks
This is the section most agencies skip. It's the most valuable one. List anything unresolved: a client approval that's been pending for two weeks, a licensing question that hasn't been answered, a supplier invoice that's disputed. If you know a risk exists, document it. The incoming person can't manage what they don't know about.
Common mistakes that make handovers useless
Writing a handover document is not enough. How it's written matters. Three habits consistently produce documents that fail in practice.
The first is writing for yourself instead of the reader. A handover document is not a project diary. The person receiving it doesn't share your context. Write every section as though the reader has never heard of this client before, because they may not have.
The second is treating file links as documentation. A Google Drive link with 400 unlabelled files is not a handover. Label folders, archive outdated versions, and leave a brief note explaining the naming convention. Fifteen minutes of organisation prevents hours of confusion on the other end.
The third is writing it after the fact. The best handover documents are built throughout a project, not the night before someone leaves. If your studio runs project debriefs at close, much of this content already exists. A handover document is the live version of that thinking, kept current as the work moves.
Formatting and delivery
A handover document should live somewhere both parties can access without needing to ask. A shared drive folder is fine. A project management tool is better, because it keeps the document next to the actual work. PDF is the wrong format. It can't be updated, and handovers often need updating in the first week as questions surface.
Send it with a 30-minute call, not as a standalone email. Walk the incoming person through it. Ask them what's unclear. The document answers most questions. The call surfaces the ones it missed. This is especially important when an external party (a client, a second studio, a new freelancer) is picking up mid-project, where the relationship context often matters as much as the file structure.
Connecting the handover to your broader process
A project handover document is most effective when it sits inside a broader process. Studios that already run a formal project closure report at the end of each engagement are halfway there. The closure report captures what happened. The handover document captures what's still in motion. Both are worth having, and neither replaces the other.
If your agency handles retainers, the handover document becomes a recurring artefact, updated every time a key contact changes on either side. Build it into your onboarding and offboarding process as a non-optional step. The agencies that do this don't scramble when someone leaves. They open the document and keep moving.