What do I need to prepare before running this?

Who's leaving and whether the exit is voluntary or not, the systems and access this role holds (flagging what's security-critical), a sense of what only this person knows that the team will need, a rough offboarding-notes.md brain-dump from the departing person, any legally-required exit steps for your region, and a Claude Desktop workspace your company has approved for people data. Claude structures the raw input — it doesn't need to be tidy.

Is it safe to put exit-interview notes into Claude?

Only inside a workspace your company has approved for people data. Exit notes are sensitive — they often name managers, colleagues, and the real reasons someone left — so they never go into a general chat or an unapproved tool. The synthesis step also aggregates and anonymizes deliberately, so what comes out is safe to act on without pinning a single exit on a named person.

Does this actually remove access, or just list it?

It builds the list and sequences it — most security-critical access first — but it does not touch any account. A human, usually IT, does the actual removal and then confirms each account is really closed. The playbook is explicit that the list is not the deed: closing access is a person's job, and someone verifies it happened.

How is this different from the onboarding playbook?

It's the bookend — the exact mirror of Build a reusable onboarding-in-a-box. Onboarding builds someone up over their first 30 days: accounts opened, people met, an early goal to own. Offboarding winds them down cleanly: access closed, knowledge captured before it leaves, a dignified exit, and a fairly synthesized exit interview. Same build-the-box-once discipline and the same template-with-placeholders move, run in reverse.

Run a respectful exit and keep what you learn

when to reach for this

Offboarding is the mirror of onboarding and almost always an afterthought. Access stays open for months after someone's gone, the knowledge in their head walks out the door on their last day, and a rushed exit chat teaches you nothing you can act on. The fix is the same as onboarding: build the box once — a dignified exit checklist, a least-access removal list, a real knowledge-transfer capture before the last day, and a fairly synthesized exit interview that feeds genuine retention insight — then reuse it identically for every leaver. How you offboard is as much your employer brand as how you hire, and the security and knowledge cost of doing it badly is high.

gather this first

Who's leaving and the role/team — and whether the exit is voluntary or not, because that changes how careful you have to be (involuntary or disputed exits route past HR/legal/counsel).
The systems and access this role holds and what's security-critical — the accounts that, left open, are the real risk.
What only this person knows that the team will need after they're gone — the in-flight work, the tribal knowledge, the "who do I ask about X" answers.
A Claude Desktop workspace your company has approved for people data — open the relevant folder there and approve each read in the 'Ask permissions' prompt; every leaver's detail stays inside it.
Any legally-required exit steps for your region (final-pay rules, notice, equipment return, anything that has to be documented).

the workflow

Define a clean, dignified exit before the checklist

Start from what 'offboarded well' means, not the task pile. Name it first — knowledge captured, access closed cleanly, the person treated with respect on the way out — so every checklist item earns its place by serving that destination instead of just being a box to tick.

you ask

I'm building a reusable offboarding system for a [role] on the [team]. Before any checklist, propose what 'offboarded well' should mean for this role — covering three things: the knowledge that has to be captured before the last day, the access that has to be closed, and how the person is treated on the way out. Don't build the checklist yet — just the definition of a good exit that every later step will serve.

what you get back A short, concrete definition of a good exit — "handover docs for the two systems they own, all access closed within 24 hours of the last day, a respectful final-week plan" — that becomes the spine every checklist item now has to point at.

This is the bookend to Build a reusable onboarding-in-a-box: same goal-first move, mirror-imaged. Anchoring on a dignified exit is what turns a generic offboarding list into a real one.
Build the checklist, grouped by owner and timeline

Now lay it out day by day and owner by owner — manager, IT, HR — sequenced so security-critical access is closed first and nothing blocks anything. Grouping by owner and day is what makes it usable: everyone sees exactly what's theirs and when.

you ask

Now build an offboarding checklist for this role, grouped by timeline (notice period → last week → last day → after) and marked by owner (manager, IT, HR, the departing person). Include a least-access removal list — every system and account this role holds — sequenced so the most security-critical access (admin, production, customer data, finance) is closed FIRST, not last. Put an owner on every single line, and keep the structure reusable as a template for any leaver in this role.

what you get back A timeline-and-owner checklist — "Last day: revoke SSO + admin consoles (IT), collect laptop (IT), exit conversation (HR)" — with a least-access removal list ordered most-critical-first and an owner on every line, ready to reuse.

Sequencing security-critical access first is deliberate: if an offboarding stalls halfway, you want the dangerous access already gone, not the harmless mailing-list membership.
Capture the knowledge before the last day

This is the highest-value, most-skipped step — and where Claude earns its keep. Turn what's in the departing person's head into real handover docs: who owns what, where things live, the in-flight work, the tribal knowledge nobody wrote down. Do it before the last day, while they're still here to answer.

you ask

Read offboarding-notes.md — this is a rough brain-dump from the departing [role] about their work. Structure it into a clean handover doc for the team taking over: who/what owns each responsibility, where each system and document actually lives, the in-flight work with its current status and next step, the recurring tasks and their cadence, and the 'tribal knowledge' — the things they just know that aren't written anywhere. Flag any gap where the dump is thin so I can ask them before their last day.

what you get back A structured handover doc — responsibilities, locations, in-flight work with next steps, recurring duties, and tribal knowledge — plus a short list of gaps to fill while the person's still there to answer them.
Synthesize the exit interview fairly

Pull the themes from the exit conversation, but separate a real signal from one bad week, run a bias pass, and aggregate so it's safe to act on. The discipline here is the same as Turn five interviewers into one fair verdict: one person's bad exit is not a trend, and a single anonymized data point never gets pinned on a named manager.

