Skip to main content
These settings are the common starting point for the whole team. A collaborator who has customized nothing receives exactly what is ticked here, and automatically follows your future changes. Go to Settings > Notifications > General, then open the Restaurant owner tab.

​
Reading the table

Each row is an event, each column a channel. If you use the Activities feature, two sub-tabs appear above the table — Restaurant and Activities — each with its own settings.
Some rows are marked Always on: their card stays in the notification center no matter what, and the App switch is locked. This covers inquiries awaiting confirmation and AI agent escalations — situations where a customer is waiting on a human, and where the trace must not be able to disappear. Push can still be turned off like on any other row.

​
The “Min. group” threshold

This is the most useful setting in a high-volume restaurant. Set to 6 on “Reservation received from a customer”, the team stops being alerted for tables of 2 or 4 — the ones that come in all day and that nobody needs to handle instantly — but stays alerted on large parties, which need deliberate seating. The threshold applies to all three channels at once: no push, no email, no card in the notification center below the threshold. The reservation is of course recorded normally and visible in the reservation list.
The threshold is a restaurant setting, not a personal one: it applies to the whole team. Leave it at 1 to be notified of every reservation.

​
Additional email addresses

Below the table, the Additional email addresses section holds the inboxes that receive the team’s emails. They are the only recipients of the Email column. Put a generic address the team actually reads there (reservations@, frontdesk@), not a manager’s personal address — someone who wants to be alerted personally should use push.

​
Accounting

The last section, Accounting, is independent from the table. The addresses listed there receive the details of every charge, refund and imprint capture, whatever the Payments rows are set to. Empty the list to stop those emails.

​
Notification catalogue

Here is every row of the table, with the permission needed to receive it and the settings applied when a restaurant is created.

​
Customer reservations

​
Internal reservations

These rows are never sent to the person who performed the action.

​
Payments

​
Customer reviews

​
WhatsApp

These two rows only appear when a WhatsApp Business number is connected, and only in each collaborator’s personal preferences — they are not in the team defaults table.
“New WhatsApp message” does not create a card in the notification center: one card per message would bury everything else, and the WhatsApp inbox already exists for that.

​
Activities

When the Activities feature is enabled, the Activities sub-tab mirrors the same structure: activity confirmed, pending confirmation, cancelled by a customer, created or cancelled internally, payment received, refund, internal refund, imprint captured or released. Permissions are activity:read for activity bookings and payment:read for payments.

​
Our recommendations

Keep the defaults. Turn Email on for “Reservation received from a customer” and “Reservation cancelled by a customer” if you want a written trace in the front-desk inbox. Leave Min. group at 1.
Raise Min. group to 6 or 8 on “Reservation received from a customer”: the team is only alerted on large parties. Turn push off on “Reservation modified” and “Reservation re-confirmed”, which arrive constantly, and keep them on App so you can still find them.
“Reservation pending confirmation” is your critical row: keep it on Push, and add Email to the shared inbox. An unanswered inquiry is a lost customer.
Leave the Payments rows on App only, and fill in the Accounting section instead: your accountant gets the details, and the floor team is not interrupted mid-service.
Defaults are per restaurant. Set them venue by venue: a cocktail bar and a fine-dining room do not have the same useful threshold.