Knowledge Transfer Process When a Key Employee Leaves

Why handovers fail

Handovers fail because the knowledge transfer process starts too late and relies on memory, so the person leaving describes the job as they think of it, not as it really runs.

When a key employee resigns, the notice period fills up quickly. There is their own work to finish, goodbyes, perhaps holiday still to take. The handover becomes a meeting in the final week and a document written on the last afternoon. It lists the big responsibilities and misses the small, regular ones that nobody thinks of as tasks: the supplier who must be reminded every month, the report a customer expects every quarter, the password only that person knows how to reset.

Those small things surface weeks later, usually as a problem. A customer asks why a document has not arrived. A deadline passes because it lived in one person's calendar. The colleague who took over spends days searching old emails for the answer.

A good knowledge transfer process fixes two things: it starts as soon as the departure is known, and it works from the record of what the person actually did, not only from what they remember.

What the role actually did

The first output of the knowledge transfer process is a plain description of the role as it was really done: the recurring tasks, the people involved and the tools used.

Job descriptions are written once and rarely updated. After a few years in a role, a capable person has usually taken on work that appears nowhere on paper. This is where process documentation and business process mapping earn their keep: each recurring task written as a short sequence of steps, with who sends what, to whom and when.

The employee handover document should be organized around these tasks, not around the org chart. For each recurring task, it should answer the same questions.

Do not aim for perfection. A page per task, written in plain words by the person who does it, is far more useful than a polished manual that is finished after they have gone.

• What the task is, in one sentence.
• How often it happens, and what starts it.
• Who it involves: customers, suppliers, colleagues, advisers.
• Where the work arrives and where the result goes.
• Which files, folders, sheets and accounts it uses.
• What usually goes wrong, and how the person deals with it.

Open items and deadlines

Next comes the list of everything that is still open on the last day, and every deadline that falls in the months after it.

Open items are the threads in progress: a quote waiting for an answer, a dispute with a supplier, a promise made to a customer, a document requested but not received. Deadlines are the dates that come round whether anyone remembers them or not: contract renewals, filing dates, reports, certificates and licenses that expire.

Both lists need an owner per line. An open item with no named owner after the last day is likely to be forgotten. The table shows a simple format that works for both.

Reading the work trail with permission

The most complete record of what a role did is its work trail: the mailbox history and the attachments in it, read with the employer's permission.

A mailbox shows the real job. It shows who the person corresponded with, about what, how often, and what they promised. Attachments show the documents they produced and received. Read carefully, a few years of email reveal the recurring tasks, the open threads and the coming deadlines that a handover meeting tends to miss.

Seen this way, reading the work trail is the evidence step of the knowledge transfer process: it checks the list the person wrote from memory against what actually happened.

This must be done properly. The employer should authorize it in writing, the departing person should be told it is happening, and personal or private messages should be left alone. Rules on reading employees' email differ from place to place, so check with your adviser before starting. Reading should be read-only: nothing deleted, moved, forwarded or answered.

This is one of the services we are running today. With the employer's authorization, our robot reads the person's mailbox history and attachments read-only and writes what the role actually did, what is still open, the deadlines and a handover plan, before the last day. It runs on our servers against the company's own accounts and changes nothing in the mailbox. The result is a draft for the manager and the departing person to check together, not a final word.

The handover plan

The handover plan turns the findings into dated actions: who takes over each task, when they shadow it and when they do it alone.

The best plans use the remaining notice period to let the successor do each recurring task once while the departing person is still there to answer questions. A sound sequence looks like this.

1. As soon as the departure is known, agree the leaving date and name the people who will take over.
2. Gather the record: the recurring tasks, the open items and the deadlines, from the person and from the work trail.
3. Assign every line to a named successor and agree it with them.
4. Walk through each recurring task together, with the successor doing it while the departing person watches.
5. Transfer access: shared mailboxes, online accounts, supplier portals, files and passwords, through the company's own process.
6. Tell customers and suppliers who their new contact is, with an introduction from the person leaving.
7. On the last day, review the open items list together and confirm each owner one final time.

After the last day

A knowledge transfer process does not end on the last day; the first months after it are when the gaps appear, so keep the record and the plan in use.

Keep the handover document where the whole team can find it, and treat it as a living record. When something turns up that was missed, add it, with the answer. Agree with the departing person, before they leave, whether they are willing to answer a few questions afterwards, and how.

The mailbox itself remains a source. Rather than leaving it unread or deleting it, many businesses keep it accessible to a named person for a period, so that replies from customers and suppliers are not lost. How long to keep it, and who may read it, is again a question for your adviser.

Use the checklist on this page to see how much of this you have in place. Our handover service is rented monthly like the rest of our work, at one figure per workflow stated in the quote; nothing is switched on without your yes, every action is written to a log and one command stops it.

Making knowledge transfer a habit

The easiest knowledge transfer process is the one that has partly happened before anyone resigns, because the key tasks are already written down.

Most businesses only document a role when someone leaves it. A lighter habit works better: once a year, or whenever a role changes, ask each key person to list their recurring tasks and the deadlines only they track. It takes an hour, and it turns a future handover from an excavation into an update.

The same record helps in other moments too: a long illness, parental leave, a sudden holiday, a new hire who needs to learn the job. Process documentation kept this way is also the starting point for any automation, because a task that is written down step by step is a task that can be checked, shared or, in some cases, drafted by software.

None of this needs special tools. A shared folder with one page per role, reviewed on a fixed date each year, is enough to start.

Questions