Handover Notes a Co-Host Can Actually Follow

A handover document fails for one reason: it describes the building, not the decision. Write the second one and the first becomes optional.

Last updated: October 21, 2026

Most handover documents are written by someone standing in the flat, describing the flat. They fail at the moment they're needed, because that moment is rarely a tour. It's a message at eleven at night about water through a ceiling, and what the reader needs then isn't a floor plan. It's a decision they're allowed to make.

Key Takeaways

• A handover is an index of decisions, not a description of a property. Organise it by what the reader has to decide, not by which room they're standing in.
• Access has to be complete. It's the one section where a gap stops the stay rather than slowing it down.
• Judgement needs thresholds, not principles. "Use your judgment" transfers nothing; a boundary checkable in ten seconds does.
• Escalation needs an hour, not just a name. A contact without a time window gets tested at the worst possible moment.
• The document should shrink. If every review makes it longer, you're describing the building again.

Why handovers get ignored

Three reasons, and none of them is laziness.

The first is the index. A document organised by room assumes the reader arrives with time to walk it; in practice they arrive with one question and ninety seconds. If the answer sits under "Kitchen" but the question is a late checkout, the index has failed before the content is read.

The second is assumed context. "The usual cleaner", "the man who fixed it last time", "the spare set in the usual place" — each phrase is a hole only the writer can fill. A co-host who has to ask about three of those stops trusting the rest, and once trust goes the document stops being opened.

The third is ownership. A handover gets written once, at onboarding, and the property changes around it: a new lock, a new cleaner, a new bin day. Six months on, it's right about most things and wrong about what matters, which trains the reader to verify everything.

There's a quick test. Hand it to someone who has never been to the unit and ask five yes-or-no questions. Can you get in without calling me, can you let a guest in early, can you authorise a repair, who do you call at 2am, what do you do first if the water won't stop. If an answer takes more than a minute to find, the problem is structure rather than detail.

Three sections that earn their place

Access. Every entry needs four things: where it is, what it opens, when it changes, and who changes it. Door code, lockbox, building entrance, parking, bin store, meter cupboard, wifi. The wifi line isn't a courtesy: it's the first thing a guest asks for, and a co-host must answer without you.

Access is the only section that has to be complete. A wrong judgement call produces an awkward message; a missing code produces a guest on the pavement.

Put a date beside every code, and never write a code you can't rotate within the hour. A code the owner can't change is a code that gets forwarded, and forwarded codes end up in group chats.

Judgement. This is the section most handovers skip and the one that saves the most messages. Write decisions with boundaries, not principles. A co-host may let a guest in early if the unit is ready and the cleaner has finished. A co-host may replace a broken glass, kettle or lamp without asking. A co-host may not refund, discount, extend a stay for free, or accept a pet the listing excludes.

Write it as a short list of "may" and a shorter list of "may not", with the line explicit. Add the reason, briefly: a boundary without one gets argued with. "May not refund" is a rule; "may not refund, because refunds must match the terms the guest agreed to" is one a co-host can apply to a case you didn't anticipate.

Escalation. Name a person, a number and an hour, then name the second person, because the first will eventually be asleep or on a plane. Add what counts as a wake-up: water where it shouldn't be, no hot water with a guest inside, a lock that won't open, anything involving the police. Everything else waits until morning, and saying so is what stops a midnight call about a towel.

Then add the holding instruction: while waiting for a call back, shut the water at the stopcock, move the guest, leave the door on the latch for the plumber. That paragraph is worth more than the contact list, because it runs while nobody answers.

What to leave out

Cut the room-by-room tour. It's the longest section in most handovers and the least read: the reader will walk the unit anyway.

Cut the equipment inventory. Boiler make, filter model, the brand of the smart lock — facts with an expiry date belong in the maintenance file, not in a document about decisions. Finding a model number in a folder costs less than maintaining it in prose.

Cut the history and the philosophy. Which guest broke what in 2023, why the neighbour complained — it reads as context and functions as noise. A paragraph about hospitality standards doesn't survive a broken boiler. If there's a standard you enforce, write it as a check with a threshold.

And cut the account description. Write what a person may do, not how the account is configured — the configuration changes, the intent doesn't. LOCALSBNB grants access by domain rather than all or nothing, so a co-host can hold the calendar and the guest messages without holding every other setting. Write actions wait for a person to confirm before they take effect, which is the boundary the judgement section describes in prose.

localsbnb.com keeps the four connected channels — Airbnb, Booking.com, Agoda and Trip.com — on one calendar, so the access you grant and the units it covers are visible in one place rather than agreed over a call.

Reviewing it after the first stay

Book twenty minutes after the first solo stay, before the details fade, and ask three questions.

What did you have to guess? Every guess is a missing line, and it says where the line belongs.

What did you message me about? The message log is the best audit the document will get. Each thread is a gap or a boundary written too vaguely.

What did you not do because it wasn't written? This one is quieter and more useful. A co-host who didn't offer an early check-in or replace a lamp has shown you where the document made them cautious, and caution is expensive.

Then add lines, delete lines, and change the date at the top. A co-host who sees last month's version reads carefully; one who sees last spring's skims and improvises.

Run the review again after the first peak week, which exposes the escalation section fastest. After that, twice a year, plus every time a code changes.

FAQ

How long should a handover be?

Short enough to answer a question in under a minute. Two or three pages is typical, and access is the only exhaustive part.

Should the co-host have access to everything?

Not by default. Grant what the role needs, domain by domain, and keep the rest closed until a stay proves it's needed. Wider access is easy to add and hard to reverse.

What if the co-host is family or a friend?

The document doesn't change, only the tone. A friend will still be woken at 2am by the same burst pipe, and still needs to know whether they may call a plumber.

Write it for the version of the co-host who is tired, on a train, with one bar of signal. That reader is the real audience, and the document that serves them is short, dated, and organised around what they have to decide. localsbnb.com is where the units, the channels and the access already sit together, so the notes describe a setup rather than a memory.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. Access, delegation and payment arrangements between an owner and a co-host differ by market and by contract. Confirm your own obligations with the competent authority and take advice on the agreement you use.