Internet, Keys and Codes: Handing Over Access on Day One

Access is the one part of a stay that has to work perfectly the first time. There's no second attempt at a front door.

Last updated: October 1, 2026

Most problems in a short stay can wait for a message. A cold radiator, a missing corkscrew, a shower that runs cool for a minute — all of them are survivable, and all of them can be explained. Access isn't like that. A guest who can't get through the door isn't having a small problem; they're standing on a pavement at midnight with a suitcase, and you're the only person who can fix it.

Key Takeaways

• Send three things before the guest travels. The way in, the wifi details, and a named person to contact if the door won't open.
• Give every stay its own code. The reason to prefer a code over a key is that you can change it — so change it, every time.
• Keep one backup that isn't a phone. A guest with a dead battery can't read a message, no matter how well you wrote it.
• Widen the access window, not your patience. A code that only works after 3pm creates a problem out of an early flight.
• Log who held access and when it changed. The record is what answers a question about last month without guesswork.

The three things a guest needs before they arrive

Send all three in one message, before the guest leaves home. Not as they land, and not in three separate notes that arrive out of order.

The way in. A door code, or the exact place a key will be, plus which door it opens. If the building has a shared entrance and a second lock, both belong in the same sentence. A guest who has to work out which of two doors the code suits will try both, and one of them will fail.

The network details. The wifi name and password, written as text in the message rather than only printed on a card inside the flat. The card is a useful backup for a guest who's already in. It's useless to a guest who's outside and trying to look up how the heating works before they've unpacked.

A person to call. A name and a number, and a plain statement of when that person is reachable. This is the one item hosts skip most often, and it's the one that turns a two-minute problem into a forty-minute one. If you'd rather not give out your own number, name whoever is nearest — a co-host, a neighbour, a cleaner on the ground.

Put them in the order a guest will need them: door first, network second, contact third. Then check the message once before you send it. Half of all access problems are a code that changed after the message was written.

Writing a code policy you can actually rotate

A code beats a key for one reason: you can change it. A key, once cut, stays valid until you re-key the lock. A code can be different for every stay, which means a guest from March can't walk in during July.

So build a policy around rotation rather than around convenience.

One code per stay. Never the same code twice in a row, and never a code that reveals anything — not the flat number, not a street, not a birthday. It doesn't need to be memorable to anyone but the guest, and the guest only needs it for a few days.

Rotate between guests, not between problems. Change the code as part of the turnover, in the same fifteen minutes you change the bedding. If rotation is a separate chore, it becomes a chore you skip on a busy week, and a code from last month is exactly as good as a key left under a mat.

Keep a spare way in that isn't the code. Smart locks are convenient and they still have batteries, networks and app updates. A physical key in a lockbox, or a neighbour who can open the door, gives you a second route when the first one fails. Choose the route that a guest can use at two in the morning without waking anyone who isn't expecting it.

Be honest about the limit. A code you send by message can be forwarded. That's a real risk and not a reason to avoid codes; it's a reason to rotate them. If a guest tells you a friend will arrive a day later, meet that person or give them their own entry, rather than forwarding the code that opens the flat while the original guest is still inside.

One more habit: change the code after the stay, not when the next booking arrives. Rotating on departure means a flat is never sitting with an open code on an empty calendar.

What to do when a phone dies or a flight lands late

Two failures cause most access emergencies, and neither has anything to do with the lock.

A dead phone is the first. The guest has the code, but not the ability to read it, and they're standing outside with nothing to check. The fix isn't a better message; it's a second surface. Put the door code somewhere they can reach without their own device — the platform's booking thread opens in any browser once they're signed in elsewhere. More reliably, make sure the person to call can simply open the door. A human being with a key outranks any clever recovery step.

A late flight is the second. Delays push arrivals into the small hours, and a code window built around a planned time turns a two-hour delay into a lockout. Set the window wide: from the morning of the arrival date through to the morning after the departure date. If a guest lands at one in the morning, the door should still open, and their first experience of the flat shouldn't be a message thread.

Then make sure your own phone is on until they're in. The window between a delayed arrival and a settled guest is the one stretch where being reachable matters more than anything else you'll do that day. Keep it short and unexciting: one confirmation that they're inside, then leave them alone.

If a code fails while a guest is standing there, resist the urge to explain. Give them a way in — a backup code, the lockbox, whoever's nearest — and work out the cause afterwards. Nobody remembers a well-written explanation from a doorstep. Everybody remembers whether the door opened.

Recording who has access, and when it changed

Access records feel like paperwork until the day you need one. Then they're the only thing that answers the question.

Keep the log simple. For each property, note the stay dates, the access window, who held it — guest, cleaner, co-host — and the date the code changed. That's a few columns, and it takes a minute per stay. What it buys you is the ability to answer "who could get into this flat in September" without relying on your memory of a busy month.

Keep the credentials in one place you control rather than scattered across notes, chats and the back of a cupboard. LOCALSBNB stores access credentials locally at localsbnb.com, masks guest names, phone numbers and identity numbers automatically, and grants access by area — bookings, finance, availability and rates — so a cleaner sees the calendar without seeing your payouts.

The same principle applies to the actions around a stay. When a check-in, check-out, extension or room move is handled through LOCALSBNB, the software shows you the guest and the dates first, and nothing runs until you approve it. That's deliberate: these actions apply to overseas properties, while China properties stay read-only, and no door opens because a system decided it should. Smart locks are fine to use — the point is who presses the button, and that stays with you.

Review the log once a quarter. Every extra person with a code is a person whose access you'll need to retire, and the flat's list is shorter than most hosts expect.

FAQ

Should I use a smart lock or a physical key?

Both, if you can. A smart lock gives you rotation without a locksmith, and a physical key gives you a way in when a battery, a network or an app lets you down. The mistake isn't choosing one — it's having only one route to the door.

What if a guest shares the code with someone else?

Assume it can happen and design around it rather than policing it. One code per stay and a rotation on departure mean a shared code expires on its own. If it matters during the stay, meet the extra person or issue them separate entry.

Do I need to keep an access log for a single flat?

Yes, and it takes less time than you'd think. Even one property has guests, cleaners and co-hosts coming and going. A one-line entry per stay means the question "who had a code in June" has an answer instead of a shrug.

Access takes the least effort of anything in hosting, and causes the most damage when it fails. Send three things early, keep one code per stay, hold a backup that doesn't rely on a phone, and write down what you changed. Do that, and the front door stops being the one thing you can't fix from a message. Hosts who run access alongside their bookings at localsbnb.com keep the stay, the window and the record in one place, so the next handover is a check rather than a scramble.

---

This article is general guidance for hosts and isn't legal, tax or platform policy advice. Access routines, local rules and platform terms differ by place and change over time; check the current terms of each platform you use and the requirements that apply where the property sits.