A handover document tells the next person what someone believed was true on their last day. This template adds the two things it leaves out: a recording of the real work, and a way to prove the successor can do it.
A knowledge transfer plan is a list of every task one person owns, with enough detail that someone else can take each one over. One row per task. The row is the index. The recording of the task is the actual content.
Copy these seven columns into whatever your team already uses: a spreadsheet, a doc, your SOP tool.
| Column | What goes in it |
|---|---|
| Task and where | The task, and the exact screen it happens on: the Shopify admin orders page, the email platform's flow builder, the 3PL portal. Name it the way the successor will see it |
| Access needed | The role, seat or login the task requires, including anything tied to one person's own account |
| How often | Per order, daily, weekly, month-end, or peak season only |
| Cost if it goes wrong | What breaks and who notices: orders stuck unfulfilled, a campaign not sent, a payment missed |
| Verification signal | Something you can see in the tool that proves the task was done correctly |
| Handed over by | Shadowed, recorded, or both, with the date |
| Re-check by | A date to record the task again, and the name of whoever owns that date |
A row with no verification signal is a task nobody can prove was handed over. If you cannot say what "done correctly" looks like on screen, the successor cannot either.
This template covers the knowledge half of a handover. If someone is leaving, closing their logins is the other half, and it has its own order to follow.
The access half: why to suspend rather than remove in Shopify, the order to close logins, and the ones small stores forget.
Go tool by tool, not task by task. People forget tasks. They rarely forget which tools they open every day.
Sit down with the person and walk through each tool they use. For each one, ask what they do in it and how often. For most Shopify stores the list looks something like this:
Then mark every row that only this one person has ever done. Those rows are where the risk is, and they get handled first.
Put a rough number on how much of your operation depends on one person, before their last week rather than after it.
One thing to check while you are in each tool: whether an integration or automation was connected using this person's own login. If it was, it may stop working when their account closes. Find those before the last day, not after.
How often a task runs decides how it gets handed over. The answer is usually blunt.
| How often it runs | What the successor can get | How to hand it over |
|---|---|---|
| Per order or daily | Several live repetitions during a normal notice period | Shadow it, then do it while being watched. Record it as well |
| Weekly | One or two live runs | Shadow once, record the other run |
| Month-end | One run, and only if it falls inside the notice period | Record it if the timing works. Often it will not |
| Quarterly, annual or peak season | None | Record the last real run, name someone to call, and set a reminder well before it is next due |
That last row is where handovers quietly fail. The successor will do those tasks alone, months later, with nobody around who remembers how. So each one needs three things the daily tasks can skip: a recording made during a real run, a named person to call when it breaks, and a calendar reminder that fires days before the task is due, not on the day.
Automations belong in the same bucket. A workflow that only triggers during peak stock levels or unusually large orders will not show itself during a quiet month. Record what it does and what triggers it, even if you cannot watch it run.
Try it on one of your own procedures.
Record a process once, AI writes the structured SOP. 3 free SOPs, no credit card.
Have the person do the real task while recording, in the order they normally do it, one row at a time. No script and no rehearsal.
The value is in the decisions a written handover leaves out. Why this order gets held. Why this refund is done by hand. Which of two nearly identical macros is the current one. Ask them to say those decisions out loud as they go.
One rule about customer data. Any screen showing customer names, addresses, card details or payouts needs a test order or a pass with that information hidden. Everything else should be recorded with real data, because made-up data hides the odd cases that are worth capturing.
Then have the person read back the written steps from each recording once, while they still work there. They are the only one who can spot what the recording missed.
A handover is done when the successor has produced the right outcome in the tool. Not when they have read the document.
Pick one visible result per type of task:
Write the result against the row with a date and the successor's name. That line is what tells you later whether the person was trained or just briefed.
Why opening a document is not evidence of anything, and what to check instead.
On the date in the last column, record the most expensive tasks again. Then compare the new recording with the original instead of replacing it.
The comparison is the point. It shows which steps changed, whether because a tool redesigned a screen or because the successor found a better way. Replace the old version and you lose the ability to tell which.
How to keep both versions side by side, so a change is something you can see rather than something that silently happened.
Here is where this fails. If nobody owns the re-check date, the recording goes stale exactly like the document it replaced. Worse, people trust it more, because it has screenshots. Decide who owns that date before the handover finishes.
The ownership decision underneath every handover, and why an unowned document always goes stale.
Start this week with the five rows that would cost the most if they went wrong. Record those five while the person who owns them is still around, and name the owner of each re-check date before anything else.
A list of every task one person owns, written so someone else can take each one over without them. For a Shopify store, each row covers the task and the screen it happens on, the access it needs, how often it runs, what breaks if it goes wrong, and a visible result that proves the successor did it correctly.
Seven columns: the task and where it happens, the access needed, how often it runs, the cost if it goes wrong, a verification signal, how it was handed over, and a re-check date with a named owner. The verification column matters most, because without it nobody can prove the handover worked.
Long enough to cover one full cycle of every recurring task. A normal notice period covers daily and per-order work with room to spare. Month-end work needs the handover to span a month-end. Quarterly, annual and peak-season tasks will not fit in a short notice period, so they get recorded, a named contact and a calendar reminder instead.
Both, with the recording as the source. A written handover is the person's memory of the task, filtered through what they think matters. A recording captures the task itself, including the steps they no longer notice doing. Keep the written template as the index that points to each recording.
Rebuild from the tools, not from memory. Go through each tool, look at recent activity, and have whoever is covering record their own current run. Treat that as version one, mark what nobody knows, and set a date to record it again.
3 free SOPs to start. No credit card required. See if drift detection keeps your docs honest.
Start for freeI built ReccordSOP after watching too many DTC ops teams lose months to undocumented workflows. These SOPs are battle-tested with Shopify operators running $1M to $50M brands.
Last reviewed September 25, 2026
When someone leaves a small store, two things walk out with them: their logins and the steps only they knew. The checklist has to handle both, in the right order.
The Slack message pinned two years ago is the real SOP. The document nobody reads is the decoy.
A version history tells you what existed. A step-level diff tells your team what changed and whether it affects the work.
We use essential cookies for sign-in and a small amount of analytics to improve the product. Privacy policy.