“The files have been sent” does not mean a project handover is complete. The recipient may be unable to open a file, may not know which version is final, or may be missing the information needed to continue the work. An acceptance checklist connects each deliverable with a visible condition that the receiving person can check.
This guide uses a fictional handover of a small website's editorial materials. It covers notes, drafts, and review evidence, not a technical deployment or a legal acceptance process. If your organization has contractual acceptance rules, use those rules and keep this note as supporting coordination material.
Replace activities with outcomes
An activity says what the sender did: “uploaded the guide.” An outcome says what the recipient can verify: “the final guide opens, its title matches the approved version, and the last section is present.” The outcome gives both sides a shared way to identify missing work.
Begin with a short list of deliverables. Keep each item concrete enough to inspect. “Documentation” is too broad; “editorial checklist dated 15 October” is easier to locate. Avoid combining several unrelated files into a single item that can only be marked fully complete or fully incomplete.
Identify who checks each item
The sender is responsible for providing the material, while a named receiver checks whether the acceptance condition is met. A project coordinator may track progress, but that does not make them the person who can confirm every specialist detail.
Use roles when names are not yet agreed, and resolve them before the handover date. “Someone from content” is not a useful assignment. An acceptance note should reveal missing ownership rather than make the list look finished by assigning everything to a generic team.
A worked handover item
Deliverable: Final review guide, version 3.
Location: Agreed shared project folder.
Sender: Editorial coordinator.
Receiver: Incoming editor.
Acceptance condition: File opens; version matches the approved record; all six sections and the final checklist are present.
Evidence: Receiver's dated confirmation in the project record.
Exception: Image captions require a separate review.
Next action: Assign caption review before the publication decision.
This fictional item does not require the receiver to approve the captions accidentally. The exception preserves that boundary. A handover is clearer when incomplete work is visible instead of being hidden beneath a broad “done” label.
Keep evidence proportional
Evidence should help another person understand why an item was accepted. A short confirmation may be sufficient for opening a text file. A more complex requirement may need a test result, review link, or a checklist completed by the appropriate person.
Do not collect screenshots simply to make the record look substantial. A screenshot of a folder does not show that its files contain the correct text. Match the evidence to the condition. If a requirement is “recipient can edit the draft,” the check must include editing a harmless copy, not merely seeing the filename.
Handle exceptions without losing them
Give each exception a description, owner, next action, and due date or review point. Decide whether it blocks acceptance of the whole deliverable or only a particular part. That decision should be explicit and made by someone authorized to make it.
Avoid treating “accepted with exceptions” as equivalent to “nothing remains.” Link outstanding work to the team's task system. The checklist can show the handover state, while the task system carries the work required to close the gap.
Walk through the receiving task
Ask what the recipient will do first after the sender is unavailable. Can they identify the current file, understand the next deadline, and find the decision that explains an unusual choice? Those questions often reveal missing context that a file inventory alone does not catch.
For the fictional editorial handover, the incoming editor needs the current draft, the review comments, the publication brief, and the unresolved caption question. Old experiments may be retained in an archive, but they should not compete with the current deliverables in the main handover list.
Confirm the final record together
Review the checklist before the transition, leaving enough time to fix missing files or unclear ownership. Record the date of the check and the version of the materials it covers. If a file changes afterward, determine whether its acceptance check needs repeating.
Keep the accepted record stable. Append later corrections or link a new version rather than quietly changing the checklist that both sides used. This helps explain the state of the project at the time responsibility moved.
Use a note without creating a second project system
A browser note works well for drafting the acceptance conditions and collecting questions before a handover meeting. Move final confirmations and restricted evidence into the system your team uses for durable records. Export important drafting work so it is not dependent on one browser profile.
The checklist has done its job when the receiver can continue the work and both sides can identify what remains open. A longer list is not automatically a better handover. Clear conditions, appropriate evidence, and visible exceptions are what make the record useful.
Use the BiNotePads online notepad to adapt this example. For a separate copy of important work, follow the browser-note backup guide.