Automating Check-In Instructions for Direct Bookings (Without Sending Them Twice)

The first direct booking I ever took was from a guest who had already stayed with me twice through a platform. She emailed, I sent an invoice, she paid, and I wrote the dates on the calendar feeling like I’d finally graduated.

She called me at 4:40 on a Friday from my own driveway, asking whether she was in the right place, because nobody had told her how to get in.

I had check-in automation. I had spent two seasons building it. Four scheduled messages, timed off the reservation, tested on dozens of arrivals, and every single one of them lived inside the platform’s message scheduler — which had never heard of her, because her booking existed only in my email and on a calendar block. The automation hadn’t failed. It had been asked about a reservation that, as far as it was concerned, did not exist.

So I did the obvious thing and added a tool outside the platform to send arrival details for every stay. Which is how, eleven days later, a platform guest received the door code twice: once from my new tool and once from the scheduled message I had forgotten was still armed. The two copies did not say the same number, because I’d rotated the code in one place.

Those two incidents look like opposite problems. They are the same problem.

---

Every Scheduler Only Knows Its Own Bookings

This is the structural fact underneath the whole topic, and it’s worth saying plainly because almost no product page will say it for you.

A platform’s message scheduler is a feature of that platform’s inbox. It fires off reservations that platform created, into the thread that platform owns, to a guest whose contact details that platform holds. It is very good at that and completely blind outside it. The same is true one level up: a channel manager’s messaging rules fire off the bookings it has ingested through its connections — so a direct booking you typed in by hand may or may not be inside its world, and “may or may not” is the part that burns you on a Friday afternoon.

Once you take bookings from more than one place, you therefore have a coverage question and an overlap question at the same time:

• Coverage: is there any reservation that no sender is responsible for? (That’s my guest in the driveway.)
• Overlap: is there any reservation that more than one sender is responsible for? (That’s the double door code.)

Hosts almost always discover these in that order, and the fix for the first creates the second. Adding an outside sender doesn’t disarm the platform’s scheduler — nothing disarms it except you, going into each listing and switching it off. For a while you have both, and both are confident.

The question that resolves both failures isn’t “which tool sends the best messages.” It’s which single thing owns the send for a given reservation — and whether you can answer that for every reservation on your calendar without going to look.

---

The Four Arrangements, and What Each One Costs

There are only a handful of ways to arrange this. I’ve run three of the four, and the fourth is the one I’d now pick first.

Arrangement	Does a direct guest get instructions?	Can a guest get two copies?	What happens when a detail changes	Where the guest’s reply lands
Platform schedulers only	No	No	You edit each platform separately	In the right thread
Platform schedulers + a separate sender for direct bookings	Yes	Only if a direct guest also booked a platform stay	You now maintain two message sets	Two places, split by booking source
Platform schedulers + an outside sender for everything	Yes	Yes, routinely	Whichever one you forget keeps saying the old thing	Both, and you watch both
One sender for every reservation, platform schedulers off	Yes	No	One edit, every channel	One place you chose on purpose

Row three is the trap, and it’s the row most hosts land in by accident, because it’s what “I added a tool” looks like before you do the switching-off work.

Row two is defensible and it’s where I sat for a season. Its real cost isn’t duplication, it’s divergence: two message sets drift, and the drift is invisible because each one looks fine on its own. The gate code I changed in the direct-booking set stayed wrong in the platform set until a guest told me. If you’re going to run row two, treat the two sets as one document with two destinations — the same discipline I describe for keeping one message set across both platforms, extended one channel further.

Row four is the arrangement worth building toward: one place that holds every reservation regardless of where it came from, and one sender that works off that. This is the specific reason I ended up running my stays through Outkeepr rather than out of a platform inbox — a direct booking I enter by hand is the same kind of object as a synced one, so “the guest gets arrival details” is a property of the reservation rather than a favour the originating platform does for me.

---

Turning the Platform Scheduler Off Is the Step People Skip

I want to be unhelpfully specific here, because “disable your scheduled messages” sounds like one click and is not.

When I went looking for the message that had double-sent, I found armed schedules in four places I’d forgotten about:

