From Booking to Post-Stay — Email Notification Design

Introduction

Build a booking system and the number of email types just keeps growing. Booking confirmation, payment complete, cancellation, error alerts — before we knew it we had fifteen of them.

This article covers how we organized them and how we decided who gets what, and when. Not sending too much is part of the design too.

Not Using the Reservation System's Built-In Email

Why We Built Our Own Instead

The reservation management system comes with a feature that automatically sends booking confirmation emails. It works out of the box with nothing but configuration, and we still built our own. There were three reasons.

The first one was the real problem. If someone books through the property's official site and then gets an email from a completely different domain, they start wondering whether the site was a scam.

So we disabled all automatic sending on the reservation system side and moved to sending from our own email delivery service.

OTA Bookings Are an Exception

Bookings that come through an OTA are different, though. Depending on the booking site, you may not be given the guest's real email address, or direct marketing may be prohibited under their terms.

So for OTA bookings, we decided to use the reservation system's own notification feature as-is. It was a deliberate choice not to unify everything under our own system.

Separating Guest Emails from Operator Emails

Five for Guests

We narrowed the emails guests receive down to five: booking confirmation, payment complete, cancellation complete, a copy of their inquiry, and a variant of the booking confirmation (for when issuing the dedicated page failed).

Choosing Not to Send Reminders

You may have noticed that this list has no "reminder the day before check-in" and no "thank you for staying" email. That was intentional.

If there's a place where the necessary information is always available, you can cut down on how often you notify.

Ten for Operators

Operator emails, on the other hand, we built out in detail: booking confirmed, dedicated page issuance failed, mismatch with the reservation management system, automatic charge failed, daily report, booking change detected, cancellation notice, inquiry notice, and more.

Operator emails follow a set of shared rules.

• Put [Action Required] in the subject line — only for things a human has to act on. Notifications you just glance at don't get it
• Spell out what to actually do — not "an error occurred", but "check this booking on the reservation management system screen"
• Don't set a reply-to address — so an accidental reply never reaches the guest

That last one is unglamorous but important. Inquiry notices are the one exception: we set the guest's address as the reply-to so operators can respond directly.

Building the Content of the Emails

One Unified Design

If the booking confirmation and the inquiry copy look different, they don't read as coming from the same property. So we built one shared outer frame for every email and swap only the contents.

The logo is embedded as an attachment to the email. If you load it from an external URL, plenty of email clients block the image and you end up with a bare, unwelcoming email.

For environments that can't display HTML email, we always include a plain-text version too.

Four Language Versions

Guest emails go out in the language chosen at booking. We keep a separate version of the text for each language and only inject the parts that change, like dates and amounts.

There's one important rule here: numbers such as amounts, percentages, and day counts are never written directly into the translated text.

It's a safeguard against the kind of accident where you change the cancellation policy and the old numbers survive in the English version alone.

Keeping the Text in a Separate Place

We manage email text separately from the site's own translation files. Emails can be sent from scheduled jobs or webhooks, and in those situations you can't assume the site's translation machinery is available.

The structure exists to avoid a situation where "the payment succeeded, but the text couldn't be loaded so the email never went out".

Previewable from the Admin Screen

Operators can see what all fifteen emails look like from the admin screen. But they can't edit them.

Email text includes amounts and cancellation terms. If it were casually editable from the admin screen, there's a real risk of it being rewritten into something legally problematic. The line we drew: you can review, but changes go through development.

Wrapping Up

Three things anchored the email notification design.

1. Send from our own system — control the sender and the timing ourselves so it arrives as an email from the property
2. Don't send too much — with the portal in place, skip the reminders and the post-stay emails
3. Don't bake numbers into the text — injecting them from configuration prevents inconsistencies across languages

Duplicate prevention and safeguards against missed sends are covered in "Never Send It Twice".