Booking Confirmation Email: How to Write One Customers Actually Read

A booking confirmation email should tell the customer whether their booking has been accepted, what they booked, when and where it takes place, and how to change or cancel it. Put those facts near the top with a recognisable sender and a subject such as "Booking confirmed: [service] on [date]". The customer should not need to phone to learn whether the reservation worked.

Use plain text or simple HTML, with both versions available if your system supports them. The guide to HTML email templates covers building the HTML version so it holds up in common email clients. If messages go missing, check the booking record and delivery trail before changing the wording. The message needs to be correct even when the email itself fails to arrive.

What a confirmation email is for

A confirmation records an accepted reservation. Receiving a request is different: if approval, payment or an availability check is outstanding, say "Booking request received" and explain what will happen next. A payment attempt alone does not prove that a slot was reserved.

The GOV.UK Service Manual guidance on transactional messages recommends telling people when an action has completed. This is guidance for government services, not a law governing booking emails. The practical point is to make the message match the actual event.

The first two lines: what, when, where

Begin with the selected service and its appointment time. The next line should identify the venue or say where to join online. Use the name that appeared at checkout rather than a database label. Put the booking reference underneath, where it helps staff find the record without hiding the appointment details.

Show the end time or duration as well as the start. For appointments in the UK, convert the stored appointment time into the local UK time on the date of the booking, showing BST or GMT as appropriate. The GOV.UK clock-change guidance explains the change between British Summer Time and Greenwich Mean Time. Do not simply apply today's offset to a future date.

Compare the received email with the booking record for an appointment before and after a clock change. Where the clocks repeat an hour, check that the system has resolved which occurrence was booked. Where they skip an hour in spring, check that a time that never happens, such as 01:30 on that Sunday, cannot be booked. If the displayed time is ambiguous, pause confirmations for affected slots and correct the time handling before sending them.

The information to include

Include the facts a customer needs to attend and enough information for staff to retrieve the booking.

• Status: Confirmed, pending or another accurate state.
• Service: The name selected by the customer.
• Appointment: Date, start, end or duration, and appropriate time zone.
• Location: Venue address or online joining details.
• Reference: An identifier staff can find.
• Payment: Amount paid or balance due, where relevant.
• Preparation: Instructions for this particular service.
• Changes: Management route and applicable conditions.
• Contact: A monitored reply or support route.

Payment wording must distinguish a deposit from full payment. Do not include full card details or unnecessary private information. The GOV.UK guidance on sending emails from a service advises against putting sensitive data in messages, while the ICO's data minimisation guidance says to limit personal data to what is necessary.

Use service-specific preparation text. An online consultation needs joining instructions; a workshop visit may need access information. Compare each field against the saved booking across different service types. If a payment or instruction mapping is wrong, stop that template variant while fixing the source data.

A complete confirmation email example

This plain-text example is a layout to adapt, not a message from a real customer. Replace every bracketed value from the confirmed booking. The preview text is the short snippet many inboxes show beside the subject; the first visible sentence should still carry the useful facts when a mail application builds its own preview. In the examples, the "Preview text" line stands for your sending platform's preheader field; it is not typed into the message body.

Subject: Booking confirmed: [Service] on [Date]
Preview text: Your appointment is confirmed. See the time and location.

Hello [Customer name],

Your [Service] booking is confirmed for [Day, date] at [Local UK start time].
Location: [Venue address or secure online joining details].

Start: [Local UK start time and BST or GMT]
End: [Local UK end time and BST or GMT]
Booking reference: [Reference]
Payment: [Deposit paid, balance due and when, or amount paid in full]

Before you arrive: [Relevant preparation instructions]

Add to calendar: [Calendar link or .ics attachment]
Change or cancel: [Secure booking management link]
Cannot use the link? [Monitored contact route and change deadline]
Conditions: [Relevant cancellation deadline or policy]

Questions? Reply to this email or use [Contact route].

Thank you,
[Business name]

Do not put private access information in the preview text. If the booking is not accepted yet, replace the subject and opening with the pending version below, and leave out anything that implies a reserved slot:

Subject: Booking request received: [Service]
Preview text: We have your request. It is not yet confirmed.

Hello [Customer name],

We have received your request for [Service] on [Day, date] at [Requested start time], [Venue or online].
This appointment is not yet confirmed.
Next step: [How and when approval will be communicated].
Reference: [Request reference]

