The guest who could not get into my condo had every piece of information he needed. He just wasn’t the one standing at the door.
He’d booked the place for his family, flown out Thursday morning, and his wife drove up with the kids and the dog that afternoon while he was still in the air. I had sent him the gate code, the elevator fob instructions, the unit door code and the parking spot number — three days earlier, in the Airbnb thread, like I always did. All of it correct. All of it on a phone at 35,000 feet.
She stood at the gate for twenty minutes. She tried the callbox. Then she found my number on the listing she wasn’t logged into, called, and asked me to read her a code I had typed out perfectly three days before.
That’s not a check-in failure. That’s a container failure. The information existed; it just lived somewhere only one person could reach, in a form nobody could forward, buried under a week of other messages. And the fix isn’t a better message. It’s giving the arrival its own object: one link, per reservation, that holds everything about getting in.
A Thread Is a Log, Not a Document
Hosts default to the platform thread because that’s where the guest is, and that instinct is right — the thread is where arrival details should arrive. The mistake is treating the thread as where they should live.
Think about what a message thread actually is. It’s append-only. The newest thing is on top, which means the most important thing sinks. It belongs to exactly one account. It can’t be corrected after the fact — you can only send a second message contradicting the first and hope the guest reads down. And it’s interleaved with everything else you’ve said to that person: the “looking forward to hosting you!”, the question about the crib, the four-message negotiation about the dog.
Here’s what happens to a perfectly good arrival message inside that container:
- It sinks. Sent at booking, three weeks out, it’s below a dozen later messages by arrival day.
- It can’t be shared. The second car, the spouse on a later flight, the friend arriving first — none of them are in the thread.
- It goes stale silently. Your HOA rotates the gate code in March. The message from February still says 4471, and it will say 4471 forever.
- It fragments. Gate code in one message, Wi-Fi in another, parking in a third. The guest is now a detective.
- It’s unreadable in the dark. A tired person in a car with a toddler cannot skim nine paragraphs for six digits.
The container test: can the person actually standing at your door — who may not be the person who booked — get the code in under ten seconds, on the first screen, without scrolling, without a login, and without calling you? If not, the problem is where the information lives, not how it’s written.
The writing still matters enormously, and I’ve put my working version of the actual words in the check-in instructions guide. This post is about the thing the words sit in.
What a Guest Pass Is, Precisely
A digital guest pass is one web page, at one URL, generated for one reservation, that answers every “how do I get in” question for that specific stay. Not a house manual. Not a listing-level PDF. One stay, one link.
The distinction I’d hold onto: a pass is operative information — things the guest does — and nothing else. The house manual is reference information, things the guest looks up once they’re inside. Mixing them is the single most common way a pass stops working, because it pushes the codes below the fold.
Operative, in rough priority order:
| Rank | On the pass | Why it earns the space |
|---|---|---|
| 1 | Address with a map pin that actually works | Rural addresses resolve wrong; the pin is the truth |
| 2 | Every barrier code in order: gate, lobby, garage, unit door | This is the whole reason the page exists |
| 3 | Parking: which spot, which pass, what gets towed | The most expensive mistake a guest can make |
| 4 | Check-in window and whether the place is ready now | Prevents the arrive-during-cleaning collision |
| 5 | Wi-Fi name and password, copyable | Asked on 100% of stays; trivial to pre-answer |
| 6 | Checkout time and the two or three checkout asks | Here on purpose — it’s the other operative moment |
| 7 | One human contact, and who answers if that fails | The escape hatch has to be on the page |
What I keep off it: the restaurant list, the beach recommendations, the full appliance manual, the history of the house. Those go inside — a binder, a separate page, a link at the bottom. The appliance manual is not what someone needs while standing in the rain.
And one hard rule about barriers: count them before you design the page. A condo with a community gate, a lobby callbox, an elevator fob and a unit deadbolt is a four-credential arrival, and a pass that lists one of them is a pass that fails three-quarters of the way through. If that’s your situation, the gated community entry guide walks through counting your doors properly before you start writing anything.
The Four Ways a Pass Fails
I’ve built this three times, badly, before it worked. Every failure was one of four things.
1. Staleness
This is the big one, and it’s fatal in a specific way: a stale pass is worse than no pass, because the guest trusts it. A guest with no information calls you. A guest with a wrong gate code punches it in three times, gets locked out of the keypad, and then calls you — from a worse position.
Any pass you build by hand is a snapshot, and snapshots rot. The Google Doc with the codes in it, the PDF you attach, the saved message template — all of them hold whatever was true the day you wrote them.
The rule that actually holds: nothing operative on the pass may be typed by a human into the pass. Codes, dates, times and spot numbers have to be read from the system that owns them — the reservation for dates and names, the lock for the current code, the property record for the gate. If a detail changes in one place, every pass that references it is already correct.
That’s the specific reason I stopped maintaining arrival documents per property and let the reservation generate the answer instead. Outkeepr reads the booking off Airbnb or VRBO and answers from that property’s own arrival details, so when I change a gate code once, the next guest who asks gets the new one — I’m not hunting through five documents hoping I caught them all. The thing I was actually buying was the absence of a stale copy.
2. No expiry
A pass with a permanent URL is a credential. If it contains live door codes and it works forever, you’ve published your keypad to anyone who ever stayed — and to whoever they forwarded it to.
A pass should stop working. Mine go dark a day after checkout, which is late enough to cover a delayed departure and early enough that last summer’s guests can’t look up this summer’s code. If your pass can’t expire, the codes on it must — which is really the same problem seen from the lock’s side, and the harder half of it is revocation rather than issuance. I went through that at length in the key exchange guide; the short version is that a code whose end date is “never” is not automated access, it’s a published secret.
3. No transfer
This is the one that got me, in the story at the top. Arrival information sent to a platform account reaches one human. Arrival information at a URL reaches whoever that human sends it to.
So design for forwarding deliberately: no login, no app install, no “sign in to view.” A plain URL the booker can paste into their family group chat. It feels like a security downgrade and mostly isn’t — the link is unguessable, scoped to one stay, and dies after checkout, which is a tighter grant than the permanent code most hosts are quietly running today.
4. No signal
The place your pass gets opened is the place with the worst connectivity on the whole property: a gate at the bottom of a hill, an underground garage, a rural driveway, a lobby with concrete walls. Design for that.
What that means in practice: one page, no JavaScript required to see the codes, text not images, codes large and near the top, and the whole thing light enough to load on one bar. Then assume the guest screenshots it — most do — which is an argument for the codes being readable in a single screen capture, and another argument for the pass expiring, because a screenshot never does.
Three Ways Hosts Actually Do This
Nobody starts with a per-reservation pass. Here’s the honest ladder, with what each rung costs you.
| Thread message | Static page or PDF | Per-reservation pass | |
|---|---|---|---|
| Effort to start | None | An hour per property | A setup, once |
| Updates when a code changes | No | Only if you remember | Yes, by construction |
| Works for the spouse / second car | No | Yes | Yes |
| Expires after the stay | n/a | No | Yes |
| Readable at a gate on one bar | Poorly | Usually | Yes, if built for it |
| Can carry stay-specific details | Yes, by hand | No | Yes |
| Fails by | Sinking and fragmenting | Going stale | Nothing to send it |
The middle column is where most organized hosts land, and it’s a real improvement over the thread — it’s shareable and it’s structured. It just trades the sinking problem for the staleness problem, and staleness is the more dangerous of the two because it’s invisible until a guest is locked out.
The right column only works if something generates it from live data. Which is why the pass is not really a document project at all. It’s a question about whether your reservations, your property details and your turnover schedule live anywhere a computer can read them — or whether they live in your head and your threads.
The Pass Doesn’t Replace the Thread
One thing I got wrong on my second attempt: I moved everything to the link, and sent a message that said, essentially, “your arrival details are here.” That’s a regression, for two reasons.
The thread is the record. When a guest claims they never received check-in instructions — which happens, and sometimes honestly — the platform thread is the evidence, and a link whose contents changed since is weak evidence. And platforms are not neutral about external links; a bare URL with no context is exactly what their filters are built to catch, and a message that gets held or stripped is a message the guest never saw.
So: both. The operative codes go in the thread as plain text on arrival day, and the pass is the durable, forwardable, always-current version. Belt and braces, and they fail differently, which is the point.
Which also means the delivery has to happen without you, or you’ve just doubled your manual work. A message sent at booking and another on arrival day, both carrying the real codes for the real stay, is three or four minutes of phone work per reservation — trivial at one property, a daily chore at five. I’ve written up the full automation chain in automatic guest check-in; the part relevant here is that the thing which sends the message and the thing which generates the pass should be reading the same reservation, or they’ll eventually disagree with each other in front of a guest.
”Is It Ready Now?” Is Part of the Pass
The field hosts leave off, and the one guests most want: not the check-in time in the listing, but whether they can come in now.
A pass that says “check-in from 4 PM” is a policy. A pass that says “your home is ready” is information, and it’s only honest if something actually knows the turnover finished. Guess at it and you get the worst arrival in the catalogue — a guest who walks in on a cleaner mid-bathroom, holding a page from you that said the place was ready.
This is why I want cleaning and reservations in the same system rather than cleaning in a text thread with my cleaner. In Outkeepr the turnover and the stay are the same timeline, so “ready” is a recorded event rather than an assumption about a schedule — which is what makes it safe to put on a page a guest reads while driving. If your turnovers are coordinated over SMS, that signal doesn’t exist anywhere software can see it, and the honest move is to leave the field off the pass entirely rather than fill it with a hopeful guess.
Early arrivals are the same problem with a sharper edge. A guest who opens the pass at 11 AM and sees codes assumes the codes work now. Either the codes genuinely start when the property is genuinely ready, or the pass has to say plainly when they begin. I handle the asks themselves as a decision with a scripted answer rather than an automatic yes — the early check-in playbook has the scripts for both directions.
A Build Order That Finishes
Each step is useful on its own, which is the only reason this one ever gets done.
- Count the barriers at one property. Gate, lobby, garage, elevator, unit door, interior lockout. Write them in arrival order. Most hosts find more than they expected.
- Write the operative page for that property. One screen. Codes near the top. Nothing a guest merely looks up.
- Check it against the container test. Hand your phone to someone who has never been there. Ask them to find the door code. Time it.
- Make every code come from somewhere other than your typing. This is the step that converts a document into a system, and the one that prevents staleness.
- Give the link a death date. A day after checkout.
- Automate both deliveries. Overview at booking, operative codes in the thread on arrival day, pass link in both.
- Add the “ready now” field only if something real tells you. Otherwise leave it out.
- Count your interruptions for a month. Every “what’s the code?” message is a defect in the page, not a defect in the guest.
Step eight is the measurement that matters, and it’s humbling. The month I started counting, I had eleven code-and-Wi-Fi questions across three properties — on properties I’d have told you had excellent check-in instructions. Every one of them traced back to the container, not the content: the right answer, somewhere the person at the door couldn’t reach.
Routine questions getting answered without me is also what keeps the real exception visible. When Wi-Fi, parking and checkout time all resolve on their own, the message that says “the keypad is blinking red” is the only unread thing on my phone instead of the fifth, and I see it in minutes instead of at bedtime. That’s the part of Outkeepr I’d defend hardest — not that it answers, but that it leaves the things needing a decision in front of me.
What This Costs
If you build it yourself, the cost is in two places and neither is hosting. It’s the hour per property of writing the operative page honestly — every barrier, the parking, the thing about the third stair — and it’s the ongoing cost of keeping it true, which is the part that quietly fails. A page nobody updates is the staleness failure with extra steps.
If you’d rather the answers come out of your reservations, that’s a software line item. Outkeepr is $5 per property per month plus 0.5% per booking with a 14-day trial, and the shape worth noting is the per-property part: adding a fourth door is an incremental decision rather than a plan upgrade you have to sit down and think about. I mention the number because I won’t quote one for anything I haven’t checked, and because the comparison that matters isn’t against free — it’s against the cost of one locked-out arrival and the review that follows it.
The thing I’d price seriously, whichever way you go: a single blown check-in costs more than a year of any of this. Not in refunds, usually. In the review that mentions it, which sits on the listing long after the guest has forgotten the gate code.
Back at the Gate
That condo has the same gate, the same callbox and the same four credentials it had the afternoon my guest’s wife sat outside it. Nothing about the building got easier.
What changed is that the arrival stopped being a message I sent to one person. There’s a link now, scoped to the stay, that anyone in the family can open, that carries the current codes rather than February’s, and that stops working the day after they leave. The codes still go in the thread too, on arrival day, because the thread is the record.
If you only take one thing: your arrival information is probably fine. Ask instead where it lives, who can reach it, and what happens to it when the gate code changes. Those three questions found every real problem I had.
Outkeepr is built for exactly that gap — it reads your Airbnb and VRBO reservations, answers arrival questions from the property’s own details in the guest’s own thread, tracks the turnover so “ready” is a real signal instead of a guess, and surfaces the threads that actually need you. Download the app and set up one property; a single arrival cycle inside the 14-day trial is enough to see whether someone who isn’t the booker can get through your front door without calling you.
Ready to automate your vacation rental?
AI guest messaging, smart lock codes, cleaner scheduling, and more — starting at $5/mo per property.
Try Outkeepr Free