• Per listing, not per account. I had switched them off on the listing I was testing with and nowhere else. Two listings later, the old set was still running.
• Attached to a saved template. Disabling the template’s schedule and deleting the template are different actions, and the one I did was neither.
• In a co-host’s account. Scheduled messages set up by someone with co-host access fire from their rules, and they do not appear where you look for yours.
• As a channel manager rule. Anything upstream that touches messaging has its own copy of the decision, and it does not know you’ve changed your mind downstream.

The audit that actually works takes about twenty minutes and is not a settings sweep. Create a test reservation on each listing on each channel you sell through, with a date far enough out that a pre-arrival message will fire, and then count the messages the test guest receives. Count, not inspect. The settings screen tells you what you think is true; the inbox tells you what happens. I found the fourth sender this way after being certain I’d found all of them.

One caution worth stating. Platforms have their own rules about what has to stay in their thread, particularly anything that looks like steering a guest off-platform. Sending arrival logistics to a guest you booked through a platform is ordinary hosting, and plenty of hosts do it from outside tools — but keep the booking conversation in the platform’s thread and read your current platform terms rather than my summary of them. The goal is one sender for the arrival instruction, not an empty platform thread.

---

A Direct Guest Has No Thread

Here’s what makes direct bookings genuinely different, as opposed to just differently plumbed.

A platform guest has a container. There is a thread, it’s attached to the reservation, both parties can scroll it, and the platform will notify them. A direct guest has none of that. They have whatever email address they typed and whatever phone number they gave you, and they have your invoice. There’s no shared surface that both of you are looking at.

So for direct bookings, “automate check-in instructions” quietly contains two jobs that platform automation handles for you by accident: delivering the message and giving the guest somewhere to find it again. Hosts solve the first with email or SMS and then skip the second, and the second is where the arrival-day calls come from. Email is a terrible archive for a detail that changes. The message is a snapshot, it sinks under four other emails, and it cannot be corrected — a point I made at length about per-reservation arrival pages and which applies with double force when there’s no thread to fall back on.

What works is sending a short message whose payload is a link, and putting the facts on the other side of the link. That way the delivery is one-shot and the content is live. For my direct bookings, the message is three lines and a URL; the page behind it is generated from the reservation in Outkeepr, so it shows the right door code on the right dates to whoever opens it — including the guest’s partner, who never had the email in the first place.

---

One Set of Facts, Rendered Many Times

The duplicate-code incident wasn’t really a scheduling bug. It was a copy bug.

If the door code appears as typed text in a platform scheduled message, in a direct-booking email template, and on a one-page PDF you made in March, you don’t have one fact with three deliveries. You have three facts that happen to agree today. Rotating the code is now a three-step job, and the step you skip is the one a guest reads.

The fix is to stop writing the value and start referencing it. Whatever holds your reservations should hold the property’s arrival facts too — code, gate, parking, wifi, trash day — and every outbound thing should render from those rather than contain a copy. Then a rotation is one edit with no distribution problem, because there is nothing to distribute. That’s the shape I’d check a tool for before anything else: in Outkeepr the arrival details belong to the property and the stay rather than to a message I typed, so changing a code is an edit in one field and not a hunt through four templates and a PDF.

This is the discipline that makes the rest of it safe:

• Write the instruction once per property, not once per channel. The register can differ between a platform guest and a direct guest; the facts cannot.
• Keep the facts out of the prose. “The code is on your arrival page” ages better than a six-digit number in a paragraph, and it means a stale message is useless rather than wrong.
• Make the trigger a reservation state, not a date you typed. A message scheduled for “two days before” against a reservation that got extended should move with it.
• Decide the escalation rule before you automate, because an automated send that a guest replies to with a problem is only an improvement if the reply reaches a human.

The structure of the message itself is a separate craft, and I won’t redo it here — how to write check-in instructions guests actually read covers the ordering and formatting, and it’s worth getting right before you wire it to anything, because automation distributes whatever quality you already had.

---

The Reply Is the Part That Surprises You

Move the send outside the platform and you have moved the conversation outside the platform, whether or not you meant to.

