The Arrival Message: Writing Door Instructions Guests Actually Follow

Ask any short-term rental operator where their support calls come from and the answer is rarely the lock, the plumbing or the Wi-Fi. It’s the arrival moment: a guest standing at an unfamiliar door at 11 PM, a phone at 4% battery, a message thread that says “the keypad is on the left” — and no context for what “left” means on this particular street.

The uncomfortable truth is that most door-access support calls are writing problems. The hardware worked; the instructions didn’t. This article is about fixing the writing — the arrival message that gets a guest through the door on the first attempt, and the failure modes it needs to pre-empt.

Why arrival instructions fail

Five failure patterns account for nearly every arrival disaster, and each one is a specific writing mistake:

The five ways arrival notes break

  • 1. The voice of the owner. “It’s the lock with the keypad — you’ll see it.” The owner knows the door; the guest has never been to this building. Every instruction describes something the reader cannot yet recognize.
  • 2. Directions through the author’s eyes. “Left of the door” means nothing without a stated viewpoint. Guests arriving from a lift, a car and the street all see different “lefts.”
  • 3. One giant paragraph. The arrival message arrives in a booking-platform chat, gets scrolled, and by the time the guest needs step three, the phone is showing the weather. Instructions must survive the conditions they’re read in.
  • 4. Missing failure branch. What should the guest do if the code doesn’t work? If the note doesn’t say, the guest’s options are: stand there, call, or guess. Two of those three are bad.
  • 5. Buried timing. When does the access actually begin? A code that activates at 3 PM and a guest who arrives at 2:45 produce a support call unless the note says so — in the note, not somewhere in the booking terms.

The structure that works

An arrival message that reliably works has six parts, in this order. It takes ten minutes to write once, gets saved, and is reused for every booking with only the numbers changed:

  1. The address line — exactly as it appears on the building. No nicknames, no “the one next to the coffee place.” A guest who can’t match the note to the building is lost before they start.
  2. The approach in one sentence. From the most common arrival point (the car park, the metro exit, the main street) to the building entrance — one line, one landmark.
  3. The door identification. Which door: the black one with the keypad, the one next to the buzzer panel. Guests count doors when they’re anxious; give them the number.
  4. The method, in numbered micro-steps. “1. Touch the keypad to wake it. 2. Enter 4-7-2-9-1 and press the tick. 3. The lock clicks and the handle turns.” Three steps, three lines, no jargon — and never more than five steps total, because the format itself is part of the design.
  5. The failure branch. “If the keypad doesn’t light up, press the bottom-left button first” or “If the door doesn’t open, call this number and we’ll be there in five minutes.” The branch is what turns a bad night into a minor moment.
  6. The timing line, in bold. When access starts, when it ends, and what to do about early arrival — “Access is active from 3 PM. If you arrive earlier, message me and we’ll see what we can do.” One sentence, no ambiguity.
Guest arrival access planning for a rental property entry
Every arrival failure has two possible causes: the lock, or the note. The note is fixable in ten minutes and is the cause far more often.

The delivery channel matters as much as the text

A perfect message in the wrong place still fails. Three rules keep the message where the guest will actually encounter it:

  • Send it twice: at booking confirmation and 24 hours before arrival. The first send is for planning; the second is for using. Guests read the second one, so make sure it’s complete on its own — never “as I mentioned earlier.”
  • Put the operational part in the app the guest is already using. Booking platform messages, the guest’s email, a printed card inside the door — every channel except one the guest hasn’t visited yet. A house guide inside the property is welcome material, not arrival material; the guest can’t read it until they’re through the door.
  • Keep a copy in plain text, no formatting. Beautiful HTML newsletters look wonderful until they arrive in a platform chat that strips the styling, leaving a jumble of tags. Plain text with line breaks survives every channel.

The test that catches everything: hand the message to someone who has never seen the property — a friend, a colleague, anyone — and ask them to read it and tell you where they’d go and what they’d do. Every ambiguity that survives ten seconds in a stranger’s hands is a support call that just got prevented.

What the hardware side should provide to support the message

Good instructions work best on hardware that keeps its promises, and three hardware facts make arrival writing materially easier:

  1. Feedback the guest can perceive. A lock that confirms its state — a light, a click, a spoken prompt in the language of the household — reduces the “did it work?” uncertainty that turns instructions into doubt. Our deadbolt models document voice prompts in four languages; the A20 documents a nine-language interface. When the reader says the door is open, the note doesn’t need to.
  2. A simple primary method. The fewer steps the method has, the shorter the note. This is a practical argument for codes and cards over multi-step app flows as a guest method — the instruction is one line instead of a paragraph.
  3. Temporary credentials with a real start and end. Where the platform supports expiring access — DDZ17’s documented temporary password support is an example — the timing line in the note is something the property can state confidently, because the lock is doing the enforcing.

For operators: the arrival note is a system asset

Properties that run six units and properties that run six hundred share the same insight: the arrival message is a piece of infrastructure. It should be templated, versioned, proofread once, and maintained like any other operational document — because it’s also the very first thing a guest experiences from the business. A property whose arrival note works reads as professional before the guest has seen the apartment. One whose note fails is judged before the door opens — and usually in a review, three days later, with screenshots.

Common questions

Should I send check-in instructions as a video?

As a supplement, yes — a 20-second clip of the actual door can be helpful for unusual locks. As the primary, no: videos need bandwidth, get watched at the worst moment, and age badly when the lock’s behavior changes. Text first, video as optional support, and only if the property keeps it current.

What if the property has multiple different locks?

Keep a map — unit, lock model, primary method, backup path — and make sure each arrival note is generated from the correct row. Multiple lock types on one property is a normal outcome of phased upgrades; the arrival message is where the difference either stays invisible to the guest or becomes their problem.

How do I handle a guest who doesn’t speak the language of the note?

Machine translation is fine for directions and codes, so send the note in the guest’s booking language where the platform supports it. For the door itself, prefer methods that skip language entirely — codes, cards, a fingerprint — and check the model’s documented interface languages if the reader displays anything. Our multilingual entry article covers the household version of the same principle.

Equipping short-stay properties with guest-ready entries?

Tell us your operating model and unit types. CaremLock supplies documented room-door and residential ranges with temporary access, multi-language prompts and simple guest methods — the hardware side of an arrival that works on the first attempt.

Request a Quote

Or review the DDZ17 room-door model and contact the team.