Questions? Reply to this email or use [Contact route].

[Business name]

Send both examples through the actual system with controlled records. Inspect the preview on a phone and make sure pending bookings cannot acquire confirmed wording from a shared footer. If they do, pause the faulty template trigger and review affected requests.

Subject line and sender name

"Booking confirmed: [service] on [date]" identifies the purpose before opening. Use the business name customers saw on the booking page. Avoid subjects such as "Important information" and keep private details out of notification previews.

Google's email sender guidelines require accurate sender information and subject lines for mail sent to personal Gmail accounts. The visible From address should be one your sending provider is authorised to use. Replies must reach an inbox that someone monitors, or the email should give a reliable alternative route.

Send a confirmation to an address you control. Read its sender and subject as they appear on a phone, then reply to it. If the reply goes nowhere or the sender looks unfamiliar, fix the routing or identity before release.

Plain text and HTML versions, and the phone layout

Plain text is sufficient for a straightforward confirmation. HTML may help with a longer message, but it must leave booking facts readable without images. Where supported, send equivalent plain-text and HTML alternatives. RFC 2046 defines the multipart/alternative format; it does not promise identical rendering in every mail application.

Keep the appointment status in selectable text, not inside a graphic. On a phone, avoid sideways scrolling and label management links clearly. The plain-text alternative needs the destination URL as well as a description of what it does.

Open the received message on a narrow screen with images disabled, then inspect the plain-text version. If words are clipped or links fail, return to a simpler layout before changing the production template.

An add-to-calendar link or .ics file

An add-to-calendar option saves manual entry, provided its event matches the accepted booking. Generate the start and end from stored appointment data. RFC 5545 defines the iCalendar format, including the event identifier (UID), start (DTSTART), end (DTEND) or DURATION, and time representations. Do not invent an end time when your system has only a start.

Generate the file after confirmation and open it in the calendar applications you support. An imported event might not update automatically after a move, even when identifiers and sequencing fields are present. For a moved booking, compare the new entry with the live record and check whether the old entry remains. If updates are unreliable, explain that customers may need to amend their calendars manually.

Leave sensitive notes out of calendar entries, which customers may share. Keep the appointment facts in the email too, so the calendar option is never the only record the customer can read.

Change and cancel links

A management link should open a review page, not perform an action. Email security scanners may visit links before the customer does, as Microsoft describes for Safe Links. RFC 9110 defines GET as a safe, essentially read-only method, and the OWASP CSRF Prevention Cheat Sheet says not to use GET for state-changing operations.

• Step 1: Keep a fallback. Preserve the existing management route and a copy of the template. Do not change outstanding bookings as part of deployment.
• Step 2: Restrict access. Require a login or a long, cryptographically unguessable token limited to that booking. Make token access expire and allow it to be revoked.
• Step 3: Prevent leakage. Keep tokens out of application and proxy logs, analytics URLs and Referer headers. Use HTTPS and a Referrer-Policy: no-referrer response on token-bearing pages, as OWASP advises for email-linked recovery pages; do not place third-party tracking on them.
• Step 4: Show the choice. Display the current booking and any cancellation conditions without changing its status when the link is opened.
• Step 5: Require confirmation. After the customer's explicit choice, submit changes and cancellations by POST with server-validated CSRF protection. Recheck authorisation, booking status and, for a move, that the new slot is still free, in the same database transaction as the update, so two customers cannot take one slot.
• Step 6: Record the result. Show the updated booking and send the relevant message. If a request fails or times out, read the booking's stored status before retrying, because the change may already have been saved.

The OWASP recovery-token guidance supports long random tokens, expiry and preventing referrer leakage. It concerns password recovery, so token lifetime and revocation rules need adapting to bookings. A booking reference alone should never authorise a cancellation.

Open a test link with a preview tool, then try an expired token and a request for another person's booking. Check a repeated cancellation too: it must not duplicate the action. Inspect access logs and outbound requests with a test token to check that it has not leaked. If it has, revoke the token, pause management links and identify affected bookings before fixing the exposure.

Keeping marketing out of it

Keep the confirmation administrative. The ICO's key concepts guidance for electronic mail marketing says service messages do not count as direct marketing when they only provide administrative information and promote nothing. Add advertising or marketing material and the message becomes direct marketing.

