Most knowledge handovers fail the same way.
The departing person gets a calendar invite in their last week called “handover meeting.” They fill a Google Doc with bullet points, run a 90-minute screen share, and leave.
Two weeks later, the successor hits a ticket nobody recognizes. They search the wiki, find nothing useful, and post in Slack: “Anyone know how this works?”
By month two, half the knowledge has disappeared.
The fix is not a better meeting. It is a documentation handover that starts before the final week, captures real workflows instead of vague notes, and checks for gaps after the person leaves.
This playbook covers what to capture, when to start, how to run the handover, and how to verify the knowledge actually survived.
Key takeaways
- Institutional knowledge is the unwritten layer: tribal know-how, decision history, relationship maps, shortcuts, exceptions, and context that never made it into the SOP.
- A real handover needs 4 to 6 weeks, not one last-week meeting.
- Capture beats interview. Recording the actual workflow produces better documentation than asking someone to describe it from memory.
- Six artifact types cover most knowledge risk: workflow recordings, decision logs, contact maps, escalation paths, in-flight commitments, and credential/ownership maps.
- The handover is not finished on the last day. Run 30- and 60-day checks with the successor to find gaps before they become incidents.
What is institutional knowledge?
Institutional knowledge is the operating know-how a team depends on that is not written down anywhere.
It includes:
- Steps people skip because “everyone knows that”
- Reasons a vendor or tool was chosen years ago
- The person who really approves a request
- Workarounds for systems that break regularly
- Exceptions that never made it into the SOP
- Some teams call this tribal knowledge. The name matters less than the risk.
- If it lives in one person’s head, it can disappear when they leave.
A regular SOP library captures repeatable workflows. Institutional knowledge is the context around those workflows: the exceptions, relationships, decisions, and shortcuts that make the work actually function.
A documentation handover turns that context into something a successor can use.
Why regular offboarding does not capture institutional knowledge
Standard offboarding is a checklist: revoke access, return hardware, exit interview, final paycheck, last-day lunch. None of those steps produce documentation. The exit interview is HR-driven and rarely covers operational knowledge. The "handover meeting" most teams schedule is one hour, ad-hoc, and uses prose notes that the successor cannot search later.
The deeper issue is timing. By the time HR triggers offboarding (usually 2 weeks before the last day), the leaver is already mentally checked out. They are clearing personal files, scheduling exit lunches, and finishing whatever real work is in flight.
Asking them to also write a 30-page knowledge dump in the last fortnight is the lowest-quality moment of their entire tenure. The fix is to start the documentation handover 4 to 6 weeks earlier, before the leaver is mentally gone.
For deeper coverage of the broader discipline, see our work on process documentation best practices. The capture-first authoring shift behind stage 2 is covered in how teams document workflows without writing a single word.
The 5-stage documentation handover playbook
These five stages are the structure we run when scoping a real knowledge handover. They are listed in time order and assume a 4 to 6 week window before the last day.
Stage 1: Scope the knowledge at risk (week 1)
The first task is figuring out what the leaver actually knows that nobody else does. Run a 60-minute scoping session with the leaver, the manager, and the future successor (if known).
Ask three questions:
- What do you do every week that nobody else on the team does?
- What do you handle once a quarter that always goes through you?
- What would break if you were hit by a bus tomorrow?
The output is a scoping document with three lists: weekly recurring work, occasional flows that route through this person, and known single points of failure. This document drives every later stage. If the scoping session produces fewer than 8 items, the question wording was wrong. Run it again with the manager separately.
Stage 2: Capture the rare flows on screen (week 2)
Once the scoping list exists, do not interview your way through it. Capture instead. The leaver records their screen the next time each flow runs in real life. They narrate the exceptions while it is happening and save the recording with a one-line title.
Capture-first authoring solves the two failure modes of interview-based handovers. First, it preserves the actual click-by-click behavior, including the small UI quirks the leaver does not even notice anymore. Second, it captures real data shapes (real ticket numbers, real client names, real edge cases) instead of the sanitized versions someone produces in a meeting. A 12-minute capture of a real flow beats a 90-minute meeting recap by an order of magnitude.
Stage 3: Document decisions, relationships, and exceptions (weeks 3 to 4)
Captures handle the "how." They do not handle the "why" or the "who." For those, the leaver writes three short artifacts.
A decision log lists every operationally significant decision the team made in the last 18 months, one line each, with a who-decided and a why. A contact map lists every external party (vendor, client, regulator, sister team) and the actual human who has to be in the loop. An exception log records the workarounds and edge cases that come up monthly or less and never make it into the formal SOPs.
Each artifact is short. The decision log is usually 30 to 60 lines. The contact map is 20 to 40 entries. The exception log is 10 to 30 entries.
The point is not completeness. The point is to capture the entries the next person could not reconstruct from the regular wiki on day one.
Stage 4: Run a handover ceremony with the successor (week 4 to 5)
The handover ceremony is a 4-hour structured session with the leaver, the successor, and the manager. The successor walks through the captured flows, the decision log, the contact map, and the exception log. They ask questions in real time.
The leaver answers. The manager takes notes on what was unclear.
The output of the ceremony is not "the successor now knows everything." It is a punch list of gaps. Anything the successor could not reconstruct from existing artifacts becomes a new artifact, or an addendum, before the leaver's last day.
Stage 5: Run a decay check at week 6 (after departure)
The hardest part of a knowledge handover is the part most teams skip: confirming the docs survived the leaver's exit. Two weeks after the last day, the manager sits with the successor for one hour and asks one question. What have you needed in the last two weeks that you could not find?
The answer is always 3 to 8 things. Each missing thing becomes a ticket. The successor writes the doc themselves, based on what they figured out.
This is the moment institutional knowledge actually transfers from one head to a durable artifact. The successor is now the person who needed to know. Schedule a second decay check at week 6 for the seasonal flows that did not come up in the first two weeks.
Stage takeaways
Stages 1 and 2 decide whether the knowledge gets out of the person’s head.
Stages 3 and 4 decide whether the artifacts are usable by someone else.
Stage 5 decides whether the handover survives after the last day.
Skip the decay check, and the handover may look complete before it actually gets tested.
What to capture: 6 artifacts that cover most institutional knowledge
These are the artifact types we have seen pay back in every real handover. They are listed in priority order. If the timeline is shorter than 4 weeks, capture the first three and skip the rest.
1. Workflow recordings (the recurring how-to layer)
Screen recordings of the leaver running real workflows on their actual systems, narrated as the work happens. Five to twenty captures usually cover the recurring weekly work. The recording format matters.
A click-by-click capture with auto-generated steps is more useful than a 30-minute video. The successor can scan the steps in 30 seconds rather than scrubbing through video. For the wider authoring shift here, see how teams document workflows without writing a single word.
2. Decision log (the "why we picked this" layer)
A flat list of operationally significant decisions made in the last 12 to 18 months, one line each. Format: date, decision, decided by, one-sentence rationale. This is the artifact that prevents the new person from spending three months relitigating decisions the team already settled.
3. Contact map (the "who actually approves what" layer)
Every external party the role talks to, with the human name and the kind of decisions that route through them. Org charts are wrong about who actually approves what. Contact maps are right because the leaver has been doing the actual approvals.
4. Escalation path (the "what to do at 2 a.m." layer)
For roles that carry on-call or incident-response responsibility, a written escalation path. Which vendor support to call first. Which internal contact handles which kind of incident. Who has the credit card for emergency vendor purchases.
5. In-flight commitments (the "open promises" layer)
A list of every external promise the leaver has made that has not been fulfilled yet. Discounts promised to clients. Deadlines committed to partners. Action items from meetings that nobody else attended.
This is the highest-risk artifact. Broken commitments are the most visible failure mode of a botched handover.
6. Credential and ownership map (the "who owns what" layer)
Every system the leaver owns or administers, paired with four data points:
- Credential location (vault entry name, not the credential itself).
- Backup owner.
- Reassignment date.
- Whether the system has audit-log access.
- For sensitive systems, this overlaps with IT documentation. The broader category is covered in our IT documentation software guide.
The 4 to 6 week timeline (when to do what)
A 6-week window covers the seasonal edge cases that 4-week windows miss. If the leaver gives 2 weeks notice, compress: run stages 1 to 3 in week 1, stage 4 in week 2. Accept that stage 5 will surface more gaps than a longer window would have.
How to run the handover ceremony
The handover ceremony is the most valuable 4 hours of the entire window. It is not a presentation. It is a structured walkthrough.
The successor asks every question they have, in front of the leaver. The manager listens for what is unclear.
Here is the agenda we use:
- Hour 1: walk through the scoping document and confirm priorities.
- Hour 2: review captured workflows. The successor opens each one, narrates back what they understand, and the leaver corrects misunderstandings in real time.
- Hour 3: review the decision log, contact map, and exception log. Same pattern: successor narrates back, leaver corrects.
- Hour 4: handle in-flight commitments. Walk through every open promise, agree on owner, write it down.
The manager's job is to listen for the moments where the successor's narration does not match the leaver's understanding. Those are the gaps. Write them down. They become the punch list for the leaver's last week.
Common mistakes that break handovers
The same mistakes show up across handovers that fail.
Starting in the last week
The single most common failure. By the last week, the leaver is mentally already at the next role and the work in flight does not stop. The handover gets the leftover hours. Start 4 to 6 weeks earlier.
Interviewing instead of capturing
A 90-minute meeting produces 5 pages of low-quality notes. A 12-minute screen capture of the actual workflow produces a step-by-step the successor can rerun. Capture first, interview second.
Skipping the decision log
Teams that skip the decision log spend the next 6 months relitigating decisions the leaver already made and forgot to mention. The decision log is a 30-line artifact that pays back in dozens of avoided meetings.
No identified successor
If there is no successor by week 1 of the window, the manager is the de facto successor and has to attend every session. Pretending the successor will be hired in time and skipping the ceremony almost always means re-running the entire handover from scratch in 6 weeks.
No decay check
The decay check is what turns institutional knowledge into durable artifacts. Skip it and the docs the leaver wrote feel complete in week 4. They turn out to be 60% complete in week 8, with no one left to fill the gaps.
Mistake-avoidance takeaways
Last-week handovers are the lowest-quality moment of the entire tenure. Start six weeks earlier.
Captures beat interviews. Record the real screen during real work.
Decision logs and decay checks are the two artifacts most teams skip and pay for later.
The handover is not done until the second decay check at week 6 after departure.
How to keep institutional knowledge from rebuilding under the radar
A handover playbook fixes the immediate problem. It does not stop the next pile of institutional knowledge from forming around the new person. The durable fix is to treat documentation as a recurring practice, not a once-per-departure scramble.
Three habits keep the residue from rebuilding. The team captures recurring workflows when they run, not when someone is leaving. Decisions land in the decision log the week they are made. Contact maps update the day a vendor changes.
None of those habits are heavy. They each cost 10 to 20 minutes a week per person. The compound effect is that the next handover starts from a 70% complete library instead of zero.
For deeper coverage of how the authoring shift makes this practical, see our work on AI process documentation and the 7-step framework for creating SOPs.
FAQ
What is a documentation handover?
A documentation handover is the structured process of transferring knowledge from a departing person to their successor before the last day. It produces durable artifacts like workflow recordings, decision logs, contact maps, escalation paths, in-flight commitments, and ownership maps.
How long should a knowledge transfer take?
A strong knowledge transfer starts 4 to 6 weeks before the last day, with follow-up checks after departure. If you only have two weeks, compress the process but keep capture and the decay checks.
What should a knowledge transfer document include?
It should include workflow recordings, decision logs, contact maps, escalation paths, in-flight commitments, and credential or ownership maps.
How do you capture tribal knowledge?
Capture the real work as it happens. Screen recordings with narration usually reveal more than interviews because the person doing the work often forgets to mention steps that feel obvious to them.
What is institutional knowledge?
Institutional knowledge is the unwritten operating knowledge a team depends on: undocumented steps, decision history, relationship maps, workarounds, and exceptions.
What is a knowledge transfer plan?
A knowledge transfer plan is a dated schedule for moving knowledge into durable documentation. It should include scoping, capture, documentation, handover review, and post-departure checks.
How do you preserve company knowledge over time?
Preserve knowledge by documenting continuously, not only when someone leaves. Capture workflows as they happen, keep decision logs current, and update ownership maps regularly.
For deeper coverage of how to author SOPs that hold up over time, see our 7-step framework for creating SOPs. Reusable structures are in 12 SOP patterns that survive UI changes.
