Someone just quit, and nobody else knows how to do their job. Now what?
Short answer: First, don't panic-hire. Sit with anyone who worked near the departing person and reconstruct what you can from emails, CRM notes and calendar history before they're gone, ideally during their notice period. Then fix the root cause: write down every role's core tasks somewhere structured, with an owner, so this never happens again blind. A shared folder works for a small team; Trainual's subject-and-owner structure is built for exactly this once you have enough roles to track.
You just found out someone's leaving, or they already have, and you're realizing in real time how much of their job existed only in their head.
I'm Ranjit, and I run Blur Studio: 15+ years building software, 120 apps taken live, and clients who have gone on to raise $10M+. I build AI systems and processes that help businesses do a lot more with a lot less time. I also work differently from most of what else is out there, more on that further down this page. Say hello.
This page may contain affiliate links from which Blur Studio earns commissions.
This is one of the most expensive surprises a small business can have: someone quits, and it turns out they were the only person who knew how a client account worked, how a vendor relationship was managed, or how a recurring task actually got done. The cost isn't just their absence, it's the time everyone else spends reconstructing what they knew, usually under pressure, usually imperfectly.
What to do in the first week
- If they're still in their notice period, use it. Sit down with them specifically to write down (or have them write down) their recurring tasks, not just a generic handover memo. Ask "what would I not know how to do if you left today" directly.
- If they're already gone, reconstruct from evidence. Email threads, CRM activity history, calendar invites and shared drive file history all hold clues about how the work actually got done, even without the person there to explain it.
- Talk to whoever worked closest to them, even if it wasn't their manager. The person in the next desk often knows more about the day-to-day mechanics than anyone officially responsible for oversight.
A plain handover template, done by hand for free, covers the basics: current projects, key contacts, recurring tasks and their deadlines, and where files live. It won't capture judgment calls or the "why" behind a process, but it's better than nothing and costs nothing to start today. A first-pass method is in how to get your business processes out of your head and written down.
The real fix is before this happens again
The underlying problem isn't that one person left, it's that their knowledge had no backup. Trainual, a platform built for writing up company roles and processes so the knowledge survives whoever holds it, structures this exact gap with its content builder: every role or process gets written up as a subject, with documents and steps inside, and an owner assigned to keep it current. If the owner leaves, the write-up doesn't leave with them.
Trainual itself is quote-only (Core, Pro, Premium, Enterprise, no published monthly price) with a $1,000 one-time setup fee on every new account. That's a real cost to weigh against a plain shared folder of documents, which costs nothing but also has no owner field, no structure and no built-in way to know whether a write-up is stale. For a handful of key roles, a folder with a clear naming convention can genuinely be enough. Once you're tracking a dozen or more roles across a growing team, the structure starts earning its cost.
What this (or any) tool cannot fix
If the departing person's job involved a physical skill, a trade, a specific way of talking to clients, or judgment built from experience, write-ups alone won't transfer it. Documentation captures steps; it doesn't capture the feel of doing something well. Pair any written process with a real ride-along or shadow period for anything hands-on, and treat the documentation as the reference material, not the full training.
A worked example: an office manager quits with two weeks' notice
Say a ten-person service business has one office manager who handles invoicing, a handful of vendor relationships, and the scheduling software nobody else has ever logged into. She gives two weeks' notice. The owner's instinct is to post the job opening immediately and worry about handover once someone's hired, but that gets the order backwards: a new hire with no write-up to learn from will ask the departing person the exact same questions the owner needs answered first, except the departing person will already be gone by the time those questions come up.
A better use of two weeks looks like this: day one, the owner sits with her for ninety minutes and lists every recurring task by name, not descriptions, just the list: run payroll every other Friday, reconcile the vendor invoice from the lumber supplier, renew the software licenses in March. Day two onward, she writes a short step-by-step for each item on that list, starting with whichever one happens soonest on the calendar. The owner or another staff member actually performs each task alongside her before she leaves, not just reads her write-up, since watching someone do a task surfaces the unwritten shortcuts and judgment calls that never make it into a document. By the end of two weeks, the business has working write-ups for the five or six tasks that would otherwise have caused real problems, plus a far better sense of which ones genuinely need a trained replacement versus which ones can wait.
Common mistakes after a key departure
- Hiring before documenting. A new hire learns fastest from a real write-up and a shadow period, not from guessing and asking around. Documenting first, even informally, makes the eventual replacement's ramp-up dramatically faster. Plan their first days with a new employee first-week checklist.
- Assuming a manager already knows the details. Managers often know what gets done, not exactly how. Don't skip the direct sit-down with the departing employee just because someone above them exists.
- Treating the handover memo as finished once it's written. Test it immediately by having someone else try to follow it for a real task, the same week, while the departing person can still answer questions if something's missing.
- Letting the crisis fade without fixing the root cause. Once the immediate gap is covered, it's easy to feel the problem is solved and skip building a standing process for every other role. The next departure then catches you just as unprepared. If the person everyone depends on is you, read how to stop being the only one who knows how things work.
A practical note on buying yourself time before the person actually leaves
If the departing employee is open to it, a short paid consulting arrangement after their official last day, a few hours on call for questions during the first month of their replacement's ramp-up, is often cheap relative to the cost of a badly handled knowledge gap. Not every departure allows this, and it shouldn't be relied on as the primary plan, but it's worth asking about directly rather than assuming someone who's quit has no further interest in helping, especially if the departure was on reasonably good terms. If they also texted customers from a personal phone, see how to keep customer conversations when a staff member leaves.
How I'd approach this
After the immediate fire is out, I'd walk through every role in the business and ask the same question for each one: if this person left tomorrow, what would actually break? That list is your real documentation priority, not every task equally. For a handful of genuinely critical roles, a structured write-up with an owner, whether in Trainual or a well-organized folder, is worth doing properly before the next departure, not after. I'd also build in a standing habit rather than a one-time project: every time someone new starts, have them write down what they learn as they learn it, since a fresh hire notices the gaps in existing documentation far more clearly than someone who's been doing the job for years and has stopped noticing what they know by instinct.
Questions people ask
What's the first thing to do when a key employee quits?
If they're still working their notice, sit with them and write down their recurring tasks and key contacts directly, don't rely on a generic handover memo. If they've already left, reconstruct from email, CRM history and calendar records, and talk to whoever worked closest to them.
How do I stop this from happening again?
Document every role's core tasks somewhere with an assigned owner, so the knowledge doesn't live only in one person's head. A shared folder works for a small team; a structured tool like Trainual helps once you're tracking many roles across a growing business.
Can documentation fully replace losing an experienced employee?
No. Write-ups capture steps, not judgment or physical skill built from experience. Pair documentation with a real shadow period or ride-along for anything hands-on, especially in a trade.
Is a free handover template good enough?
For a small team with a few key roles, often yes. It covers the basics: current projects, contacts, recurring tasks and file locations. It lacks structure and an ownership field, which matters more as you have more roles to track.
What does Trainual cost for this specific use?
Trainual doesn't publish a monthly price; it's quote-only across Core, Pro, Premium and Enterprise, plus a $1,000 one-time setup fee on every new account. Weigh that against your actual number of key roles before committing.
Should I document every role or just the critical ones?
Start with the roles where, if the person left tomorrow, something would genuinely break. That's a shorter list than "every role" for most small businesses, and it's the one worth getting right first.