How to write a handover that doesn't come back to you

Most handover documents are written at the end of a project, in an hour, by the person who most wants the project to be over. They're a list of where things are. Then the client messages you six weeks later anyway.

A handover that works isn't longer. It's a different kind of document, and most of the work isn't writing at all.

Start by deciding what they're allowed to do

Before you write a word, answer this: what will this client change, and what must not change?

The usual answer, once you say it out loud, is narrow. They'll add news posts, update staff, change opening hours, swap a photo, edit the copy on two pages. They will not redesign anything. Nobody at the client asked to redesign anything.

Write that list. It's the spine of the document, and it's also the specification for what you restrict. The temptation is to hand over full access and rely on the document to explain what not to touch. That reliably fails — not because clients are careless, but because a tool that offers an option is inviting someone to take it, six months later, under deadline.

So: restrict first, document second. Whatever your platform, give them the narrowest access that covers the list. A document that describes a locked door beats a document that asks people not to open an unlocked one.

Write it as tasks, not as a tour

A tour — "here's the dashboard, here's the media library, here's settings" — is how you'd explain the system to another developer. It's useless to a client, because the client doesn't have a question about the media library. They have a question about a photo.

Write a heading per real task, phrased the way they'd say it:

• Add a news post

• Change the phone number on every page

• Replace the photo at the top of the About page

• Add a member of staff

• Take a job advert down

Under each, the actual steps. Five lines, not a paragraph. Screenshots go stale faster than words, so use few and keep them for places where the interface is genuinely confusing rather than as decoration.

If a task takes more than about eight steps to describe, that's not a documentation problem. It's a sign the site is harder to run than it should be, and it's worth fixing before handover rather than explaining forever.

Say who owns what, in writing

The part every handover skips, and the part that prevents the most arguments a year later. One short section, in plain sentences:

Domain and DNS. Who holds the registrar account, whose card is on it, when it renews. If it's in your name, say when it moves.

Hosting. Who pays, what happens if a card expires, who to contact when the site is down at 9pm.

Email. Almost always someone else's problem, and almost always assumed to be yours. Say it explicitly.

Content. Theirs. Say so, and say how they get it out if they leave. A client who knows they can leave rarely does.

Design and structure. Yours to change, at an agreed rate. This is the sentence that converts "can you just" into a quote.

Support. What you'll answer for free, what's billable, and how long a reply takes. Even "same day, usually" is better than silence, because silence gets filled with the client's own assumption, which is always more generous than yours.

Agree the shape of a future request

Add one paragraph naming what a change request looks like: send it to this address, we'll come back with a price and a date, urgent things cost more. It feels stiff and it saves the relationship. The alternative is a stream of small asks arriving as friendly messages, none of which feel large enough to invoice, all of which add up.

Do the handover live, then send the document

Twenty minutes, screen shared, with them driving. Not you demonstrating — them doing. Have them add a real post and publish it while you watch. You'll find the two things that are confusing, which you then fix in the document, or better, fix in the site.

Record it. Six months later a new marketing person watches the recording instead of messaging you.

Then check back once

A short message a month later: anything you've wanted to change and couldn't work out? Costs you five minutes and catches the things people don't want to ask about. It also makes the next real project easier to win, which is the part that isn't about handover at all.

Where the platform can help

Everything above works anywhere, and most of it is about discipline rather than software. But it's worth noticing how much of it exists to compensate for one thing: the editing tool lets the client change more than they should.

That's the problem Contentive is built around. The client's editor is generated from the content model, so it contains their task list and nothing else — content permissions and structure permissions are separate, and there's no layout to break. Every change keeps a version history with restore, so "what did I do" has an answer. Deployments promote from staging deliberately and roll back in one click.

It doesn't remove the need for a handover. It makes the handover a list of things the client can do, rather than a list of things they mustn't.