Booking e-mails and reminders
Every e-mail the system sends by itself, who gets it, and what it says. Rules: COMM-001 … COMM-014, COMM-037 … COMM-039. Settings: Admin → Reminders (Admin). Running it: Booking reminder e-mails.
The booking block
Every e-mail about a booking carries the same block, read from the database
(booking_email_summary, COMM-001):
| Row | From |
|---|---|
| Booking number | BK-…, also in the subject |
| Moved to | only on a booking closed by a transfer: the booking(s) it went to |
| Lead customer | the booking's customer, with the CU- code |
| Paid by | only when a different customer pays |
| Travellers (N) | every live traveller, the lead first; cancelled travellers are left out |
| Partner | only on a partner booking: agency name and BP- code |
| Departure | group name and code |
| Travel dates | DD/MM/YYYY to DD/MM/YYYY |
| Package | trip type and room type, e.g. Umrah · Quad room |
| Booking total, Received so far, Cancellation credit, Balance due | only on an e-mail about money (COMM-002) |
| This payment, Payment date, Paid by method, Reference, Receipt number | only on a payment receipt |
The subject is what happened — booking number — people. The block never carries a passport, Aadhaar or PAN number, a date of birth, a phone number, an e-mail address or a document link (COMM-003).
The sender only passes the booking id (and, for a receipt, the payment id). The mailer reads the
block with the service key. A browser caller gets it only for a booking its own session can read.
If the database cannot be read, the e-mail still goes with what the sender passed, and without the
block.
Every automatic e-mail
"Block" says whether the e-mail carries the booking block. Recipients did not change with the block; only the reminders are new.
About a booking
| E-mail (mailer type) | Sent when | Sent by | To | Block |
|---|---|---|---|---|
Booking received (booking_created) |
a booking is announced (LC-007) | the database queues it (booking_created_notify), the dispatcher sends |
the customer | yes, with money |
Booking placed (b2b_booking) |
the same, on a partner booking | the same | the partner | yes, with money |
Booking status (booking_status_change) |
ops approves, sends back or a booking is resubmitted; finance approves or rejects; a booking's status is changed on the booking edit route (PATCH /bookings/:id) |
the browser (src/lib/api.ts) |
the customer, and the partner on a partner booking | yes |
Payment received (payment_receipt) |
a payment on a booking becomes verified — finance verifies it (web or phone), or razorpay-webhook records an online payment. Not an allocation of a partner's on-account receipt (COMM-038) |
the database queues it (payment_email_notice, once per payment, category finance), the dispatcher sends |
the partner on a partner booking; else the customer, or the payer when someone else pays | yes, with money and the payment |
Payment claim not accepted (payment_claim_rejected) |
finance rejects a payment a partner or customer reported themselves (COMM-037) | the database queues it (payment_email_notice, once per payment, category finance), the dispatcher sends |
the agency for a partner's claim, the customer for theirs | yes, without money; the claim and finance's reason |
Refund processed (refund_notice) |
a refund is approved | the browser, after approve_refund |
the customer | yes, with money |
Visa issued / refused (visa_status_change) |
a visa case moves to ISSUED or REJECTED (VISA-005) |
the database queues it (visa_status_notify), the dispatcher sends |
the customer, and the partner | yes, plus whose visa and the application number |
Visa documents needed (visa_status_change) |
ops approval opens visa cases | the browser, after ops_decide_booking |
the customer, and the partner | yes |
Payment due (booking_reminder) |
7 days before the balance due date | the daily reminder run | the payer or customer; the partner on a partner booking | yes, with money |
Payment overdue (booking_reminder) |
after the due date, weekly, at most 4 times | the daily reminder run | as above | yes, with money |
Departure (booking_reminder) |
7 and 1 days before departure | the daily reminder run | the customer; the partner on a partner booking | yes, the balance if any, and before you go |
Documents (booking_reminder) |
45 and 21 days before departure, if something is missing | the daily reminder run | as above | yes, and who is missing what |
Message from the booking (freeform_message) |
staff press Send message on a booking | the browser | who staff choose | yes |
Not about a booking
| Sent when | To | Block | |
|---|---|---|---|
Quotation (quotation_created) |
a quotation is created | the customer, the partner copied | no — a quotation has no booking |
Welcome (customer_welcome) |
a customer registers | the customer | no |
Wallet top-up (wallet_topup_status) |
not sent by any screen today | — | no |
One-time code (otp_code) |
a code is requested | the person | no |
| New enquiry, new visa application | the website forms (lead-intake, visa-intake) |
staff | no — no booking yet |
Leave (leave_notice) |
a leave application, absence, approval, refusal or cancellation (LV-036 … LV-039); queued by the database, sent by the dispatcher | the reporting officer, the approvers, the applicant — see Leave → E-mails | no — staff only |
| Account e-mails | sign-up, password reset, e-mail change (customer-signup, partner-signup, auth-login, admin-users, Supabase Auth templates) |
the account holder | no |
No e-mail is sent by issue-document (it makes the receipt, e-ticket and voucher PDFs that staff
share). razorpay-webhook sends none itself: the online payment it records is verified, and the
database queues the receipt e-mail from that. A partner's or customer's payment claim is not
e-mailed when it is reported; it is when it is verified (the receipt) or rejected (Payment claim
not accepted).
One queue, once. Every e-mail the database queues has a category (hr_leave, finance,
booking, visa, general) and, when it is automatic, a key such as payment_receipt:<payment>;
the same category and key are queued once
(COMM-039). The leave e-mails
are switched in Leave admin; the finance e-mails in Admin → Reminders → Automatic e-mails by
category.
Samples
Invented names and numbers.
Payment received — BK-00123 — Irfan Ahmad Dar & 2 others
Assalamu alaikum Irfan Ahmad Dar, We've received your payment for booking BK-00123.
Booking number BK-00123 Lead customer Irfan Ahmad Dar (CU-000123) Travellers (3) Irfan Ahmad Dar, Shazia Dar, Umar Dar Departure Umrah December (UMR-DEC-26) Travel dates 05/12/2026 to 19/12/2026 Package Umrah · Quad room Booking total ₹3,15,000.00 Received so far ₹1,00,000.00 Balance due ₹2,15,000.00 This payment ₹1,00,000.00 Payment date 27/09/2026 Paid by method UPI Receipt number RV-0001
Other subjects:
- Booking received — BK-00123 — Irfan Ahmad Dar & 2 others
- Booking placed — BK-00124 — Aisha Bhat (to the partner)
- Your booking is confirmed — BK-00123 — Irfan Ahmad Dar & 2 others
- Refund processed — BK-00123 — Irfan Ahmad Dar & 1 other
- Visa issued for Shazia Dar — BK-00123 — Irfan Ahmad Dar & 2 others
- Payment due on 05/11/2026 — BK-00123 — Irfan Ahmad Dar & 2 others
- Payment overdue — BK-00123 — Irfan Ahmad Dar & 2 others
- Your journey starts in 7 days — BK-00123 — Irfan Ahmad Dar & 2 others
- Documents needed before departure — BK-00123 — Irfan Ahmad Dar & 2 others
A documents reminder lists, for example, "• Umar Dar: Passport details" — never a number.
Not built
- WhatsApp versions of these e-mails and reminders (each needs a Meta-approved template). Two are built: booking confirmed and payment received with the receipt PDF — see Booking WhatsApp notices.
- A quotation expiring reminder.
- Reminders per instalment: a booking has one balance due date.
- A per-booking switch to stop reminders; the customer's e-mail consent is the switch.
- An e-mail when a cancellation request is approved (
apply_booking_cancellation_status) or a traveller is transferred. Neither sends one today; the booking's status e-mail goes only from the edit route and the approval steps above. - The status e-mails, the receipt and the refund are still sent from the browser after the database step. The booking block itself comes from the database.