How to Document Processes When Your Best Employee Quits Tomorrow

You get the Slack message at 4:47pm on a Friday. Your best employee — the one who knows how everything actually works — just put in their two weeks.

Panic sets in. Not because they're irreplaceable as a person (everyone is replaceable), but because their head contains the operating manual for half your business. And none of it is written down.

You have ten business days. Here's how to capture as much as possible.

Stop trying to document everything

This is the first mistake everyone makes. You sit your departing employee down with a Google Doc and say "write down everything you do." They stare at a blank page. They write a few bullet points. They miss 80% of what actually matters because the most important knowledge is unconscious — they don't even realize they know it.

Instead, focus on three categories:

1. What breaks without them? Ask: "If you disappeared tonight, what would go wrong first?" This surfaces the critical path — the processes that will fail immediately and visibly.

2. What's slow without them? Ask: "What do people come to you for?" This reveals the informal support role they play. The questions they answer twelve times a week. The decisions that route through them because nobody else has the context.

3. What's invisible without them? Ask: "What do you do that nobody else knows about?" This is the hardest one. These are the maintenance tasks, the relationship management, the preventive actions that only become visible when they stop happening — usually as a crisis three weeks after the person leaves.

Use conversation, not questionnaires

Written documentation captures what people think they do. Conversation captures what they actually do.

Sit down with them. Ask them to walk you through their last Tuesday. Not a hypothetical process — an actual day. What did they do first? Why? What about that email from the vendor — how did they decide to handle it that way?

You'll surface things like:

"Oh, I always check the overnight error log before anything else because last year we had a thing where..."
"When I get a request from that client, I always loop in Sarah first because they have a history..."
"The report says to use Method A, but Method A hasn't worked since we switched vendors. I actually do it this way..."

This is the gold. The workarounds, the institutional memory, the relationship context that makes processes actually function.

Record the sessions

If your departing employee is willing (and they usually are — most people feel good about leaving things in order), record your conversations. Audio or video, doesn't matter. The goal is to capture the nuance that gets lost when someone tries to summarize their own expertise.

A 30-minute conversation where someone walks through their actual workflow will produce more useful documentation than a week of them trying to write it down.

Prioritize ruthlessly

You don't have time to capture everything. Rank processes by two dimensions:

Frequency × Impact. A process that happens daily and directly affects revenue gets documented first. A quarterly report that's nice-to-have can wait (or just won't get captured — accept that).

Here's a rough priority matrix:

Document immediately: Daily processes, client-facing workflows, anything with financial implications
Document this week: Weekly processes, internal workflows with multiple dependencies
Document if time allows: Monthly/quarterly tasks, one-person processes with low blast radius
Accept the loss: Rarely-used knowledge, historical context that's interesting but not operational

Focus on the "why," not just the "how"

The biggest failure mode of process documentation is capturing steps without context. "Step 3: Send the file to accounting" is useless if the new person doesn't know why it goes to accounting, what accounting does with it, and what happens if they skip this step.

For every process, capture:

What you do (the steps)
Why you do it this way (the reasoning)
What goes wrong if you don't (the consequences)
Who else is affected (the dependencies)

The "why" is what enables the next person to make good judgment calls when the process doesn't perfectly fit a new situation — which it won't, because processes always evolve.

Create a "landmine map"

Ask your departing employee: "Where are the landmines? What are the things that will blow up if someone doesn't know about them?"

Every organization has these:

The client who cancels if their invoice is even one day late
The server that needs manual restart on the first Monday of every month
The vendor contract that auto-renews in April unless you send a specific cancellation letter
The spreadsheet formula that breaks if you sort Column D

These are the things that cause disproportionate damage relative to how simple they are to prevent. A five-minute landmine conversation can save you weeks of crisis management.

Don't wait until someone quits

If you're reading this because someone just quit, do all of the above. Right now.

But here's the real lesson: this shouldn't be an emergency. The knowledge extraction that you're now cramming into two weeks should be happening continuously.

The best time to document critical processes is when the person who owns them is happy, employed, and not in a rush. Not when they've already got one foot out the door.

Tools like Understudy exist specifically for this — capturing operational knowledge through conversation before it becomes an emergency. Your best employee talks through how things actually work, AI captures the nuance and context, and when they eventually do leave (because everyone does), the knowledge stays.

The worst time to build a fire escape is during the fire.

The two-week sprint checklist

If you're in the thick of it right now, here's your daily plan:

Days 1-2: Identify the top 10 processes/knowledge areas at risk. Use the "what breaks, what's slow, what's invisible" framework.

Days 3-5: Record conversations about the top 5. One process per session, 30-45 minutes each. Don't edit yet — just capture.

Days 6-8: Have the departing employee shadow their replacement (if you have one) or a team member through the most critical workflows. Let the new person ask questions while the expert is still available.

Days 9-10: Rapid-fire Q&A. Collect every question the team has been saving up. Get the departing employee to answer them on record.

After they leave: Accept that you missed things. You will discover gaps in the first month. Document those too — they'll tell you what to capture earlier next time.

It's not going to be perfect. It's going to be better than having nothing.

Related Resources

Understudy for your industry: