How to hand over business knowledge before someone leaves

When the person who knows how everything works leaves, a folder of documents rarely replaces their judgment. The difficult knowledge is often smaller and less visible: which customer needs a particular explanation, why an apparently redundant check exists, where a recurring exception gets resolved, and what must never be changed without approval.

A useful knowledge handover makes the next person capable of doing specific work. It gives them a starting point, a current record of commitments, decision limits, and a way to recognize trouble. That is a more demanding goal than collecting files, but it also produces a much more useful result.

This guide explains how a small business can organize that transfer without buying another platform. The method works for an employee leaving, a contractor finishing an assignment, a founder delegating operations, or a colleague moving into a different role. Employment obligations and access arrangements still need to follow the rules that apply to your organization.

Define what the handover must enable

Start with the work someone must be able to complete after the transition. Avoid a vague objective such as “transfer the marketing knowledge.” A clearer objective is “prepare the weekly customer update, identify missing approvals, and publish only the approved version.” You can observe whether that capability exists.

Separate three outcomes. First, the recipient can find current information. Second, they can perform routine work correctly. Third, they recognize situations that require help. Those outcomes need different evidence: a working link, a successful rehearsal, and an explained exception.

Atlassian’s knowledge-sharing guidance describes the importance of making organizational knowledge available beyond individual experts. For a small team, a practical application is to define the recipient’s next few tasks before deciding what to document.

If the role itself is poorly defined, begin with the responsibilities in your service catalog. A handover cannot settle every unresolved ownership question simply by assigning a new name to the old ambiguity.

Build a work inventory before recording explanations

List active commitments, recurring work, occasional responsibilities, and known exceptions. Ask the departing person to review their recent calendar, work queue, and approved project records. Memory alone tends to emphasize unusual work and overlook the small recurring tasks that keep services running.

For each item, record the trigger, next due date, business consequence, current owner, incoming owner, and location of the authoritative record. Include the last completed instance when it provides a useful example. Do not copy an entire customer archive into a handover pack when a permission-controlled link is sufficient.

Distinguish ownership from contribution. A colleague who provides figures for a report may not own the report. If two people appear responsible, name the person accountable for ensuring the next action occurs. Contributors can remain listed separately.

Also capture unfinished promises. “Send revised estimate after the client confirms quantities” is useful. “Client account: ongoing” is not. The next person needs the condition that unlocks the next step, not just the existence of a relationship.

Prioritize by consequence and recoverability

Not every task deserves the same transfer effort. A frequently used procedure with a trained backup may need a short confirmation. An annual renewal known by only one person may need immediate attention even if it is months away.

Use a simple decision table to allocate the available time:

Do not convert this into a complicated scoring exercise. The table exists to expose judgment, especially when the departure date leaves less time than the workload requires. Record what will remain incomplete and who accepts that risk. An honest gap list is safer than a completed checklist that hides uncertainty.

Capture decisions as well as instructions

A procedure explains what to do. Decision context explains why a competent person would choose one route over another. Both matter when the next case differs from the demonstration.

For important decisions, write a short record containing the situation, the options considered, the selected approach, the reason, and conditions that would justify reconsidering it. Link the approval or agreement where it exists. Describe assumptions as assumptions rather than presenting them as permanent policy.

For example, a hypothetical design studio sends proofs through a private project page because emailed attachments previously caused version confusion. The handover should explain that the page holds the approved proof, the client receives a link, and approval of a different attachment must be reconciled before publication. “Send proof link” alone loses the reason for the control.

Process documentation guidance from Atlassian provides a useful distinction between describing a process and leaving work dependent on informal memory. Your own SOP should include the decision boundaries that make its steps usable.

Use a small, consistent handover packet

Create one landing page or document for the role, then link out to the underlying work. Keep the landing page short enough that the recipient can understand its structure in one reading. Its purpose is navigation and operational context, not duplication.

Include the role’s purpose, responsibilities, current commitments, recurring calendar, key procedures, decision limits, relevant contacts, known risks, and unresolved questions. Give every section a named maintainer. Add the last review date and the transition date so readers can distinguish an old handover from current instructions.

Contacts need context. A supplier’s name and email address are less useful than an explanation of what they handle, which account reference to use, and who may authorize a paid request. Do not include private contact details that the recipient does not need or is not authorized to access.

The packet should point to a current queue. A static list of open work becomes misleading as soon as people start completing tasks. Make clear which information is a historical snapshot and which link contains the live operational record.

Transfer access through proper ownership

Knowing where information lives does not mean the recipient can use it. Check access early enough to resolve problems before the departing person becomes unavailable. Confirm the recipient can open required records, perform permitted actions, and reach the appropriate administrator if something fails.

Use individual identities and approved role permissions. Do not treat a shared password written in a handover document as a transfer method. Account ownership, recovery channels, billing contacts, and automation ownership may require separate administrator actions. Record those actions without copying secrets into the packet.

Some work should not transfer in full. A recipient may need operational status while an authorized specialist retains access to confidential underlying material. Document that boundary and the route for requesting an approved extract or decision.

Coordinate the knowledge transfer with the employee offboarding access checklist. The knowledge packet explains the work; the access process ensures continuing authority and removes permissions when appropriate. Completing one does not automatically complete the other.

Rehearse the work with the recipient in control

A demonstration can look clear while leaving the observer unable to repeat it. Reverse the usual format for the most important tasks: let the recipient perform the work while the experienced person observes. Use a safe example or an authorized routine case, and avoid irreversible actions solely for practice.

