Ownsteps

Ownsteps / Guides

Employee handover document: template and checklist for when someone leaves

Reviewed .

When someone leaves or changes role, the most expensive loss is rarely a file. It is the routine nobody wrote down: which report goes out on Fridays, where the vendor portal login request goes, what to check before approving a refund. A handover document gets that knowledge out of one head while the person is still available to answer questions.

This guide gives a template you can copy today, a short list of what to capture first, and a way to record browser-based tasks with screenshots so the next person can follow them. You can do all of it with a text editor and manual screenshots.

Start with a two-week window, not a brain dump

A departing colleague usually has limited time. Asking for "everything you know" produces a vague page and a tired author. Instead, ask for three lists and work through them in order:

  1. Recurring tasks they do weekly, monthly or quarterly, with the usual date.
  2. Things only they can do because of access, relationships or habit.
  3. Open work: anything started and not finished, and who is waiting on it.

Rank the first two by what hurts most if it is missed. Document the top five properly instead of twenty badly. A missed month-end export is a bigger problem than an obscure tool nobody uses.

Handover template

Copy this into your document tool. Fill one block per recurring task, and keep the role-level sections short.

HANDOVER: [name / role] to [name or team]
Prepared on: [date]    Last working day: [date]
Reviewed with successor on: [date]

1. ROLE SUMMARY
- Main responsibilities (3-6 bullets)
- Who depends on this person's work, and for what
- Systems and tools used (names only, no passwords)

2. RECURRING TASKS (one block each)
Task: [name]
When: [daily / weekly on Friday / month-end day 3]
Trigger: [what tells you it is time]
Steps: [numbered, with screenshots for browser steps]
Expected result: [what done looks like]
If it goes wrong: [who to ask, what not to do]
Last done: [date]

3. ACCESS AND ACCOUNTS
- Systems that need access for the successor
- Who approves access (role, not password)
- Shared accounts to be re-owned or rotated

4. OPEN WORK
- Item / status / next step / who is waiting

5. PEOPLE
- Key contacts inside and outside the company, and why

6. KNOWN QUIRKS
- Things that look wrong but are normal, and the reverse

7. SUCCESSOR SIGN-OFF
- Tasks the successor has done once with the author watching

Never write passwords, recovery codes or API keys into the handover. List which systems need access and who grants it, then rotate shared credentials when the person leaves. The document should be safe to open in a ticket or an email thread.

Make each recurring task testable

The test of a handover is not whether it reads well. It is whether the successor can do the task. For each top-priority task, ask the successor to run it once while the author is still reachable, using only the document. Whenever they ask a question, add the answer to the step where the question came up.

Look for these gaps, which an experienced person no longer notices:

Example: a month-end report task

Here is how one block might look when filled in. It is a structure example; replace the details with your own system.

  1. Task: Export last month's invoice list and send it to Finance.
  2. When: Third working day of the month, before 12:00.
  3. Steps: Open the billing portal and confirm the account shown is the company account. Choose Reports, then Invoices, and set the date range to the previous calendar month. Export as CSV. Check that the row count matches the figure in the portal summary. Attach the file to a reply in the Finance thread.
  4. Expected result: Finance confirms receipt and the count matches.
  5. If it goes wrong: If the portal shows a different account or the count does not match, stop and ask the billing owner. Do not re-run exports with a changed date range to make the numbers fit.

The line about stopping is as important as the steps. A successor who cannot tell a normal result from a bad one will either guess or freeze.

Recording browser tasks with screenshots

Many handover tasks are click paths in a web app: a portal, a CRM, an admin console. Words alone are slow to follow, and a few annotated screenshots remove most of the guessing. You can take them manually, or record the path once as the author does the task for real on their last few days.

Ownsteps is a Chrome extension that records webpage clicks, captures a screenshot of each, and builds an editable step-by-step guide on your computer. Edit titles and notes, delete detours, replace images, black out private areas and export Word, PDF, HTML or Markdown. It does not capture desktop applications, terminals or remote sessions, so any step outside the browser needs a manual note or screenshot. See the redaction checklist before sharing any guide that shows customer data.

Ownsteps does not save what you type into fields, skips password fields and blacks out input boxes in screenshots. Page text elsewhere can still appear, so review each screenshot, and check client names, notifications and URL parameters.

Store it where the successor will look

A handover that sits in a departing person's personal folder will be deleted with their account. Put the reviewed document in your team's normal knowledge base or shared drive, name it so it can be found by task, and tell the successor and their manager where it is. Give it an owner and a review date; a handover that is never reopened turns into a historical record of how things used to work.

When the successor has done each key task once, move the useful parts into ordinary procedures. Use the free SOP template for repeatable tasks and the work instruction guide for short single-action instructions. See SOP examples for filled-in IT, support and HR procedures.

A short checklist for managers