What leaves with an employee that the ERP never had

When someone leaves a business, the exit checklist covers access: revoke the login, collect the laptop, reassign the email. All of that is real and necessary. None of it touches the thing that actually made that person valuable, which was never stored anywhere the checklist could reach.

Access and knowledge are different assets

Access is a permission. It's binary, it's recorded in the system, and revoking it is a mechanical task that takes minutes. Knowledge is accumulated judgement — which supplier to push back on, which customer's complaints need immediate escalation and which can wait, which numbers in a report are usually a data entry error rather than a real problem. None of that has a field in the ERP. It exists entirely as pattern recognition inside one person's head.

The exit checklist handles the first perfectly and has nothing to say about the second, because the second was never the checklist's job — nobody designed it to be.

Why this is worse than it looks on paper

On paper, the role gets backfilled and the business carries on. In practice, the replacement starts from zero on everything that wasn't written down, and rebuilds that judgement the same way the original person did — slowly, through mistakes, over months. The business pays for that education twice: once when the first person learned it, and again when the second person has to relearn it, because none of it transferred.

This is easiest to see with the mistakes that used to get quietly caught. An experienced staff member develops an instinct for which transactions look wrong before they cause a problem. A replacement without that instinct approves things the predecessor would have flagged, not through carelessness, but because the pattern recognition that used to catch it left with the person who had it.

Where this hits hardest

Vendor and customer relationships — the informal understanding of who's reliable, who needs extra scrutiny, who responds well to a phone call versus an email. None of it is in the CRM. All of it leaves with whoever built it — see the vendor relationship that lived in one person's phone.

Exception handling — knowing which unusual requests are routine-but-rare versus genuinely suspicious. This kind of judgement is built entirely through repetition and pattern exposure, and a new hire hasn't had the repetitions yet.

Institutional scepticism — the healthy habit of double-checking specific things because of a past incident nobody else remembers. Without the story attached, the scepticism looks like an arbitrary extra step and often gets quietly dropped by whoever inherits it.

Why "document everything before you leave" doesn't really work

It's the obvious answer and it fails for a predictable reason: people don't know what they know. Most of this judgement is tacit — it operates below the level of conscious awareness, which is exactly why it feels like instinct rather than a rule. Asking someone to write down their knowledge before they leave produces a list of the things they consciously recognise as knowledge, which is a small fraction of what they actually carry.

What actually helps

Structured handover conversations, not a documentation request. Someone else — a manager, a successor, even a colleague — actively interviewing the departing person about specific scenarios ("what would you do if this customer complained about X") surfaces far more than asking them to write a memo, because it prompts recall rather than requiring unprompted recognition.

Shadowing before departure, not after. A successor who works alongside the departing employee for even a few weeks absorbs judgement through exposure that no document could transfer — see what a notice period is actually for.

Capturing exceptions as they happen, continuously, rather than trying to extract years of accumulated judgement in a two-week notice period. The earlier practice this cluster keeps returning to — write the reason down at the moment of the decision — is the only version of this that doesn't depend on remembering to do it all at once, under time pressure, on someone's way out the door.

Common questions

Why doesn't a standard exit checklist protect against this kind of loss?

Because an exit checklist is designed to handle access and assets — logins, equipment, permissions — which are concrete and easy to track. The judgement an experienced employee accumulates is tacit and was never recorded anywhere the checklist could reach, so revoking access does nothing to preserve or transfer it.

Why doesn't asking someone to document their knowledge before leaving work well?

Because most of what makes an experienced employee valuable is tacit knowledge that operates below conscious awareness — pattern recognition built through repetition, not a set of rules they could easily list. Asking them to write it down captures only what they consciously recognise as knowledge, which is a small fraction of the total.

What works better than a documentation request?

Structured handover conversations where someone actively interviews the departing employee about specific scenarios, and shadowing periods where a successor works alongside them before they leave. Both prompt recall and transfer judgement through exposure, which a memo cannot do.

How can a business reduce reliance on this kind of last-minute transfer?

By capturing reasoning continuously, as decisions are made, rather than trying to extract years of accumulated judgement during a notice period. A habit of writing down the reason behind exceptions and judgement calls as they happen means less has to be reconstructed under time pressure when someone eventually leaves.

Related: the vendor relationship that lived in one person's phone · what a notice period is actually for · key-person risk in finance