How to hand off a workflow before you go on leave

The handoff doc you write the week before vacation is the worst doc you'll ever produce. Here's a saner approach: capture as you work, hand over the recording, and stop being the team's single point of failure.

The handoff doc you write the Friday before vacation is always wrong in the same way. You sit down, list the things you do, and write a paragraph about each one. The paragraphs are vague where the procedures are specific and specific where the procedures are flexible. Two weeks later you come back, the cover person has Slack-messaged you four times despite the doc, and you spend the first day after vacation firefighting.

The fix isn't a better template. It's a different moment. Hand-off documentation written the week before leave is documentation written from memory, under time pressure, by someone who already mentally checked out. The good handoff is the one you start three months earlier, by recording your routine work as you do it.

This post is a practical guide to that approach. What to record, when, what the artifact looks like, and how to make sure the cover person actually opens it.

What goes wrong with the Friday-before doc

Three failure modes, all predictable.

You forget the procedures you do automatically. The thing you do every Tuesday morning at 9am, the email you reply to twice a week — those are the ones most likely to be missing from the doc, because they're invisible to you. The cover person hits them on Tuesday morning at 9am and has no idea what to do.

You write at the wrong altitude. The doc describes the workflow in summary, not in steps. “Run the weekly billing reconciliation” is a label, not a procedure. The cover person reads “run the weekly billing reconciliation” and Slacks you because they don't know which dashboard, which filter, which report.

You bake in your assumptions. The doc says “check the dashboard for anomalies” without explaining what anomalies look like. You know an anomaly when you see one. The cover person doesn't. They either ignore real anomalies or escalate normal noise.

The capture-as-you-work approach

The premise: every routine workflow you do is a candidate for recording the next time you do it. Not all at once. Three months out from leave, start recording one routine per week. By the time leave starts, you have a library.

Three categories to record, in order of priority.

Category 1: the recurring scheduled work

The Tuesday-morning thing. The end-of-week reconciliation. The monthly customer report. Anything triggered by a calendar or a cron schedule.

These are the easiest to record because you know they're coming. Hit record before the next instance, do the work, stop recording. Edit titles where they're wrong. You now have a walkthrough that the cover person can follow on Tuesday morning at 9am.

Category 2: the trigger-based work

The thing you do when X happens. A customer escalates. A vendor sends an invoice. The pipeline fails. You don't know exactly when these will happen, but you know the shape.

These take longer to record because you have to wait for the trigger. Keep a recorder ready (the Chrome extension is fine for this) and hit record the next time the trigger fires. Within three months you'll have the top half of your trigger-based work covered.

Category 3: the “you'll know it when you see it” judgement calls

The hardest category. The decisions that look easy because you've made a thousand of them, and impossible to a cover person who hasn't. “Approve this refund or escalate?” “Bump this ticket priority or not?” “Is this customer about to churn?”

These don't fit the click-by-click walkthrough format, but they can still be captured. Record the next decision you make and add a long-form description on the relevant step explaining the heuristic: “Refund this because the failure was on our side. If the failure is on their side, ask the questions in the ‘refund denial checklist’ doc before approving.”

These end up as one walkthrough per heuristic. Five or ten of them is usually enough to cover the judgement-call work the cover person will face.

The handoff package

When leave is two weeks out, assemble the package. Six parts.

1. Cover memo. A single page. The dates you're away, the cover person's name, the backup's name, who to escalate to if both are unreachable. Top of the doc, no ambiguity.

2. Inventory of routines. A list of every workflow that might fire while you're out, sorted by urgency. Each item has a one-sentence description and a link to the walkthrough recording. Format:

  • Daily 8am: Slack alerts review — Open the #alerts channel and triage the overnight backlog. → walkthrough link
  • Tuesday 9am: weekly billing reconciliation — Pull the numbers from the billing dashboard and update the shared sheet. → walkthrough link
  • End of month: customer health report — Generate the report and circulate to the success team. → walkthrough link

3. Trigger-based playbooks. A separate section for the “when X happens, do Y” work. Same format: trigger, one-sentence description, link to walkthrough.