you ask

Read exit-interview.md. Summarize the themes worth paying attention to, but be disciplined: separate a genuine, recurring signal from a single bad week or one person's frustration, and say which is which. Run a bias pass — flag anything that's a personality judgment or unverifiable claim rather than something actionable. Then frame the output so it's safe to act on: aggregate and anonymize where possible, and do NOT attribute a single negative exit to a named manager or colleague off one data point. Tell me what would need corroborating before it's a real trend.

what you get back A fair read of the exit — the themes that look like real signal, what's likely one-off, bias flags called out, and aggregated/anonymized framing — with anything thin marked 'needs corroboration before acting,' never a named blame off a single exit.

One exit is a data point, not a trend. The synthesis surfaces what to watch; you and HR decide what's actually a pattern worth acting on — see Turn an engagement survey into an action plan for stitching exits into the bigger retention picture.
Templatize it for the next exit

This is what makes it a system instead of a one-off. Strip the person-specific details to clear placeholders, add a 'manager prep' list, and keep the structure identical — so every exit is consistent and fair, not dependent on who happened to run it.

you ask

Turn this whole offboarding flow into a reusable template for any [role] who leaves: replace person-specific details with clear [placeholders] (name, last day, manager, systems owned), and add a short 'manager prep' checklist of what to set up the moment a departure is confirmed. Keep the checklist, the least-access removal list, the handover structure, and the exit-interview synthesis identical in shape — so the next exit is a fill-in, not a rebuild, and every leaver gets the same dignified, consistent process.

what you get back A clean, reusable offboarding-in-a-box with obvious [placeholders], a manager-prep checklist for the moment a departure lands, and an identical structure every time — drop in the next leaver's details and the process runs the same as the last one.

Save this template. Reusing one structure for every exit is what makes offboarding feel consistent and fair instead of dependent on who ran it — the exact mirror of the onboarding template.

make it your own

Involuntary or sensitive exits: when the departure is a termination, a dispute, or anything emotionally charged, pair this tightly with Draft a sensitive message you can stand behind for the comms, and route everything — message, timing, and access decisions — past HR, legal, or counsel before anything sends. Claude drafts; HR and the manager own the call.
Aggregate the themes over a quarter: run the synthesis step across many leavers' exit interviews over a quarter to find the patterns a single exit can't show — then feed those aggregated themes into Turn an engagement survey into an action plan so exits become one more retention signal alongside the survey, not an isolated anecdote.
Arabic or bilingual exits: for an Arabic-speaking leaver, run the exit conversation and handover docs in Arabic — and adapt rather than machine-translate, so the exit interview and farewell read naturally and respectfully in the language the person actually works in, not as a stiff translation of an English template.
Nudge the prep automatically (Power Track): once the template is stable, a scheduled agent (see the Playbook's Features tab) can nudge IT on the access-removal list and remind the manager to start the handover capture before the last day — so nothing slips. Scheduled agents are the opt-in Power Track — on Desktop the template runs fine as a checklist you work through by hand for each exit.

watch out for

Leaving access open is the classic offboarding failure — close it promptly and remove least-access-first, so the security-critical accounts are gone even if the rest of the checklist drags. A human, usually IT, confirms every account is actually closed; the list is not the same as the deed.
People data stays in a workspace your company has approved for people data — exit notes, names, and the reasons someone left never go into a tool that hasn't been cleared. Confidentiality is the whole job, not a footnote.
One bad exit is not a trend. Aggregate before you act, and never attribute a single anonymized exit to a named manager or colleague off one data point — the synthesis surfaces what to watch, it doesn't render a verdict on a person.
Involuntary or disputed exits go past HR, legal, or counsel before anything sends. Claude drafts the message and lists the access to remove, but HR and the manager own the call, the timing, and every access decision — especially when the departure is contested.

you'll end up with A reusable offboarding-in-a-box: a dignified exit, access closed cleanly with the most security-critical removed first, the departing person's knowledge captured before it walks out the door, and exit insight you can actually act on — built once and dropped in for every departure instead of improvised under pressure each time.

Questions people ask

What do I need to prepare before running this?: Who's leaving and whether the exit is voluntary or not, the systems and access this role holds (flagging what's security-critical), a sense of what only this person knows that the team will need, a rough `offboarding-notes.md` brain-dump from the departing person, any legally-required exit steps for your region, and a Claude Desktop workspace your company has approved for people data. Claude structures the raw input — it doesn't need to be tidy.
Is it safe to put exit-interview notes into Claude?: Only inside a workspace your company has approved for people data. Exit notes are sensitive — they often name managers, colleagues, and the real reasons someone left — so they never go into a general chat or an unapproved tool. The synthesis step also aggregates and anonymizes deliberately, so what comes out is safe to act on without pinning a single exit on a named person.
Does this actually remove access, or just list it?: It builds the list and sequences it — most security-critical access first — but it does not touch any account. A human, usually IT, does the actual removal and then confirms each account is really closed. The playbook is explicit that the list is not the deed: closing access is a person's job, and someone verifies it happened.
How is this different from the onboarding playbook?: It's the bookend — the exact mirror of *Build a reusable onboarding-in-a-box*. Onboarding builds someone up over their first 30 days: accounts opened, people met, an early goal to own. Offboarding winds them down cleanly: access closed, knowledge captured before it leaves, a dignified exit, and a fairly synthesized exit interview. Same build-the-box-once discipline and the same template-with-placeholders move, run in reverse.