A guest who gets a text with their arrival details replies to the text. A guest who gets an email replies to the email. Neither reply appears in the platform thread you’ve been checking for two years, and both are now your responsibility to watch at 9 PM. I added a fourth place to look and it took me a month to notice, mostly because the replies were short and polite and not urgent — right up until one of them was.

So the sender decision and the inbox decision are one decision. Whatever owns the send has to be somewhere you’ll see the answer, or you’ve traded a missing message for a missing reply, which is worse because the guest knows they wrote to you. I keep the arrival sends and the guest replies in the same place in Outkeepr precisely so there isn’t a channel whose answers land somewhere I’m not looking — and if you’re running more inboxes than that, the triage system in handling guest inquiries across platforms is the thing to build before you add another sender.

---

A Setup You Can Do This Week

In the order I’d do it again, because the order matters — switching off before you’ve switched on produces a guest in a driveway.

1. List every sender you currently have. Each platform’s scheduler, each listing separately, anything your channel manager does, anything a co-host set up, and every template you’ve ever saved. Write them down. You will find one you forgot.
2. Pick the one thing that will own arrival sends for every reservation, including the ones you type in by hand. The test for a candidate is whether a direct booking is a first-class reservation in it or a note on a calendar block.
3. Put the property’s arrival facts in that one place, and strip the literal values out of every message body you keep.
4. Build the sends there and test them against a real reservation on a real date, as a guest, on a device that isn’t yours.
5. Now disarm the others, one listing at a time, and re-run the count-the-messages test on each channel. Your new guest should receive exactly one of everything.
6. Confirm you can see the replies from the channels you’ve started sending on, before you need to.
7. Run one change through it. Extend a test reservation by a night, rotate a code, swap a parking spot. Watch whether the guest-facing instruction follows. If it doesn’t, you’ve built a faster way to send the wrong thing.

Step seven is the only one that distinguishes a real setup from a demo. Every arrangement in the table above looks identical on a booking that never changes.

---

What This Costs to Run

Two things are worth pricing separately, because they get argued about as one.

The sending is cheap or free almost everywhere — platform schedulers cost nothing, and email or SMS for a handful of arrivals a month is not a line item worth defending. If the only thing you need is “fire this text two days before,” you can have that today without buying anything, and for a single listing on a single channel that genuinely is the right answer.

What you pay for is the single source of truth underneath it — one place where a direct booking and a synced booking are the same kind of object, where the door code is a field rather than a string in four templates, and where a reservation change propagates to the thing the guest reads. Outkeepr is $5 per property per month plus 0.5% per booking, with a 14-day trial, and it sits alongside whatever channel manager or PMS you already run.

Use the trial on the change test rather than the setup. Setup looks good everywhere. Enter one direct booking by hand, let its arrival details go out, then change the dates and watch what the guest sees.

---

The Short Version

1. Every scheduler only knows its own bookings. That single fact causes both the missing message and the duplicate one.
2. Adding a sender does not remove a sender. The fix for no-coverage creates overlap unless you do the disarming as a deliberate step.
3. Answer one question per reservation: what owns the send? If you can’t answer it without looking, you don’t have a system.
4. Scheduled messages hide per listing, inside saved templates, in a co-host’s account, and in channel manager rules. Find them by counting what a test guest receives, not by reading settings screens.
5. A direct guest has no thread, so you owe them both a delivery and somewhere to look it up again. A link to a live page does both; an email does one.
6. Reference facts, don’t copy them. Three templates containing the same door code are three facts that agree until the day they don’t.
7. The sender decision is the inbox decision. Send from a channel and you’ll receive on it.
8. Test with a change, not a booking. Extensions, rotations and reassignments are where every arrangement reveals itself.

What I’d tell myself on that Friday: the problem was never that direct bookings are harder to automate. It was that I’d built the automation inside something that could only ever see two-thirds of my business, and then measured it on the two-thirds it could see.

If you’re taking bookings from more than one place and your arrival instructions live in more than one, download Outkeepr and put a direct booking in next to a synced one — reservations from every channel, the arrival details each guest actually sees, and the replies that come back all sitting in the same place, so “who told this guest how to get in” is a question with one answer.