4. Judgement-call guidance. The heuristics. Each one a short walkthrough or written guidance. “If a customer asks for a discount over 20%, the answer is no — escalate to [name] before replying.”

5. Access checklist. Tools the cover person needs to be added to. Slack channels. Shared folders. Specific dashboards. Do this two weeks early so the access requests have time to clear.

6. The escalation path. The two or three things the cover person should not try to handle alone. Customer-data incidents. Production deploys. Anything with a legal angle. Specify who they should call instead.

The 90-day capture schedule

Working backwards from leave starting on day 0:

Day -90 to -60: Record the Category 1 recurring work. One walkthrough per week. Target: the top eight to twelve recurring procedures. Don't edit them heavily yet — first pass is fine.

Day -60 to -30: Record Category 2 and 3 work. Record the next instance of each trigger-based workflow as it happens. Capture the next few judgement calls and write the heuristics on top.

Day -30 to -14: Edit. Walk through every walkthrough you recorded. Fix titles. Add descriptions where the screenshot alone isn't self-evident. Redact anything sensitive. Re-record any walkthrough that has obvious gaps.

Day -14 to -7: Hand the package to the cover person and have them try one walkthrough end to end on a real instance. Where they get stuck, fix the walkthrough.

Day -7 to 0: Final access checks. Confirm the cover person can log in to every system they'll need. Set up your out-of-office. Leave.

Why recordings beat written docs for handoff

Three properties of recordings that matter specifically for the handoff case.

The cover person can match what they see on their screen against what you saw on yours. Written docs describe the screen; recordings show it. When the UI matches the screenshot, the cover person has confidence they're in the right place. When it doesn't, they spot the mismatch before clicking.

The URL of every step is captured automatically. The cover person doesn't have to figure out where “the dashboard” is. They paste the URL from the walkthrough and land on the same page you did.

The clicked element is captured by name and label. “Click the Approve button next to the customer's name” isn't something you have to remember to type — the recording already knows the visible text of the element you clicked. The cover person sees a step description that matches what they see on the screen.

Getting the cover person to actually open it

The best handoff doc, unread, is no handoff doc. Three patterns that improve the open rate.

Walk through the package live, once, before you leave. 30 minutes, screen share, click through the inventory and explain the structure. The cover person is twice as likely to open the recordings later if they've seen one once.

Hand it over in chunks, not all at once. If you drop a 12-walkthrough package in their lap on day -7, they won't open any of them. Drop one walkthrough a week starting at day -60, with a Slack message asking if anything was unclear. By day -7 they've seen them all in context.

Pre-fill at least one task. Pick the easiest recurring procedure and have the cover person actually run it once before you leave, with you available for questions. Now you know whether your walkthrough works and they have proof they can run the procedure.

What to share, and where

Three patterns for hosting the package.

Internal wiki page with embedded links. The cover memo and inventory in your Confluence / Notion / wiki of choice, with each item linking to a hosted walkthrough. The wiki page is searchable; the walkthroughs do the heavy lifting.

Markdown export into the wiki. If your team prefers everything in one place, export each walkthrough to Markdown and paste it into the wiki. Inline images. The cover person scrolls one page; you don't maintain links.

Team-shared cloud workspace. If your tooling supports it, share the walkthroughs with your team only — authenticated through Google or Microsoft Entra ID — and link from a single cover doc. Better for sensitive procedures than the public hosted link.

The dual benefit

Worth noting: a handoff library you build over 90 days isn't only useful for the leave it prepares for. Once it exists, it's the onboarding doc for your replacement, the SOP library for your team, and the audit trail for compliance.

The conversation when you come back from leave is also different. Instead of “I need to bring you up to speed on what happened,” the cover person can say “I followed the walkthroughs, here's what I deviated on, here's why.” You read the deviations, update the walkthroughs, and the next handoff is easier.

Start with one walkthrough

The first one to record: the procedure you do most often, that you'd be most worried about someone messing up while you're away. Hit record the next time you do it.

Try UIHike on the workflow you'd most worry about leaving uncovered. The walkthrough you record this week is the Slack ping you don't answer from a beach two months from now.

— The UIHike team