The week before a long break has a familiar rhythm. You try to finish everything, fail, and then spend the last afternoon writing a handoff for whoever is covering. What usually comes out is one of two things. The first is a brain dump: pages of context in the order it occurred to you, useful to nobody at speed. The second is a single sentence — “should be quiet, call me if anything comes up” — which guarantees that something will come up and you will get the call.
A good coverage note is neither. It's short, structured, and written for one reader: the person who will open it on a Tuesday afternoon while something is going wrong. Its job isn't to transfer everything you know. It's to answer the questions that person will actually face while you're gone.
Write for the questions, not for the job
The difference between a brain dump and a coverage note is the direction it faces. A brain dump describes your job. A coverage note anticipates your stand-in's questions. Before you write a word, list what might actually land on their desk in the weeks you're away: the recurring task that falls due, the customer who's likely to write back, the report someone will ask for, the approval that can't wait. Everything in the note should serve one of those moments.
This is the same idea as the vacation test, applied to a real absence rather than a hypothetical one. The vacation test finds what only one person knows. The coverage note is what you do about it when that person is you and the time off is booked.
Five sections, in this order
- In flight. Every piece of work that's open and could move while you're away. For each: where it stands, what happens next, and what would count as done. One or two lines each, not a history.
- What might happen. The things you can predict: the recurring task with a due date, the renewal, the customer waiting on an answer, the month-end step. For each, what to do — or, just as useful, what not to do.
- Where things live. Links, not attachments. The folder, the dashboard, the system, the saved search. An attached file is a copy that goes stale the moment you leave; a link points at the real thing.
- Who to ask. For each kind of question, the person who can answer it who isn't you. Include the outside contacts — the vendor rep, the accountant, the partner — with a note on what each one can help with.
- What can wait. The explicit permission list. Anything on it is allowed to sit until you're back, and your stand-in shouldn't feel they've failed if it does. This section is the one most people leave out, and it's the one that prevents the most anxious phone calls.
Put your decision rules in the note, not just your tasks. “If the client asks to move the date, yes up to a week, anything longer waits for me” lets someone act. “Use your judgment” asks them to guess what yours would have been. If you keep a decision log, link the relevant entries; they're the reasons behind the rules.
Match the length to the absence. A few days away might need a half-page note covering the in-flight work and one or two contacts. A multi-week break over the holidays, when month-end and year-end tasks can fall due, deserves the full five sections. The test is simple: could your stand-in get through an ordinary day of your work using only the note and the people it names? If the honest answer is no, the note isn't finished.
Access, not passwords
A coverage note should never contain a password. It's the most tempting shortcut in the whole exercise, and the most dangerous: the note gets shared, forwarded, and saved, and the credential inside it outlives your vacation by years. If your stand-in needs access to something, give them their own access through the system's normal sharing or delegation features before you leave, and note in the document that you've done so. When you get back, decide whether that access should stay or be removed — which is exactly the kind of loose end an access audit exists to catch.
Write it a week early, then walk it through
A coverage note written on the last afternoon is written by someone who's tired and distracted, and it can't be tested. Write the draft a week before you leave. Then sit down with the person covering for a short walkthrough: go through each section, let them ask questions, and watch for the places where they look confused. Every question they ask is a gap in the note. Fix it while you're still there to fix it.
If you can, have them do one real task from the note while you're still around — run the report, send the update, process the request. A note that has been followed once is far more trustworthy than one that has only been read.
Turn it into knowledge when you get back
When you return, the note has one more job. Ask your stand-in two questions: what did you have to ask someone about, and what did you have to figure out yourself? Those answers are a list of the places where your team's knowledge lives only in your head. Some of them deserve a proper article or a written procedure so the next absence — yours or anyone's — starts from better ground.
Keep the note itself, too. Next year's version will be mostly the same, and editing last year's is much faster than starting from a blank page in the busiest week of the year.
The bottom line
Before a long break, don't write a brain dump and don't write a sentence. Write a coverage note that answers the questions your stand-in will actually face: what's in flight, what might happen, where things live, who to ask, and what can wait — with decision rules instead of “use your judgment.” Grant access properly instead of pasting passwords. Draft it a week early and walk it through. And when you're back, turn the questions it didn't answer into knowledge the whole team can use. You'll take a real break, and your stand-in will have a real chance.
— Tom
Handoffs that don't depend on your memory
KnowledgeByDesign keeps procedures, owners, and decision rules as linked articles — so a coverage note points at knowledge that already exists, and the gaps it finds become articles instead of phone calls.
See how KnowledgeByDesign works →