> ## 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.
# Booking rules
> Which contact details guests and staff must enter, how customer records are matched, who can delete a reservation, when guests can modify their booking, and the cancellation reasons they pick from.
These rules decide what a guest has to fill in on your booking portal, what your team has to fill in when they add a reservation by hand, and what a guest can do with their booking afterwards. Everything is under **Settings > Portal > General**, in the **Reservation portal settings** card, below the links and widget block (covered in [Share and embed](/portal/share-and-embed)).
Changes apply as soon as you click **Save** at the bottom of the card. Saving requires the **Portal > Update** permission: without it, the button reads **Action not authorized**. See [Permissions](/collaborators/permissions).
The same card also holds the portal's custom message and the large group message. Both are explained in [Guest messages](/portal/guest-messages).
## Contact details: portal vs internal
Each contact detail has two switches. The one without "internally" applies to **guests booking on your portal**. The one with **internally** applies to **your team adding a reservation in the dashboard** (web or mobile app). They are independent: you can require an email from online guests without forcing your staff to ask for one on the phone.
| Setting | What it does | Default |
| - | - | - |
| **Mandatory email** | On the portal, the guest cannot send their booking without an email address. | On |
| **Mandatory email internally** | In the staff reservation form, a new customer cannot be saved without an email. | Off |
| **Mandatory phone number** | On the portal, the guest cannot send their booking without a phone number. | Off |
| **Mandatory phone number internally** | In the staff reservation form, a new customer cannot be saved without a phone number. | Off |
**On the portal**, first name and last name are always required. When an email is optional, the field can be left empty, but an email that is typed must still be valid. The same goes for the phone number: optional or not, a number that is typed must be valid before the guest can continue. When a required field is missing, the send button stays disabled and a hint tells the guest what is missing.
**In the staff reservation form**, the check only applies when your team creates a **new** customer. If they pick an existing customer from the name, email or phone autocomplete, the booking is saved even if that customer has no email or phone on file. Fields that are not required show **Optional** next to their label. When a required field is empty, saving is blocked with **Email is required** or **Phone number is required**. See [The reservation form, field by field](/operations/reservation-form#customer).
**Mandatory email** also applies to bookings taken by the WhatsApp AI agent: when it is on, the agent asks the guest for an email before booking if none is on file.
Keep **Mandatory email** on unless most of your guests book through WhatsApp. Without an email, the guest receives no confirmation, reminder or review request by email, only WhatsApp messages if you have their number. See [Notifications sent to your customers](/notifications/guests).
Turn **Mandatory phone number internally** on if your team takes bookings by phone. The phone number is what EatNow uses to recognise a returning guest (see below), and it gives you a way to reach someone who is running late.
These four switches apply to restaurant reservations. The activities portal has its own contact settings under **Settings > Portal > Activities**.
## Customer records
| Setting | What it does | Default |
| - | - | - |
| **Automatic customer matching** | Links a new booking to the existing customer record with the same phone number or email, instead of creating a duplicate. | On |
| **Allow anonymous customer** | Lets your staff save a reservation with no customer record attached. | On |
### Automatic customer matching
When a booking comes in with contact details, EatNow looks for an existing customer of **this restaurant**:
1. by **phone number** first. Numbers are compared digit by digit, using your restaurant's country, so `+212 661 234 567` typed on the portal and `0661234567` typed at the counter are the same guest;
2. then, if no phone matches, by **email** (case-insensitive).
If a customer is found, the booking is attached to it and appears in that guest's history. The existing record is **never overwritten**: its name, email and phone stay as they are. The only thing a new booking can change is newsletter consent, which can be switched from no to yes but never back. If the match is a draft record opened by an incoming WhatsApp message, it is completed with the name and details from the booking.
Matching applies to bookings from your portal (restaurant and activities), bookings your staff type in with a new customer, and bookings created through the partner API. Two exceptions:
* bookings made through a **prescriber** (travel agency, concierge) are never matched: each one gets its own customer record;
* **Reserve with Google** bookings are always matched, whatever this setting says.
**When the setting is off**, every booking creates a new customer record, even for a regular. Your customer list fills with duplicates, and history, notes and no-show counts are split across them. The [blacklist](/portal/blacklist) still works: a blacklisted phone number or email is still recognised and the portal booking is refused.
In the staff form, the **Attach to this profile** suggestion that appears when you type a known phone number is shown whatever this setting says. The setting only controls what happens when staff ignore it.
### Allow anonymous customer
In the staff reservation form, the **Customer** section has two tabs: **Walk-in** and **Defined**. **Walk-in** saves the reservation with no customer record: no name, no email, no phone.
* **On**: staff can pick **Walk-in**. The walk-in shortcuts (the walk-in button, adding a guest from a free table on the floor plan, clicking an empty slot in the planning grid) open the form with **Walk-in** already selected.
* **Off**: the **Walk-in** tab is greyed out, with the tooltip **Anonymous reservations are disabled for this restaurant**. The walk-in shortcuts open the form on **Defined**, and saving without a customer is blocked with **A customer is required (anonymous reservations are not allowed).** Anonymous reservations created before you turned it off can still be edited and saved.
In practice, an anonymous reservation has no contact details, so no confirmation, reminder or review request can be sent. It is not added to any customer's history, and the guest has no link to manage it on the portal. This setting only affects staff: a portal booking always creates or matches a customer.
Leave it on if you seat many walk-ins during a rush: typing a name for every couple at the door slows service down. Turn it off if you want every cover tied to a guest profile, for example to build your marketing database or track regulars.
## Staff tools
| Setting | What it does | Default |
| - | - | - |
| **Allow reservation deletion internally** | Shows the delete action on reservations for staff who have the **Reservations > Delete** permission. | On |
| **Show total paid** | Shows a **Total paid** amount at the top of the reservation form. | Off |
### Allow reservation deletion internally
This setting is about **your staff**, not your guests. When it is on, staff who also have the **Reservations > Delete** permission see **Delete reservation** in the reservation list actions and in the reservation form menu, and **Delete** in the floor plan context menu. The mobile app follows the same rule. When it is off, these actions disappear for everyone in your team.
Deleting is permanent: the reservation is erased with no trace kept, and the guest is **not** notified. **Cancel** is always available, whatever this setting says, and keeps the reservation in your history with a canceled status.
This switch does **not** control whether guests can cancel from the portal. Guests can cancel their own booking from the portal whatever this setting says.
Turn deletion off and have your team cancel instead. A canceled reservation stays in your statistics, in the guest's history and in the activity log. A deleted one simply vanishes. Keep deletion for real mistakes, such as a test booking or a duplicate entered twice.
### Show total paid
When it is on, opening an **existing** reservation shows a **Total paid** amount at the top of the form, in your restaurant's currency. It does not appear when creating a new reservation. Staff with the **Reservations > Update payment** permission can click the pencil to correct the amount, then confirm with the check mark. The change is saved with the reservation.
If a point-of-sale system is connected (Lightspeed, NowOS), it fills this amount automatically from the bill. The amount counts towards the customer's total spent, except on canceled or rejected reservations.
This setting only changes the staff reservation form: nothing is shown to guests on the portal.
## Reservation modification
This section decides whether guests can change the **date, time and number of guests** of their booking themselves, from the portal link in their confirmation.
| Setting | What it does | Default |
| - | - | - |
| **Allow reservation modification** | Shows the **Update my reservation** button (**Update my request** for a request still pending) on the guest's reservation page. | On |
| **Maximum modification threshold in hours** | How many hours before the reservation the guest must modify at the latest. `0` = up to the time of the reservation. | 1 hour |
| **Limit modification to group size** | Turns on a party-size limit for self-service changes. | Off |
| **Maximum group size for modification** | The largest party size a guest can modify online, and the largest size they can change to. Appears when the limit is on. | — |
The two number fields can only be edited when **Allow reservation modification** is on.
### When a guest can modify
On the portal, the guest sees the update button only when all of these are true:
* **Allow reservation modification** is on;
* the time now is no later than the reservation time minus the threshold. With a threshold of 2 hours, a guest booked at 20:00 can modify until 18:00;
* the reservation is **Pending**, **Confirmed**, **Manually confirmed** or **Double confirmed**;
* the reservation has **no payment line** attached (deposit, prepayment, card imprint or any other);
* the party size is not above the **Maximum group size for modification**, when that limit is on.
Otherwise the button is replaced by a contact button (**Contact the restaurant** or **Contact us**) that shows your contact details. A guest who opens an old modification link after the deadline (or once the booking is canceled or paid) is sent back to their reservation page. A guest whose party is above the group-size limit who opens the modification link sees **Modification not possible**, with the reason and a **Contact the restaurant** button, and no form.
EatNow checks the same rules again when the guest saves: a modification page left open past the deadline, for example, cannot be saved: the guest sees an error message and their booking stays as it was.
The new date and time go through the same availability checks as a new booking. A guest cannot move to a service that requires a prepayment or deposit: the modification page shows **Modification impossible** and asks them to contact you. Once the change is saved, the guest receives the modification message (email and WhatsApp, depending on your [guest notification settings](/notifications/guests)) and your team is notified.
Your staff are not bound by these rules: they can always edit a reservation from the dashboard. The WhatsApp AI agent applies the same toggle, threshold and group-size limit. Reserve with Google modifications only check **Allow reservation modification**.
### Group size limit
The limit is inclusive and applies both to the size of the booking **as it stands** and to the **new** size the guest picks. With a maximum of 6:
* a table of 6 or fewer can change their booking online, up to 6 people. On the modification page, the party-size buttons stop at 6; picking **7+** shows a message asking the guest to contact you for a larger group;
* a table of 7 or more cannot change their booking online and has to contact you.
When you switch **Limit modification to group size** on, the maximum starts at **1**. If you save right away, only bookings for one person can be modified online. Enter your real limit before clicking **Save**.
A 2 to 3 hour threshold suits most restaurants: it leaves time to replan the room. For large groups, set a limit around the size where you start combining tables (for example 8), so those changes always go through your team.
## Cancellation reasons
The **Cancellation reasons** section is the list guests choose from when they cancel on the portal.
* **Add a reason** adds a line at the bottom of the list.
* Each reason can be written in several languages (FR, EN, DE, ES, PT, IT) with the language field. At least one language must be filled in, otherwise **Save** stays disabled.
* The trash icon at the end of a line removes that reason.
New restaurants start with 14 ready-made reasons, such as "I am no longer available", "I booked by mistake", "I booked at the wrong time" and "The price is too high". Edit or remove them as you like.
**What the guest sees.** When the guest cancels on the portal (from their reservation page, the modification page, the payment page, or an activity booking), a confirmation dialog shows a **Cancellation reason** drop-down with your reasons followed by **Other reason**. **Other reason** is selected by default, so giving a reason is optional. Each reason is shown in the guest's language. If it has no translation in that language, English is shown, then French, then any language that is filled in. If your list is empty, the guest only sees **Other reason**.
**What your team sees.** The chosen reason is saved on the reservation. It appears as **Cancellation reason** in the reservation form and on the reservation's line in the list once it is canceled. Removing or rewording a reason later does not change reservations that were already canceled.
Keep the list short (5 to 8 reasons) and specific. "I want to modify my reservation" coming up often means guests do not know they can change their booking themselves: check that **Allow reservation modification** is on.
## Default values
For a new restaurant:
| Setting | Default |
| - | - |
| **Mandatory email** | On |
| **Mandatory email internally** | Off |
| **Mandatory phone number** | Off |
| **Mandatory phone number internally** | Off |
| **Automatic customer matching** | On |
| **Allow anonymous customer** | On |
| **Allow reservation deletion internally** | On |
| **Show total paid** | Off |
| **Allow reservation modification** | On |
| **Maximum modification threshold in hours** | 1 |
| **Limit modification to group size** | Off |
| **Cancellation reasons** | 14 standard reasons |
## Related pages
Every field of the staff create / edit form, including the customer section.
The custom message on your portal and the large group message.
Refuse online bookings from specific guests.
Which confirmation, modification and cancellation messages guests receive.