Modification emails show both the original and the new date and time
Why it matters
A modification email that only shows the new time creates two failure modes. First, customers who don't remember the original booking cannot tell what changed and assume the email is spam or a duplicate confirmation. Second, customers who misread the new time cannot cross-check it against the old one — they show up at the original hour. Before/after comparison is the only way the customer can verify the reschedule matches what they requested, and its absence directly generates support tickets and missed appointments.
Severity rationale
Medium because ambiguous reschedule emails cause wrong-hour arrivals and support volume, but the booking record itself is correct.
Remediation
Preserve the old booking state before the update, pass both old and new booking objects to the template, and render them side-by-side with <s> strikethrough on the old values plus explicit "Previous:" / "New:" labels. Edit src/emails/modification-template.ts:
export function modificationEmailTemplate(booking: Booking, oldBooking: Booking) {
return `
<p><strong>Previous:</strong></p>
<p><s>${formatDateTimeWithTimezone(oldBooking.start_time, oldBooking.timezone)}</s></p>
<p><strong>New:</strong></p>
<p>${formatDateTimeWithTimezone(booking.start_time, booking.timezone)}</p>
`
}
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Booking Notifications & Reminders Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
Taxons
History
- 2026-04-18·v1.0.0·Initial import from booking-notifications-reminders·automated