Quick answer
Inventory unfinished and recurring work, prioritize the next business deadlines, assign receiving owners, document decisions and exceptions, and ask successors to rehearse critical tasks. Close each item only after recording what was demonstrated or what remains unresolved. Run account security and data preservation as coordinated but separate workstreams; incomplete handover is not a reason to leave a former employee's access active.
This guide is for people managers, operations leads, and HR coordinators. It covers operational knowledge and handover evidence, not final pay, benefits, termination decisions, or a universal legal retention schedule. Security administrators and qualified HR or legal reviewers must approve the controls relevant to your organization.
Prepare a handover register, not a folder dump
Download the editable handover register. This blank Markdown worksheet can be copied into your document or spreadsheet. It has no employee data, embedded automation or automatic completion formula.
Start with one record per responsibility that could stall after the departure. A responsibility might be a weekly customer report, an unresolved supplier exception, or approval of a release. A folder containing hundreds of documents is a source location, not a responsibility or proof that someone has taken over.
The receiving owner should help define the acceptance test. “Read the report guide” is an activity. “Produce the next report from the approved source, explain an excluded record, and route an exception to the correct reviewer” describes usable knowledge. Scale the test to the task's consequences; a rehearsal must not create an unauthorized payment or customer commitment.
Use these fields in your own spreadsheet or task system. The template is intentionally a work register rather than a personal dossier.
| Field | What to record | What to avoid |
|---|---|---|
| Responsibility and next trigger | Specific output, recipient, due date and time zone | A vague topic such as “customers” |
| Receiving owner and backup | People authorized to continue and escalate | “The team” without accountability |
| Source and version | Approved location, document owner, last checked date | Unsorted attachments and personal storage |
| Decision and exception | Rule, reason, boundary and escalation contact | Informal practices presented as policy |
| Access dependency | Resource, required role and administrator ticket | Passwords, recovery codes or copied sessions |
| Acceptance evidence | Rehearsal result, reviewer and remaining gaps | A meeting attendance list as completion proof |
| Current status and next action | Not started, captured, tested, accepted, or blocked | An unexplained green tick |
Cornell's knowledge-transfer guidance includes recurring work, relationships, systems and risks, and specifically directs staff to coordinate access changes with IT rather than share passwords. It is a useful institutional reference, not certification of this ten-step method. Source: Cornell Knowledge Transfer.
The ten-step employee offboarding knowledge transfer checklist
1. Confirm the transition owner and operating window
The manager names one coordinator and confirms the last authorized working time with HR and IT. Record the time zone, working availability, review sessions, and who can make decisions if the departing employee is unavailable. Do not assume every departure comes with two weeks of cooperative overlap.
Ask first: what must continue before another person could reasonably learn this role? That identifies the immediate continuity problem. Keep reasons for departure out of the operational register unless a qualified owner determines that a specific detail is necessary and appropriate. The coordinator needs scheduling constraints, not a collection of private HR information.
2. Inventory obligations using more than memory
Review approved project boards, calendars, recurring reports, service queues, scheduled automations and team-owned documents. Ask the employee to explain which tasks are missing from those systems. Separate active commitments from ideas, abandoned work and historical reference material.
For each item, capture the next event that would reveal a gap: an invoice exception, a customer renewal, a maintenance window, or a report deadline. Flag work that depends on a personal account or a single person's approval. A manager should validate inventory coverage with another knowledgeable colleague; the employee's recollection alone is not a completeness test.
3. Prioritize interruption risk and near-term deadlines
Review business consequences, urgency, available substitutes and recovery options together. A low-frequency obligation can matter more than a daily routine if nobody else can perform it and its deadline is imminent. Use named priority categories with reasons rather than inventing a precise risk score from uncertain inputs.
Reserve the available overlap for the highest-consequence gaps. A department history document can wait while a receiver learns how to stop a duplicate shipment. If the inventory is too large for the available time, the manager must explicitly defer work, assign temporary controls or reduce service scope. Do not hide the shortage behind “handover in progress.”
4. Assign successors and verify their practical capacity
Name the receiving owner for each responsibility and ask that person to confirm capacity, authority and relevant experience. Reassigning a row to someone who lacks time or approval rights does not transfer the work. Record a backup for time-sensitive responsibilities where coverage is needed.
When no replacement exists, split responsibilities among interim owners instead of assigning an entire role to a vacant position. The manager retains the unresolved allocation decision. Use the 30–60–90-day onboarding plan for the successor's longer learning journey; offboarding must still cover the work due before that journey is complete.
5. Capture a runnable procedure and its decision boundaries
For a critical task, write the trigger, required inputs, approved source, steps, expected output and escalation condition. Add one ordinary example and one exception. Explain why a decision was made when that reasoning affects future action, while distinguishing approved policy from personal preference or an unverified workaround.
For example, “send the report every Friday” omits the cutoff time, missing-data rule and approver. A useful procedure names those dependencies and says when not to send. Link to the controlled policy instead of copying it into multiple notes. When sources conflict, record the disagreement and ask the policy owner; do not select whichever version makes the handover look complete.
6. Transfer work relationships and pending commitments
Document the purpose of important internal and external relationships, the current commitment, its due date, and the authorized successor. Arrange introductions where appropriate. Transfer business context, not personal judgments about a contact or speculative comments about colleagues.
Check whether a promise exists only in an email thread or meeting note. The successor must know whether it was approved, proposed or disputed. Have the relationship owner approve any outward announcement; do not let a generated summary send messages automatically. A contact list without the next promised action leaves the operational problem unsolved.
7. Coordinate access, ownership and retention with administrators
Create administrator tasks for required permissions, document ownership, shared resources and scheduled jobs. Identify integrations that depend on the departing person's credentials without copying secrets into the register. The authorized system owner should arrange replacement identity, credential rotation or job changes and test continuity under the approved procedure.
Account sign-in, file ownership and retention are different controls. Microsoft's former-employee guidance separates blocking access from preservation and successor access. Google Workspace's administrative Drive guidance also places conditions on ownership transfer, including organization boundaries. Use the instructions for the actual tenant and resource type, not a generic “share everything” shortcut. Microsoft 365 offboarding overview; Google Workspace administrative ownership transfer.
8. Have the successor perform a controlled rehearsal
Choose a representative task and have the receiving owner work from the handover material using their own authorized access. The departing employee can observe and clarify, but should not silently finish missing steps. Record where the receiver needed help and update the procedure accordingly.
For irreversible or sensitive actions, use approved test data, a dry run, or an administrator-supervised simulation. A simulation demonstrates only what it exercises; it does not establish that all production permissions work. Mark those remaining dependencies separately. Include one exception path so the receiver proves they can stop and escalate, not merely reproduce a happy-path sequence.
9. Accept evidence or keep the gap visible
The receiving owner records the demonstration result. The manager reviews whether the evidence meets the agreed acceptance condition and whether remaining limitations are tolerable. Keep “captured,” “tested,” and “accepted” separate: they answer whether material exists, whether someone tried it, and whether an accountable person approved the handover.
A failed rehearsal creates a specific action with an owner and deadline. A risk accepted temporarily needs an expiry date, fallback and decision maker; it should not become permanent by omission. If a high-consequence dependency is still unresolved, mark the item blocked and activate the continuity plan rather than declaring the whole role transferred.
10. Review the first operating cycle and close deliberately
Schedule a check after the successor's first relevant operating cycle. That may be the next daily queue review or the next month-end task; one universal follow-up date is not sufficient. Confirm that the output reached its recipient and that exceptions were handled without relying on the departed person's account.
Update the record with lessons from actual execution, remaining ownership changes and a future document-review trigger. Remove unnecessary duplicates according to approved retention rules; do not delete material subject to a hold. Closure means responsibility, evidence and remaining risk are understood—not that every uncertainty has disappeared.
Example: a complete document that still fails handover
The following is a hypothetical teaching example, not an OpenMax customer result. A customer-operations specialist is leaving. The manager selects three responsibilities for the first review: a weekly report, an exception queue and a supplier escalation. The report has detailed instructions, but its scheduled export still runs under the specialist's personal work identity.
The receiver can explain the reporting logic and reproduce a redacted report. That supports procedural understanding. It does not prove the scheduled export will continue after account access changes. The register must preserve that distinction.
| Responsibility | Demonstrated evidence | Remaining issue | Status and next action |
|---|---|---|---|
| Weekly customer report | Receiver reproduces approved test output and explains exclusions | Scheduled export identity has not been migrated | Tested, not accepted; system owner migrates and validates the job |
| Exception queue | Receiver handles a sample and routes a prohibited action for approval | No material gap found in the selected test | Accepted for the tested scope; review next live cycle |
| Supplier escalation | Contact introduction is acknowledged | Receiver has not handled an urgent exception | Captured; rehearse the escalation boundary before acceptance |
If the departing employee's access must end today, IT follows the approved security timing. The manager can authorize a permitted manual reporting fallback while the system owner resolves the scheduled job. Neither a good document nor a successful simulation justifies keeping an inappropriate account session alive.
The lesson is not that every handover needs complicated software. It is that operational knowledge, resource ownership and technical continuity need distinct evidence. A single completion percentage would conceal the report's remaining dependency.
Choose the simplest workflow that exposes missing work
A manually maintained spreadsheet and shared document can work for an occasional departure with a small, well-understood inventory. Use explicit owners and review dates. Its limitation is coordination: copied lists can diverge, and an overdue item may be invisible outside the manager's view.
Native HR or service-desk task rules can add assignments, reminders and administrator approvals when departures are recurring. Verify what the tool actually tracks. A completed access ticket does not establish that the successor understood the task, and a completed HR checklist does not prove a scheduled job still works.
No-code or scripted automation can synchronize approved status fields or check missing owners. Start with a dry run, retain error records and stop on ambiguous identity matches. Avoid connecting a general-purpose content workflow directly to destructive account actions.
An agent-assisted workflow becomes useful when authorized procedures and handover notes are too fragmented for manual review. It can be evaluated for drafting source-linked summaries, identifying missing fields and preparing questions. Treat source documents as evidence, not instructions that can override the review process. At larger scale, keep queue monitoring, exception handling, access controls and human approvals explicit.
Where OpenMax fits—and what still needs verification
OpenMax describes its product as a workspace for human–agent collaboration. That positioning makes coordinated handover preparation a reasonable workflow to evaluate. It does not establish a built-in offboarding module, a connection to your HR system, or the ability to revoke every account safely.
For a proposed pilot, the input is an approved, sanitized handover register plus a small set of selected procedures. The proposed agent output is a draft responsibility summary with source references, unresolved questions and suggested review tasks. The receiving owner checks accuracy; the manager accepts business continuity; IT handles permissions and identity changes in the authorized administrative systems.
Before using real records, confirm supported data sources, isolation and retention settings, permission boundaries, audit evidence and available review controls with OpenMax. Test missing and contradictory source material as well as a normal handover. If the deployment cannot keep administrative actions separate from drafting, do not connect account-management privileges to the pilot.
Start by preparing one non-sensitive handover example and discussing the workflow with OpenMax. Ask for a demonstration of source traceability and human review using that example. A small team with one straightforward transition should keep the manual checklist if it already provides adequate visibility and control.
Handle abrupt departures and sensitive records differently
Without overlap, the manager and system owners reconstruct the inventory from authorized sources and consult knowledgeable colleagues. Mark inferred information as unconfirmed. Test critical tasks and prioritize immediate obligations; do not recreate the former employee's identity to recover informal know-how.
Retention and access require their own decisions. Preserving information for an approved purpose does not grant every successor permission to read an entire mailbox or private HR record. Legal holds, contractual duties and privacy requirements vary. Ask qualified reviewers to approve scope and timing; this guide supplies no universal retention period or legal determination.
Recordings are optional. If a session may be recorded, obtain the required authorization and notice, limit access, and keep a written procedure so a useful step is not buried in a long video. Do not upload confidential conversations into an AI service merely because transcription is available.
For policy questions, use the employee policy assistant guidance to separate cited rules from uncertain interpretation. The same discipline applies here: an answer with no reliable source should become a review question, not an invented handover instruction.
Frequently asked questions (FAQ)
What should an offboarding knowledge transfer checklist include?
Include specific responsibilities, upcoming deadlines, approved source locations, receiving owners, decision boundaries, access dependencies and acceptance evidence. Keep account secrets and unnecessary personal information out. The checklist should identify who can continue each task and what remains unresolved.
When should knowledge transfer begin?
Begin when the transition is authorized and the relevant people can be informed. Use the available overlap to inventory and test priority work. When there is no overlap, use a manager-led continuity process rather than assuming the departing employee can complete a standard schedule.
Is a handover meeting enough to mark an item complete?
No. A meeting can capture context, but acceptance requires evidence appropriate to the task. Ask the receiver to demonstrate a controlled task or explain an exception, then record what the test did and did not establish. An attendance record is not a capability check.
Should account removal wait until handover is accepted?
No. Administrators follow the authorized security and employment timeline. Business continuity, information preservation and successor access should be coordinated without treating unfinished documentation as permission to keep the former employee's access active.
Can AI replace the departing employee's explanation?
AI may help organize approved material and surface unanswered questions, but it cannot recover undocumented reasoning reliably or certify that a successor can perform the role. Label uncertain statements, check sources and retain human responsibility for acceptance and administrative actions.
Sources, editorial limits and your next action
This is an OpenMax-branded educational guide with a commercial link to OpenMax. The ten-step checklist and sample register are editorial recommendations, not a validated standard, customer benchmark or claim of firsthand product testing. No named HR, legal or security expert review has been supplied for this draft; obtain appropriate review before operational adoption.
Source scope, checked September 4, 2026:
- Cornell Knowledge Transfer: institutional handover topics and password-sharing warning.
- Microsoft 365: remove a former employee and secure data: separate administration paths for access, preservation and successor access. Tenant-specific execution is outside this checklist.
- Google Workspace: transfer Drive files as an administrator: administrative ownership-transfer conditions, not a universal transfer rule for every service.
- OpenMax official product site: vendor positioning; the pilot described above remains a proposal requiring verification.
Choose the next responsibility that could fail after a departure. Name its receiving owner, agree on a safe demonstration, and capture the unresolved dependencies. That first accepted handover is more useful than a large archive nobody has proved they can use.

