The handover document
Asking a leaver to document everything they do fails every time. A handover has a smaller and more achievable job than a procedure library: making sure nothing is lost.
What to capture when somebody leaves, in the order that fits a notice period, so that nothing is lost in the following months.
A handover is not a documentation project
When somebody resigns, the instinct is to ask them to document everything they do. It fails every time, for a reason that has nothing to do with goodwill: there is not enough time, and the person now has one foot out of the door.
A handover has a different job from a procedure library. A procedure exists so that the task can be done correctly by anyone, indefinitely. A handover exists so that nothing is lost in the next few months — which is a much smaller and much more achievable target.
Aim at the second one. The first can be built afterwards, from a position of not being in a crisis.
Start with the list, not the documents
The first artifact is a single page listing everything the person is responsible for, with one line each and a name against it. Not how any of it is done — just what exists and who now owns it.
This takes an hour and it is the single most valuable output of the whole handover. Most of what goes wrong after somebody leaves is not that a task was done badly. It is that nobody knew the task existed until it was overdue.
The list is also what tells you where to spend the remaining time. You cannot write twenty procedures in a notice period. You can look at twenty lines and identify the four that would actually hurt.
The five things that are genuinely lost otherwise
Recurring obligations with a deadline. The monthly return, the annual renewal, the quarterly report. These are the highest-risk items on any list because the failure is invisible until the date passes.
Relationships and who to contact. Not the company name — the person, what they handle, and anything about how the relationship works that is not written down anywhere.
Where things are. Which shared drive, which account, which spreadsheet is the real one. This is trivially cheap to capture and disproportionately expensive to reconstruct.
Decisions and their reasons. Why it is done this way, what was tried before, what the exception is for. This is the category that never gets written down and is the most costly to lose, because the successor cannot know to ask.
The work only they do. Anything where they are the only person who can. If time runs out, this is the one to spend it on.
Access is a separate list and it has a deadline
Accounts, systems, shared logins, physical keys, anything with their name on it as the sole administrator, anything paid on a card that is theirs. This list is not a documentation task and it should not wait behind one.
Two directions matter and only one is usually done. Removing their access is remembered. Making sure somebody else has access before theirs is removed is what gets forgotten, and it produces the locked-out situation that turns a manageable departure into a bad month.
Work through it while they are still there and can log in. This site takes no position on how any of it should be administered — that depends on your systems and on obligations this site knows nothing about.
Have the successor do the writing
Where there is a successor and any overlap at all, the leaver should perform the task and the successor should write it down. It is the fastest known way to get an accurate procedure and it inverts the usual failure.
The reason is that a person who has done something for three years cannot see the steps they no longer think about. Somebody watching for the first time notices every one of them, and asks the question the document actually needs to answer. Getting a process out of the person who holds it is the general form of this.
It also produces something you cannot get any other way: the successor has already done the task once, with the leaver in the room. That is worth more than the document.
A realistic notice period
Week one: the responsibility list and the access list. Both complete, both on one page each, both with names against every line.
Week two: the successor shadows and writes, starting with the recurring obligation that falls soonest.
Week three: the successor does the work with the leaver watching, and fixes what the document missed. This is the step that tells you whether any of it worked.
Last week: contacts, context, the reasons behind decisions, and anything on the list still uncovered — captured as notes rather than as documents, because a rough note that exists beats a proper procedure that does not.
Then, after they have gone, turn the four most important notes into real procedures. The SOP template is free and blank, and that work is much easier to do calmly than it was during a notice period.
Nothing here is employment or HR advice, and this site does not know what your obligations are when somebody leaves. Everything above is about not losing operational knowledge; anything with legal effect belongs with someone qualified in your jurisdiction.
Editor's notes
Written by Free Biz Docs about the document above — not reader submissions.
The list beats the documents and the post says so early
One page naming what exists and who owns it now is an hour's work and is worth more than any procedure written in a notice period. It is first because time runs out, and because the common failure after a departure is a task nobody knew about rather than a task done badly.
Nothing here is employment advice and the boundary is narrow
Notice periods, what may be asked of someone working one, and how access is administered are governed by law and by agreements this site knows nothing about. Everything in the post is about not losing operational knowledge. Where a step has legal effect it belongs with someone qualified in the relevant jurisdiction, which is the standing line on every page here.
The access list is separated from the documentation on purpose
It is not a documentation task, it has a hard deadline, and it fails in a direction people do not check: removing the leaver's access is remembered, and confirming that somebody else already has it is not. Putting it behind the procedure writing is how organisations end up locked out of something the week after a departure.
These documents are starting structures for you to build on, not professional or legal advice. Anything that will have legal or contractual effect, or that varies by jurisdiction, should be reviewed by someone qualified in the relevant place.
Common questions
- What should a handover document include?
- Start with one page listing everything the person is responsible for, one line each, with a name against every line. Most of what goes wrong after somebody leaves is not that a task was done badly — it is that nobody knew the task existed until it was overdue.
- Should we ask a leaver to document everything they do?
- It fails every time, and not for lack of goodwill: there is not enough time and they have one foot out of the door. A handover has a smaller job than a procedure library — making sure nothing is lost over the next few months — and that target is achievable.
- What gets lost when someone leaves?
- Five things: recurring obligations with a deadline, who to contact and how that relationship works, where things actually are, the reasons behind decisions, and any work only that person can do. The reasons are the most expensive to lose, because a successor cannot know to ask.
- Who should write the handover procedures?
- The successor, while the leaver performs the task. Somebody who has done a job for three years cannot see the steps they no longer think about; somebody watching for the first time notices every one. It also means the successor has done the task once with the leaver in the room.
- What about accounts and access?
- A separate list with its own deadline, worked through while they can still log in. Removing their access is usually remembered; making sure somebody else has access before theirs is removed is what gets forgotten, and it turns a manageable departure into a bad month.