> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eat-now.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Team defaults
> The screen that decides, for every event, whether your team is alerted by email, by push and in the app — with the full notification catalogue and our recommendations.
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.
| Column | What it does when enabled |
| -------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Email** | Sends an email to the restaurant's **shared addresses** (see below). Never to collaborators' personal addresses. |
| **Push** | Sends a notification to the team's phones and tablets running the EatNow app. |
| **App** | Makes a card appear in the [notification center](/notifications/center). |
| **Min. group** | Only on the "Reservation received from a customer" and "Activity confirmed" rows: only alerts from this party size upwards. |
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
| Notification | Trigger | Permission | Default |
| ------------------------------------ | ---------------------------------------- | ------------------ | ------------------------ |
| Reservation received from a customer | A customer reservation is confirmed | `reservation:read` | Push + App |
| Reservation pending confirmation | A customer sends an inquiry to approve | `reservation:read` | Push + App *(always on)* |
| Reservation modified | A customer modifies their reservation | `reservation:read` | App |
| Reservation re-confirmed | A customer re-confirms their reservation | `reservation:read` | App |
| Reservation cancelled by a customer | A customer cancels | `reservation:read` | Push + App |
### Internal reservations
These rows are never sent to the person who performed the action.
| Notification | Trigger | Permission | Default |
| --------------------------------- | --------------------------------------------- | ------------------ | ---------- |
| Reservation created internally | A team member creates a reservation | `reservation:read` | App |
| Reservation cancelled internally | A team member cancels a reservation | `reservation:read` | Push + App |
| Refund issued internally | A team member issues a manual refund | `payment:read` | App |
| Card imprint captured or released | A team member captures or releases an imprint | `reservation:read` | App |
### Payments
| Notification | Trigger | Permission | Default |
| ---------------- | ---------------------------------------------- | -------------- | ------- |
| Payment received | A payment or pre-authorization is charged | `payment:read` | App |
| Refund issued | A customer is refunded following their request | `payment:read` | App |
### Customer reviews
| Notification | Trigger | Permission | Default |
| ------------------------ | ------------------------------------- | ------------- | ------- |
| Customer review received | A customer leaves a review or comment | `review:read` | App |
### 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.
| Notification | Trigger | Permission | Default |
| -------------------- | -------------------------------------------------- | ---------------------------- | ------------------------ |
| AI agent escalation | The AI agent hands a conversation over to the team | `whatsapp:escalation_notify` | Push + App *(always on)* |
| New WhatsApp message | A customer writes on WhatsApp | `customer:read` | Push only |
"New WhatsApp message" does **not** create a card in the notification center: one card per message would bury everything else, and the [WhatsApp inbox](/notifications/center#the-whatsapp-tab) 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.