Designing the Post-Booking Experience — a Guest-Only Portal

Introduction

The moment a booking goes through, contact with the guest tends to go quiet. It's not unusual for the next message to arrive the day before check-in. In the meantime, the guest is left wondering: did the booking actually go through? How do I even get in?

This article walks through the design of a guest-only portal that covers everything from the moment of booking to the end of the stay. At a property with self check-in, this is what makes or breaks the quality of the experience.

Don't Make Them Create an Account

The Sign-Up Wall

When you hear "my page", you probably picture a screen where you log in with an ID and password. For a lodging booking, though, that's a serious obstacle.

Nobody is going to create and memorize a password for a place they might stay at once a year. And if guests can't log in and start emailing you about it, the whole point of unstaffed operation starts to evaporate.

So we issue an unguessable, booking-specific URL and let only the people who know it get in. The URL itself acts as the key.

The full safety design is covered in "Safe with a Single URL", but the three essentials are: the URL can't be guessed, it has a validity window, and it can be revoked.

The URL Goes in Both the Email and the Booking System

We don't just put the issued URL in the confirmation email — we also record it on the booking record in the reservation management system. That way, if the email ends up buried in a spam folder, the operator can look it up from the booking data and resend it.

Opening Up Over Time

Revealing Information in Stages

The portal is accessible from the moment the booking is made, but not everything is visible right away. As check-in gets closer, more of the content appears.

Holding the access codes back until the day before is a security decision. If someone booked six months ago and the codes had been sitting on their screen the whole time, a leaked URL during that window would be a much bigger problem.

Not "Hidden" — Simply Never Loaded

The key point here is that information that isn't due to be shown yet isn't hidden on the screen; it's never read out of the database in the first place.

If you only hide things visually, anyone who inspects the page contents can find the access codes. If it was never loaded, there's nothing to find, no matter where you look.

Emergency Contacts Are Always Visible

The one exception to staged disclosure is emergency contacts. The management company's phone number and the public emergency numbers are always shown, even during the "getting ready" period.

Safety-related information shouldn't be hidden just because "it isn't time yet". It's a good example of why every rule deserves a look at where the exceptions belong.

What Guests Can Do in the Portal

Everything Needed for the Stay, in One Place

The portal gathers up all the information a guest needs for their stay.

We deliberately left payment status out of the portal. For anything involving amounts of money, we decided email is the surer way to deliver it — it also leaves a record.

Offering Self-Cancellation

If cancellations come in by phone or email, someone on the operations side has to handle each one. So within the window where no cancellation fee applies, we let guests do it themselves.

Before the cancellation goes through, though, we ask them to confirm the terms and enter their email address. If anyone with the URL could cancel a booking, that leaves room for mischief. Unless the address matches the one used at booking, the process doesn't continue.

Note that this feature isn't shown for bookings made through an OTA, since those have to be cancelled according to the OTA's own terms.

The Order of Cancellation Matters Too

Cancellation runs in this order.

First we cancel in the reservation management system, and if that fails we abort the whole thing. Next comes cleanup on the payment side (deleting the saved card, for example), then updating our own database, and finally revoking the URL and sending the notification email.

Outside in, biggest impact first. If we updated our own database first and the cancellation in the reservation management system then failed, we'd end up in the worst possible state: cancelled on our side, still booked in reality.

Wrapping Up

Three principles anchored the design of the guest-only portal.

1. Don't make them create an account — one dedicated URL does everything, with no login wall
2. Open up over time — access codes aren't even loaded until the day before, but emergency contacts are always visible
3. Cancel from the outside in — reservation management system first, and abort everything if it fails