Write a handover note for work AI helped with
"AI did this" is not much of a handover. Your colleague needs to know which file it came from, what was fixed and what nobody has checked yet.
What you'll make
a short handover note for one piece of AI-assisted work: what went in, what came out, what was fixed, what you checked and what is still to do.
What you'll need
your work AI account (ChatGPT, Claude, Copilot or Gemini), the names and versions of the files you used and produced, and a few rough notes on what you did. About 10 minutes.
Example result.
In: release-notes-oct-v4.pdf · Out: plans-faq-v3.docx (12 answers)
Fixed: v2 said shared inboxes were on all plans — the release notes say Business only
Checked: all 12 answers against release-notes-oct-v4.pdf, page by page
Not done: support lead sign-off, publishing to the help centre
Next: Priya to get sign-off, then publish1. Start with three lines
Most handovers need only three things: what went in, what came out and what you checked. Write those in your own words first, however rough. Then ask the AI to tidy them without adding anything.
Turn my notes into a short handover note for a colleague.
Use these lines: In, Out, Fixed, Checked, Not done, Next.
Use only what my notes say. If a line has nothing in my notes, write "unknown".
Don't describe the work as approved, final or ready unless my notes say so.
My notes: [notes][notes] is your rough account: file names and versions, what changed, what you checked and what’s left.
Why this works: the fixed lines stop important gaps from disappearing, and “unknown” makes a missing step visible instead of quietly filled in.
What you should see: five or six short lines, each traceable to something in your notes.
2. Give “checked” an object
“Checked” on its own tells your colleague nothing. Did you compare every answer with the source, read two of them, or open the file to see that it wasn’t blank? Each line under Checked should name the file or version, what you compared it with and the result, including anything that failed and was fixed. If you didn’t time the work or compare it with another method, leave time savings out; one good handover doesn’t need a statistic.
Why this works: your colleague decides how much more checking to do from this line. “Checked against the release notes, page by page” and “skimmed it” lead to very different decisions.
What you should see: every check names its file and what you compared it with.
3. Read it as the person receiving it
Before you send the note, ask the AI to read it from your colleague’s side and point out what they’d still have to ask you.
Read this handover note as the colleague taking over the work.
Name the source, the current output, the main fix, the checks done and the next decision.
List any question you'd need to ask before carrying on.
Point out any status word, such as "approved" or "done", that the note doesn't back up.
Note: [handover note][handover note] is the note from step 1.
Why this works: the questions it lists are the ones your colleague would otherwise send you on your day off.
What you should see: a short summary and a list of open questions. Answer each one in the note, or move it to Not done.
Check the result
- Every file named in the note has a version, and it’s the version you’re handing over.
- The Fixed line says what was wrong, not just “fixed errors”.
- Every Checked line names what you compared the work with.
- Nothing is called approved, final or published unless that has actually happened.
The usual failure: the AI turns your checks into a promise. “I checked the 12 answers against the release notes” becomes “FAQ reviewed and ready to publish”, and the fix from v2 disappears. Spot it by looking for status words your notes never used.
The note says "[status words]", but my notes only say "[what I did]".
Replace the status with what actually happened, put the remaining steps under Not done,
and restore the fix I described.[status words] is the phrase the AI added; [what I did] is the matching line from your notes.
Worked example: a plans FAQ that’s checked but not published
Fictional example. Sam used AI to update the plans FAQ from October’s release notes and is handing it to Priya before going on leave.
Sam's notes: used release notes oct v4, made faq v3 (12 answers)
v2 said shared inboxes on all plans - wrong, Business only, fixed in v3
went through all 12 against the release notes
support lead hasn't seen it, not on help centreFirst note (wrong): “In: release notes. Out: plans FAQ, reviewed and ready to publish.”
Repair: the repair prompt above, with “reviewed and ready to publish” as the status words and “went through all 12 against the release notes” as what Sam did.
Repaired note: the five lines in the example result at the top of this page.
- “Ready to publish” skipped a step: the support lead hasn’t seen it. That one phrase could have put a draft on the help centre.
- The Fixed line tells Priya where the risk was. If a customer asks about shared inboxes, she knows the answer was checked.
- Version numbers matter: Priya can tell v3 apart from the wrong v2 in the shared folder.
Task kit for this job: Download (ZIP) · Reusable instructions
Go deeper
Use the longer record for higher-stakes work
For work that feeds a decision, a customer or a regulator, add the instruction or prompt you used (and its version), the tool name as it appeared in your account, every revision with its reason, and who must approve it next. Keep failed versions when they explain a fix. Store the record where the work lives, in your organisation’s usual storage, not pasted into a public channel.
Put the evidence beside the status
Next to “Signed off” or “Published”, add the thing that proves it: a link to the approval email or the live page. A date on its own doesn’t show that something happened.
Version instructions you reuse
If you run the same AI task every month, give the prompt a version number and note it in the In line. The stable rules guide separates the method you keep from the facts that change each run.