The resignation lands and the instinct is to book a series of long handover meetings and hope something sticks. Two weeks later the person is gone, you have four hours of recordings nobody has watched, and the first time anyone notices a gap is when something breaks at the worst possible moment.
The problem is not effort. It is ordering. You cannot capture everything one person knows in two weeks, so the only useful question is which knowledge costs the most if it leaves unwritten.
Triage by cost of loss, not by seniority of task
Rank what this person does by what happens if nobody knows how to do it. That ordering is rarely the same as what they consider the important part of their job. The expensive knowledge is usually mundane and invisible.
- Anything with an external deadline. Payroll runs, tax filings, regulatory submissions, client reporting cycles, renewal dates. These have a date attached and a real penalty for missing it, and they are often known by exactly one person.
- Anything where they are the only account holder or approver. Vendor portals, a bank approval step, a domain registrar, a certificate that expires. Not the process so much as the access and the fact that it exists at all.
- Recovery procedures for things that rarely break. If a nightly job fails, if a client's data needs restoring, if the payment provider rejects a batch. Rare plus undocumented is the worst combination, because nobody discovers the gap until they are already in the incident.
- Judgment calls they make routinely. When to escalate a customer complaint, which discounts are acceptable without approval, when an invoice is worth chasing. This is the hardest to capture and often the most valuable.
- The frequent, everyday tasks. Counterintuitively these come last. They happen often enough that a colleague has probably watched one, and the next person will hit them in week one while the leaver is still reachable by message.
Do not run a handover meeting. Run a screen share.
Asking someone to describe a process from memory produces a summary. Asking them to do it while narrating produces the detail: the button that is mislabelled, the report that has to run before the other one, the client whose invoice always needs manual adjustment.
Practically: have them perform the task while talking through it. Do not interrupt with clarifying questions during the run; note them and ask at the end, because interruptions make people summarise instead of demonstrate.
For a task they cannot perform on demand, because it only runs at month end, ask them to walk you through the last one that happened. Real artefacts from a real instance beat a hypothetical description every time.
The four questions that actually pull knowledge out
Most handover questions produce the official version of the process. These four produce the real one.
- "What goes wrong with this most often?" Surfaces the failure modes that are the entire reason the process has its odd shape.
- "What would a new person get wrong here?" People are far better at predicting other people's mistakes than at listing their own tacit knowledge.
- "Who do you contact when this breaks, and do they know that?" Frequently uncovers an informal arrangement that exists nowhere in writing.
- "What do you do that is not in your job description?" This is where the orphaned processes live: the thing they picked up two years ago because nobody else would.
Write it down as procedures, not notes
A recording is not documentation. Neither is a document that says "log into the portal and do the monthly reconciliation" for someone who has never seen the portal. The test is whether a competent colleague who has never done this task could follow it without asking a question.
That means each procedure needs: the event that starts it, who does it, the numbered steps in order, and what to do at each point where the answer changes the path. If a step says "check whether the client is on the enterprise plan", the document has to say what happens in both cases or it stops being followable exactly where it matters.
Have the leaver review it, not write it
Do not hand a departing person a blank template in their final fortnight. Compliance will be low and the output will be thin, and understandably so: they are wrapping up, saying goodbyes, and starting somewhere else.
Invert it. Someone else produces the draft from the recording or the walkthrough, and the leaver reviews and corrects it. Correcting a draft is much faster than authoring from scratch, and a wrong draft prompts a specific correction in a way a blank page never does.
Verify before the last day, not after
The single highest-value thing you can do: have someone else perform each critical procedure from the written version, while the leaver is still there. Not read it. Perform it.
This is the only real test, and it always finds something: a permission the new person does not have, a step that assumed context, a link that goes to the wrong place. Finding that on day minus three costs a five-minute conversation. Finding it on day plus thirty costs an incident.
Where Sendabrief fits
This whole process works with a screen recorder and a text editor, and if that is what you have, do it that way. The reason we built Sendabrief is that the write-up step is where handovers stall: the recordings exist and nobody turns them into documents.
So the two inputs that matter here are the ones that skip the writing. Click through the process once with the browser extension and every click becomes a numbered step with an annotated screenshot and your narration attached. Or take the handover call you already recorded, paste the transcript or upload the file, and get a structured procedure out of it. Either way the leaver reviews a draft instead of facing a blank page, which is the version that actually gets finished.