What Tabledoo sends, and when

What this covers

Every message Tabledoo can send your guests, what makes each one go out, and which channels it can use. This is the reference page — the articles after it cover each area in detail. Reading Property Settings → Notifications (/settings/notifications) needs the manage-settings permission (Owner or Manager).

Guest messages are transactional: they are about a booking the guest made, and they go out automatically. Tabledoo does not send marketing email and has no newsletter.

The full list

MessageWhat triggers itEmailSMS
ConfirmationA booking reaches confirmed status — either created that way or confirmed laterYes, on by defaultYes, off by default
ReminderA set number of hours before the bookingYes, on by defaultYes, off by default
UpdateThe date, time, pax or table changesYes, on by defaultYes, off by default
CancellationThe booking is cancelled, with an optional reasonYes, on by defaultYes, off by default
Table readyStaff press Notify on a waitlist entryYes, on by defaultYes, off by default
Review requestA set number of hours after a booking is marked completedYes, off by default, and needs the Guest Feedback Emails featureNo — email only
Event booking confirmationA guest is booked onto an eventYes — uses the confirmation toggleNo — email only
Event booking cancellationAn event booking is cancelledYes — uses the cancellation toggleNo — email only

Three things this table is telling you

Email is on, SMS is off, until you say otherwise

Every email type except the review request is on for a new restaurant. Every SMS type is off, because SMS costs credits and nobody should start spending without deciding to. Turning SMS on is a deliberate act — see SMS: what's different and How SMS credits work.

Each type has its own switch per channel

Email confirmations and SMS confirmations are two independent settings. You can send confirmations by both, by one, or by neither, and the same for reminders, updates and cancellations. Nothing is bundled.

Event messages share the reservation switches

This one catches people out. There is no separate "event confirmation" toggle — event booking confirmations ride on the confirmation setting, and event cancellations on the cancellation setting. So turning off reservation confirmation emails also silences event booking confirmations.

What decides whether a guest actually gets it

Every message passes the same checks. If any fails, nothing is sent and nothing is queued for later:

  1. The message type is switched on for that channel.
  2. The guest has the contact detail that channel needs — an email address, or a mobile number.
  3. For SMS: the guest is not opted out, and you have enough credits.
  4. For review requests: your plan includes the feature and you have saved a review link.

If a guest did not get something, work down Why a message wasn't delivered — it follows exactly this order.

Messages go out in the background

Sending happens after your click, not during it. This matters in practice:

  • Saving a booking is never held up. A slow mail server or a busy SMS provider cannot make the host stand wait, which is the whole point at a busy pass.
  • A failed send retries by itself, up to three attempts, so a momentary hiccup does not lose a message.
  • There is a short delay. Usually seconds. If a guest is standing in front of you saying they have not had the email, give it a moment before assuming something is wrong.

What is never sent

  • Marketing of any kind. No newsletters, no promotions, no re-engagement campaigns.
  • Anything to a guest with no booking. Adding someone to your guest book does not message them.
  • Notifications to your own staff by email or SMS. Staff alerts appear inside the app — the arrivals list, the Orders board, the header indicators — not in an inbox.
  • A message for a status change that is not in the table above. Marking a guest arrived, seated or completed sends nothing (link The reservation lifecycle). Only confirmed and cancelled reach the guest.

What the guest sees

Emails carry your restaurant's name, email, phone and address, taken from Property Settings → Restaurant — so keeping those accurate matters more than it looks (link Restaurant profile). Messages are written in your restaurant's language, not the guest's.

Where to go next