Ask the recipient to explain the expected result before starting. During the rehearsal, note places where they search, hesitate, or ask for an undocumented assumption. Those moments identify improvements to the procedure. They are information about the handover, not evidence that the learner is incapable.

Finish with a teach-back. Ask what would happen if the input were incomplete, the usual approver were unavailable, or the result differed from expectations. A person who can complete the happy path but cannot recognize an exception needs a clearer stopping rule.

Record only what is necessary. A short annotated example and a revised procedure may be more maintainable than an hour-long recording containing customer information and outdated screen details.

A hypothetical transition for an operations coordinator

Consider a five-person training provider whose coordinator is leaving. The coordinator manages course confirmations, participant lists, venue instructions, and completion records. The business has ten working days for the handover and cannot stop delivery during the transition.

The owner first identifies the next three scheduled courses. For each, the incoming coordinator receives the authoritative participant record, outstanding questions, venue contact, next communication date, and the person who may approve changes. Future unscheduled courses remain in a separate reference section.

The outgoing coordinator then documents one complete confirmation cycle. The recipient rehearses preparing a participant update, checking the distribution list, and saving evidence of the approved message. During that rehearsal, they discover that dietary information belongs in a restricted operations record rather than the general participant list. The procedure is corrected before transfer.

An occasional course cancellation becomes an exception exercise. The recipient explains how to pause scheduled reminders, obtain an authorized decision, and reconcile any outstanding commitments. They do not need to memorize every past cancellation; they need to know how to identify the current obligations and who can decide.

Finally, the owner accepts three remaining gaps: an old venue agreement needs review, a future course has no confirmed instructor, and one legacy folder has not been classified. Each gap receives an owner and a review date. None disappears behind a “handover completed” label.

Handle a short or unplanned departure

Sometimes there is no overlap period. In that case, switch from comprehensive transfer to controlled stabilization. Protect near-term commitments, find the authoritative records, assign temporary owners, and identify decisions that must pause until someone with appropriate authority can review them.

Do not infer current commitments from an old folder name or an automated reminder alone. Cross-check recent approved records and contact history available to authorized staff. Treat conflicting evidence as an open question, with a person responsible for resolving it.

For missing knowledge, create a reconstruction log. Record the question, evidence found, working assumption, risk, and validation date. This prevents guesses made during an urgent transition from becoming invisible permanent rules.

A wider business continuity plan should describe temporary coverage when a key person becomes unexpectedly unavailable. The handover packet provides detailed work knowledge; continuity planning decides how the business operates while that knowledge is incomplete.

Check inherited shortcuts before teaching them

A transition can expose habits that were never formally approved. Someone may have developed a workaround to meet an old deadline, then repeated it because it was convenient. The handover should preserve the reason for the workaround without automatically presenting it as the correct future procedure.

Ask which steps differ from the documented process and why. Separate legitimate adaptations from unresolved control gaps. A useful adaptation might be a clearer sequence for checking information. A questionable shortcut might skip an approval or keep customer records in an unapproved location. Those situations need different decisions.

Give the appropriate process owner a short review list. For each difference, record the current habit, the documented expectation, the consequence of changing it, and the person authorized to decide. Do not ask the incoming employee to settle every historical inconsistency while learning the role.

Where a decision cannot happen before the transition, state the temporary instruction and its limit. The recipient should know which method to follow now, which question remains open, and when it will be reviewed. That prevents an explanation of how work used to happen from becoming an accidental endorsement of every inherited practice.

Measure readiness instead of document volume

Counting files encourages people to produce more files. Measure whether essential work can continue. Useful indicators include critical tasks with an accepted new owner, rehearsals completed without undocumented help, unresolved access issues, overdue commitments, and exceptions with a clear escalation route.

Keep measures proportionate. A small team might review its ten highest-consequence responsibilities rather than score hundreds of minor activities. Mark each as ready, ready with an explicit limitation, or not ready. The middle state is valuable because real transitions often contain accepted constraints.

After the first week, review where the recipient needed help and whether the packet answered the question. Update the record while the experience is recent. A handover that nobody revisits can remain technically complete while becoming operationally obsolete.

Also examine the recipient’s workload. Transferring knowledge without transferring available time merely relocates the risk. If the new owner cannot realistically perform the work, change capacity, scope, or timing rather than adding more reminders.

Make knowledge transfer a normal operating habit

The cheapest handover to prepare is one that has already begun through normal work. Keep procedures beside the tasks they support, record consequential decisions when they happen, and maintain named backups for work that cannot pause. These habits make eventual departures less dependent on a final documentation sprint.

Choose one important recurring process this month. Ask another person to find its instructions, explain its boundaries, and complete a safe example. Fix what they cannot discover. That exercise tests whether the business owns its operating knowledge or simply knows whom to ask.

When a transition does occur, close it with explicit acceptance. The recipient accepts the defined responsibilities, the manager accepts any remaining gaps, and access owners confirm their changes separately. The result is a clear starting position for the next person, with evidence they can use and uncertainty they can see.

Sources and editorial method

Research checked October 15, 2026. This article uses Atlassian’s knowledge-sharing overview and process documentation guidance for general background. The handover packet, prioritization table, readiness checks, and training-provider example are original practical analysis. The example is hypothetical and does not describe a tested customer outcome. Adapt employment, confidentiality, and access arrangements to your own organization and applicable requirements.