Your Guests Don't Read the Booking Confirmation

Most short-term rental hosts learn this the hard way. You write a careful booking confirmation. Check-in code, wifi network, parking instructions, house rules, guidebook link, checkout time. You send it.

Three days before check-in, a guest emails asking where they can park. Two hours after they arrive, someone texts for the wifi password. Checkout morning: "What time do we need to be out?"

Everything they asked was in the confirmation. The problem is timing. Guests absorb information when they need it, not when it lands in their inbox three weeks early. Fixing the inbox problem means showing the right information at the right moment, not writing a more detailed email at booking.

Why front-loading doesn't work

The booking confirmation arrives weeks or months before the stay. At that point, guests are not thinking about how to get from the airport to your property. They're thinking about whether to book a dinner reservation. The confirmation gets skimmed for the dates and the total, then archived.

By the time they're driving to your property with three kids in the back seat, they're not opening an email from two months ago. They're texting you.

The same overload shows up in message sequences. Many hosts send a welcome at booking, a pre-arrival reminder at 72 hours, and a check-in message on arrival day. Each has everything. Guests start filtering them out. The message with the door code gets opened for the code, and the parking and wifi get skimmed. The wifi password question still shows up that night.

What guests need, stage by stage

Think about what a guest needs at each point in their stay, not at booking.

More than a day out

At this stage, guests mostly want reassurance and context. General arrival info: neighborhood, what check-in looks like, what to expect. If you have a pool heater or early check-in available to purchase, this window is the right time to offer it, before they arrive and assume the pool is already warm.

The door code does not belong here. They won't remember it in two weeks, and sending it early doesn't reduce calls on check-in day.

The day of check-in

Now they need navigation. The specific address. Parking instructions. Which entrance to use. A map link they can tap, not a paragraph of written directions. This is also when the door code should become visible, in a link they can open without hunting through a long email thread.

Active stay

This is when most self-serve information becomes relevant. Door and gate codes. Wifi network and password. How to operate the locks. House instructions. Pool access. Checkout time. In this window, guests want a short, clear screen they can reach in seconds. Not a PDF, not a thread of six messages they have to scroll.

Late in the stay and checkout

By now guests have their codes and wifi. What comes up is mostly checkout questions, requests to stay a little later, or problems to report. A contact form that routes to your ops team is more useful here than a phone number they'll text, because it captures context and creates a record. The late-checkout upsell belongs in this window too: an offer surfaced inside the final 24 hours of the stay converts better than one sent at booking, when the guest hasn't yet spent four days in the property.

Post-checkout

The address and codes are gone. What works here is a first-party review prompt. Guests who get a clean, simple "how was your stay?" right after checkout respond at a much higher rate than they do to a follow-up email two days later. A brief "plan your next visit" link closes the loop on the rebooking conversation.

Building the staged view

A few operators build this manually with a Notion page or a custom URL that they update per reservation. That works, but it doesn't update what the guest sees based on where they are in their stay. Codes are either always visible or always hidden.

The cleaner approach is a portal that knows the reservation timeline. Same link for every guest. Different content depending on whether they're two days out, checked in, or past checkout. The codes never appear before the check-in window. The address comes visible in the final day before arrival. The review prompt replaces the arrival information after checkout.

Most property management systems don't do this natively. Their guest-facing links are static pages or redirects into the platform's own interface. Building a staged portal usually means either writing something custom or using a tool that sits on top of your PMS and uses the reservation data you already have.

Pomello's guest portal handles this without custom code: four lifecycle stages, with codes gated to the active stay window, upsells at the right points, and a contact form that routes to your comms team. If you're running on Hostfully, the reservation data is already there.

Measuring whether it's working

The most direct signal is your inbound message volume for routine questions. Pull the messages your team receives and tag the ones that are information requests: wifi, codes, parking, checkout time, pool access. Measure what fraction they are of your total inbox.

For most operators running without a portal, that category is 30 to 40% of messages. With a working portal, it drops under 10%. The remaining messages are things that need a human: something broken, a noise complaint, a special request. Those you want. The routine questions you don't.

If the volume isn't dropping, the issue is usually discoverability. Guests aren't finding the portal link, or it's buried in a long email they don't open. The link needs to be in the first message, prominent, with a single clear call to action. "Everything you need for your stay, in one place" is enough.

What comes next

The inbound reduction is a cost story and a quality story. When the team isn't fielding the same five questions every stay, they have more capacity for things that require judgment: arranging a contractor quickly, handling a noise complaint thoughtfully, following up on feedback worth acting on before checkout.

Scheduled guest messages handle the proactive outreach side of this. A portal handles the reactive side. Together they cover most of the inbox, and what's left is the work that requires a person.

The reviews that call out "so easy to check in" and "everything was clearly explained" don't come from longer confirmation emails. They come from guests finding what they needed, right when they needed it.