A normal business name or logo is different from an offer for another service. Inspect the provider-added footer as well as your own text. Remove promotional material from the confirmation and check the rendered result; get appropriate advice if a mixed-purpose message is unavoidable.

Reminders are a separate workflow from initial confirmation. The guide to SMS booking reminders and no-show reduction covers that subject.

Getting it delivered: SPF, DKIM, DMARC and the from address

SPF identifies authorised sending systems and DKIM provides a verifiable signature. DMARC requires the domain in the visible From address to align with the SPF-authenticated sending domain or a valid DKIM signing domain for a pass. RFC 7489 explains this alignment, including the difference between relaxed and strict matching.

Google's Gmail sender requirements, checked on 4 November 2026, require SPF or DKIM for all senders to personal Gmail accounts, with additional requirements for bulk senders. Google recommends configuring all three more generally. Authentication improves trust signals but does not guarantee the inbox.

For a third-party booking provider, check the domain it authenticates and the From address customers see. Record current DNS settings and identify other legitimate mail services before changing anything. Apply only values confirmed by the provider; inspect a received message's authentication results afterwards.

The NCSC's DMARC guidance recommends starting with the monitoring policy p=none. Review the reports and correct legitimate failures before tightening enforcement. If a change disrupts business mail, pause the rollout and check the affected messages against the saved DNS records.

For persistent junk-folder problems, compare provider delivery records with actual received messages. The separate guide to email deliverability and the spam folder covers other causes.

Testing before launch

Check the complete booking journey, not just the template. A successful email API response does not prove that the recipient got the message. The GOV.UK Service Manual's email guidance recommends delivery monitoring and integration testing; it is operational guidance, not legislation.

Save the accepted booking before asking the mail service to send anything. To avoid losing the notification if the application crashes between those operations, record a confirmation job in a durable outbox as part of the same database transaction as the booking. A separate worker can then deliver it. The AWS transactional outbox guidance explains why two independent writes can leave a saved record without its notification.

Automatic retries need an idempotency record keyed to the booking and confirmation event, so processing the same job again does not create another routine confirmation. Check whether your mail provider also supports deduplication: a crash after a send but before its acknowledgement can otherwise cause duplicates. A customer-requested resend is a separate, recorded action, not another automatic retry.

Exercise a pending request and an accepted booking, then interrupt the worker after the booking has been saved. Compare the resulting jobs and received messages with the stored statuses. For systems receiving outside events, receiving events through a PHP webhook covers the related integration concerns.

• Step 1: Preserve the working setup. Save the template and sending settings. Prepare a way to pause new triggers without altering existing reservations.
• Step 2: Exercise booking states. Use controlled bookings for pending and accepted states, including online appointments. Run payment success and failure checks in the payment provider's test mode, using its test credentials and test payment methods, never live cards.
• Step 3: Check persistence and retries. Interrupt delivery after saving a booking. Verify that the outbox retains the job and that reprocessing does not create a second automatic confirmation. Check a customer-requested resend separately.
• Step 4: Compare the result. Match received details with the booking record, then inspect both message formats on a phone. Review delivery and authentication evidence.
• Step 5: Exercise the links. Confirm that previewing a link makes no change, and that authorised POST actions update the booking. Examine the resulting calendar entry.
• Step 6: Release carefully. Watch delivery failures and booking-status mismatches after launch. If a trigger is faulty, pause that trigger only, list the affected bookings and send each customer a corrected message.

Provide a fallback for failed email delivery. After the booking is saved, show an on-screen confirmation with its reference and a way to request a resend. The resend must verify access to the booking, use the saved details and avoid exposing whether another person's email address has a reservation. Check that the page still works when the email provider is unavailable and that a resend generates one deliberate new request.

If you want to know whether the new message reduces calls asking "did my booking go through?", record those enquiries before and after launch using the same categories. Compare calls per completed booking over comparable periods, and separate missing-message reports from unclear wording. Without the records, do not claim an improvement. Even with them, season, booking volume and other site changes move the figure too, so treat it as a signal rather than proof.

Do not use opens alone as proof of reading. Apple's Mail Privacy Protection documentation explains why remote images may load in the background, independently of someone reading the message.

Before you rely on the new template

Correct booking status and appointment data before changing the design. You can handle straightforward wording changes yourself, or hire me to set up your booking emails when the integration needs development. Check the full journey, including the on-screen fallback, before relying on the revised booking confirmation email.