Host receives a separate notification for each new booking

If the host does not get a per-booking notification, bookings go unnoticed until the customer shows up to an empty room. Digest-only notifications fail the moment a booking is made less than 24 hours out — the host reads the digest the next morning, after the appointment slot. Host-side awareness is the difference between a booking system and a calendar-shaped black hole. No-show rates for hosts are just as business-critical as customer no-shows and they break trust with paying customers permanently.

Dispatch a host notification inside the same confirmation handler as the customer notification — same code path, same transaction boundary, queued not cron'd. Include at minimum customer name, service, date, time, and timezone in the payload so the host can act without opening the dashboard. Edit src/lib/bookings.ts:

await emailQueue.add('send-host-notification', {
  bookingId,
  hostEmail: booking.host_email,
  customerName: booking.customer_name,
  service: booking.service_name,
  dateTime: booking.start_time,
  timezone: booking.timezone,
})

• ID: booking-notifications-reminders.reminders.host-notification-per-booking

• Severity: medium

• What to look for: Find the booking confirmation code. Search for a notification to the host/provider — either an email, in-app notification, or webhook. Verify: (1) The notification is triggered per-booking (not aggregated into a daily digest). (2) The notification includes booking details (customer name, service, date/time). (3) The notification is dispatched in the same code path as the customer notification. Count the number of notifications sent on booking confirmation — there should be at least 2 (customer + host).

• Pass criteria: Count all notification details included. ALL of the following: (1) On booking confirmation, a notification is sent to the host — quote the send call or queue addition. (2) Notification is per-booking (not a digest). A daily digest does NOT count as pass. (3) Notification includes at least 3 of these 5 fields: customer name, service, date, time, location — enumerate each field found and report the count even on pass.

• Fail criteria: Host not notified of new bookings at all. Host receives a daily/weekly digest instead of per-booking notification. Host notification lacks booking details (just "You have a new booking"). Notification is in a separate code path that could be missed (e.g., separate cron job).

• Skip (N/A) when: Booking system is single-user (no separate host/provider entity in the data model — verified by checking the database schema for a host_id, provider_id, or equivalent foreign key on bookings).

• Detail on fail: State what host notification was found (or "none"). Quote the confirmation handler and identify what notifications it dispatches. Example: "confirmBooking() at src/lib/bookings.ts:25 queues email to booking.customer_email only. No host notification found. Host has no email or notification sent anywhere in the confirmation code path.".

• Remediation: Send a per-booking notification to the host:

  // src/lib/bookings.ts
  async function confirmBooking(bookingId: string) {
    const booking = await db.bookings.update(bookingId, { status: 'confirmed' })
  
    // Notify customer
    await emailQueue.add('send-confirmation', {
      bookingId,
      customerEmail: booking.customer_email,
    })
  
    // Notify host — per-booking, not a digest
    await emailQueue.add('send-host-notification', {
      bookingId,
      hostEmail: booking.host_email,
      hostName: booking.host_name,
      customerName: booking.customer_name,
      service: booking.service_name,
      dateTime: booking.start_time,
    })
  }
  

• Cross-reference: Booking Flow & Lifecycle audit checks the confirmation handler completeness. Email/SMS Compliance audit checks notification email compliance. Accessibility Fundamentals audit checks notification accessibility.