Messages, confirmations & reminders

DineGlobe sends guests transactional messages about their own bookings and queue entries: confirmations, request receipts, change and cancellation notices, reminders, reconfirmation pings, fresh self-service links and waitlist notices. Every message is rendered from a reviewed template and dispatched through a durable background job, and every attempt — success, suppression or failure — leaves an evidence row staff can inspect. During the pilot no email provider is configured, so email jobs dead-letter visibly instead of pretending to send; this page explains that posture plainly.

What is sent

Each row below is an approved message purpose. Purposes are fixed: nothing outside this list can render, and no marketing message exists anywhere in the product.

Purpose	What the guest gets	When it is enqueued
booking.requested	“We received your booking request — {venue}”, stating it is a request, not a confirmation	A request-mode booking is placed
booking.confirmation	Confirmation with the code, date and time, party size and amount due at the venue	The booking is confirmed — instant booking, request approval, or a verified payment
booking.changed	Notice that the booking changed	A staff edit such as a reschedule (the booking’s version moved)
booking.cancelled	Cancellation notice with the policy outcome of that cancellation	The guest or the venue cancels
booking.declined	Decline notice with the venue’s reason	A manager declines a requested booking
booking.expired	“Your booking request for {venue} expired before it could be confirmed…”	A request passes its review deadline, or its service start passes
booking.reminder	An upcoming-service reminder (24h, or the optional 2h one) or a reconfirmation ping	Scheduled with the booking’s version; see quiet hours below
booking.access_recovery	A fresh one-time self-service link, valid 24 hours	Email-plus-code recovery, or staff issuance
waitlist.joined	“You are in the queue — {venue}” with the position at join time	A guest joins the same-day queue
waitlist.ready	“Your table is ready — {venue}”, asking to confirm within 5 minutes	A host offers the party a held table
sms.booking.confirmation, sms.booking.reminder	SMS versions of the confirmation and reminder	When the venue has SMS switched on — the gates below still decide at dispatch

The confirmation email contains only the confirmation code — it never carries the self-service link. That link arrives through recovery (email plus code) or staff issuance, as described in Guest self-service links.

Templates and languages

Every purpose has a versioned template (for example booking.confirmation.v1). Templates are reviewed in English and Japanese; a guest whose locale is neither still gets the English text, and the delivery evidence records which language actually went out rather than assuming. Times render as YYYY-MM-DD HH:mm with the venue’s time zone named beside them. A manager can preview any template against live booking facts from the operator console — a preview renders and sends nothing.

How sending works

A message job is written into the outbox in the same transaction as the change that caused it, so a booking and its confirmation email are born (or not) together. Jobs move READY → RUNNING → DONE or FAILED. The worker is at-least-once: a crashed job’s lease expires and the work is reclaimed, and handlers are idempotent (dedupe keys, reconcile-before-send) so a retry can never send the same message twice. Retries back off exponentially — the first retry after 15 seconds, doubling, capped at 15 minutes — and every job carries its own attempt cap. Exceeding the cap dead-letters the job as FAILED: an operator-visible state, never a silent drop.

Reminders are scheduled per booking version. An edit schedules the new version’s reminders while the old version’s pending jobs suppress as stale, so a guest is never reminded into a time they no longer have.

Quiet hours and reminder switches

A manager sets the venue’s quiet window as venue-local HH:MM start and end times (equal values mean no window) and can switch the optional two-hour reminder on or off. The 24-hour reminder is the default; a booking made inside the reminder window simply skips the reminder that would have fired before it existed. When a scheduled reminder’s run time lands inside the quiet window, it is advanced to the window’s end at scheduling time — and the quiet window is checked again at dispatch, because the booking may have moved since. The reconfirmation ping is exempt from quiet hours: the venue asked that guest a direct question, and the template says so.

Delivery outcomes

Every dispatch attempt writes one evidence row with exactly one of five outcomes:

Outcome	Meaning
SENT	The provider accepted the message; its provider message id is recorded
RECONCILED	Crash recovery — prior evidence or a provider lookup proved the send already happened, so nothing is sent twice
SUPPRESSED	A policy verdict said no; the reason is recorded (table below)
NO_RECIPIENT	No address existed for the guest — nothing is invented, and an email is never sent pretending to be SMS
FAILED	The message was aimed at a real recipient but errored; the error code is mandatory

Suppression reasons

Reason	Meaning
STALE_EVENT	An edit superseded this version’s event — the guest will hear about the newer version instead
REMINDER_PAST_SERVICE	The reminder’s service has already started; the ping is pointless
ALREADY_RECONFIRMED	The guest already reconfirmed; no further nagging
QUIET_HOURS	Dispatch time falls inside the venue’s quiet window
ENTRY_CLOSED	The waitlist entry is no longer active, so the joined notice is moot
OFFER_NOT_OPEN	The table offer is no longer open or has expired, so the ready notice is moot

SMS gates

SMS is deny-by-default, and every refusal is evidenced rather than hidden. At dispatch, in order: the venue’s SMS switch must still be on (SMS_VENUE_DISABLED); the shared suppression truths above apply identically; the recipient must be the E.164 phone frozen in the booking’s contact snapshot (absent is an honest NO_RECIPIENT); the venue’s country must carry an enabled sms capability row (SMS_COUNTRY_NOT_APPROVED); the approval must name the provider actually in use (SMS_ROUTE_NOT_APPROVED); and the venue’s approved quota budget must cover the send (SMS_QUOTA_NOT_APPROVED, then SMS_COST_CAP_EXHAUSTED once the cap is reached — a failed send returns its claimed unit). With no provider configured the send fails visibly as PROVIDER_NOT_CONFIGURED instead of disguising itself as a policy verdict.

A manager can read the live gate truth — country approval, provider configuration, quota state — next to the venue’s own switches. A switch that is on is not a promise the gates can keep, and the console says so.

The pilot posture, stated plainly

No email provider is configured for the live pilot. Every email job therefore dead-letters visibly with PROVIDER_NOT_CONFIGURED as a permanent failure — nothing is silently dropped and no success is faked. In product terms: a booking still confirms in the app with its DG- code, but the confirmation email never arrives, and staff can see exactly that in the delivery evidence. Once an approved provider is connected, a manager can retry the dead-lettered jobs.

Single-market pilot evidence only: one approved country and its listed capabilities do not constitute global support; unlisted countries and capabilities stay disabled.

What staff can inspect

The delivery-evidence list at the operator console (https://dineglobe.com/app/panels) shows one row per job: purpose, state, attempt count, last error code, and the latest attempt’s outcome — status, template, language, masked recipient, provider, provider message id and error code. Recipients are always masked in evidence (roughly j***@example.com for email, the leading characters and last two digits for a phone, e.g. +81***78); the full address never crosses into staff views.

Only a visibly FAILED job can be retried, and only by a manager or above — retrying anything else answers CONFLICT. A retry sets the job back to READY, and it walks the same ladder as any first attempt. Suppressed and sent messages are not retryable; they are the record of a decision. Unrecognized failures are listed with their codes in Error codes & fixes, and the guest-side view of the same pipeline is covered in Making a booking and Waitlist.