A handover note should help another person resume work without reconstructing every conversation. For unfinished work, the important information is the current state, what remains open, where the evidence lives, and which next action is safe to take. A chronological account of everything the outgoing person did may obscure those essentials.
This guide uses ChatGPT to draft an original handover note from supplied work records. Examples are fictional, and current documentation was checked on October 6, 2026. The workflow preserves uncertainty and ownership gaps rather than turning an incomplete project into a finished-looking summary.
Define the handover boundary
Identify the work being handed over, the receiving role, the cutoff date, and the period the note must cover. State whether the recipient is expected to continue delivery, monitor the work, or prepare a review. These are different responsibilities and require different levels of detail.
Confirm the actual assignment separately. A draft note naming a recipient does not establish that the person has accepted ownership or has the necessary authority. Record the agreed role or mark assignment pending when it is not confirmed.
List what remains outside the handover. A note for one project stream should not imply responsibility for unrelated tasks mentioned in the same meeting. Keep the boundary concrete so the recipient can identify what to resume and what to route elsewhere.
Gather the current work records
Collect the latest approved plan, working files, task list, decisions, and relevant messages. Give sources stable IDs and note their versions. Distinguish the latest draft from the latest approved version; they may differ materially.
The OpenAI projects reference describes organizing related chats and sources. That can support a handover packet, but confirm which files and instructions are available to the recipient. A link is useful only when the intended person can access the correct version.
Record work status from evidence. A file existing in a folder does not prove that it is reviewed or complete. A task marked done in an old list may have reopened after feedback. Preserve conflicting status records for clarification before drafting a confident summary.
Create a state table before writing prose
For each work item, record what is complete, what remains, the evidence, the next action, and any dependency. Keep the state concise and practical. “In progress” is rarely enough to tell a recipient where to begin.
| State field | Useful content |
|---|---|
| Work item ID | Stable reference to the task or deliverable |
| Current state | Specific completed and unfinished parts |
| Evidence | Working file, reviewed result, or decision reference |
| Next action | Concrete step supported by the current state |
| Dependency | Input, decision, or access needed first |
| Owner | Confirmed role or unresolved assignment |
| Timing | Documented deadline or explicitly unknown date |
Separate required next actions from optional improvements. A recipient should not have to guess whether polishing a layout matters more than resolving a factual gap. Use the approved plan to establish priority rather than inventing urgency.
Ask ChatGPT for a source-linked draft
Supply the work packet, recipient context, state schema, and desired length. Ask for a state table first and a note derived from that table. Require the output to preserve unresolved items and distinguish recommendations from commitments.
Draft a handover note for the stated work and receiving role.
First build a source-linked state table from the supplied records.
Separate completed, unfinished, blocked, and unresolved items.
For each item identify the next action, dependency, owner, and documented timing.
Do not invent completion, assignments, approvals, or deadlines.
Keep optional improvements separate from required continuation steps.
Return a concise note, source index, and questions requiring clarification.Review the state table before approving the prose. A readable narrative can conceal a mistaken status label. Correct the underlying row so later revisions remain consistent with the actual work.
Work through a fictional handover
Suppose a fictional training guide has a complete draft, two unresolved source checks, and a design review scheduled but not completed. The handover should say that drafting is complete while verification and review remain open. It should not simply describe the guide as finished.
The next action might be checking the two cited sources before requesting final review, if that sequence is established in the plan. If the records do not establish the order, present it as a proposed sequence for the owner to confirm.
Include the relevant draft version and source-check IDs. A statement such as “check the remaining references” is too vague when the packet contains several reference lists. The recipient needs the exact unresolved items and their expected evidence.
Put continuation information first
Open the note with the work's current state and the most important next step. Follow with completed work, open decisions, dependencies, key files, and contact roles. Put long background history in a linked appendix or supporting record.
Explain decisions that would otherwise be easy to reverse accidentally. If a section was intentionally deferred until an approved source arrives, say so and cite the decision. The recipient can then distinguish deliberate scope control from an overlooked task.
Keep the language factual and neutral. Avoid blaming a person for a dependency delay or claiming that a future review will be straightforward. Describe the unresolved condition and the role responsible for clarifying it.
Check usability from the recipient's perspective
Review whether the recipient can locate the current files, understand their status, and identify the first supported action. Descriptive links and version labels are more useful than a list of unexplained filenames. Confirm access through the approved process where needed.
Do not place passwords or raw credentials in the note. Refer to the normal access route and the responsible role. The handover should explain what access is required without becoming an insecure substitute for the organization's access process.
If the history itself is unclear, use the project timeline reconstruction guide to organize dated evidence separately. The handover's main purpose remains the current state and continuation steps.
Review acceptance and keep the note current
Ask the outgoing owner to verify statuses, evidence links, and open decisions. Give the recipient an opportunity to identify missing context or inaccessible files. Record whether ownership and scope have actually been accepted rather than assuming acceptance from delivery of the note.
If clarification changes the work state, revise the note and record its new cutoff. Preserve the earlier version when it explains what the recipient was initially told. A handover can become stale quickly if several people continue editing the work afterward.
Keep the approved note, source index, and unresolved-question list with the project records. Close open items through their normal decision process. A useful handover reduces reconstruction work while remaining honest about unfinished tasks and unconfirmed responsibilities.
Frequently asked questions
Should the note list every action already taken?
Include history that explains the current state or an important decision. Keep the main note focused on resuming the work.
Can ChatGPT mark a task complete from a filename?
No. Completion requires supporting evidence. A file's presence does not establish review, approval, or final status.
What if the receiving owner is not confirmed?
Mark assignment pending and identify the clarification needed. Do not treat the draft note as an ownership agreement.
How should blocked work be described?
State the specific dependency, evidence, responsible role if known, and the next action once the condition is resolved.
When should the handover be updated?
Update it when material status, scope, ownership, or source information changes, and record the new cutoff and version.
