Who gets told what
What this is for
Restodesk sends messages on its own — to customers, to you, and to your staff. This page is the complete list and the thinking behind switching each one on or off.
The messages
| Notification | Goes to | When |
|---|---|---|
| New Order Received | Restaurant admin | A customer places an order. |
| Reservation Confirmation | Customer | They make a reservation. |
| New Reservation Received | Restaurant admin | A customer books a table. |
| Order Bill | Customer | You send them the bill. |
| Menu PDF Email | Whoever you send it to | You email your menu. |
| Staff Welcome Email | New staff member | You add them. |
| Send OTP | Customer | They sign in or verify an account. |
| POS Machine Registration Request | Restaurant admin | A device requests POS access. |
Each is switched on or off individually under Settings › Notifications.
The Menu PDF email also carries a send time, since it's the one that can be scheduled rather than triggered.
Deciding what to switch on
The default instinct is to enable everything. Resist it — a notification nobody reads trains people to ignore the ones that matter.
Always on:
- Send OTP. Customers can't sign in without it.
- Staff Welcome Email. New staff need their details.
- Reservation Confirmation. A guest with no confirmation rings to check.
Usually on:
- New Order Received, if orders arrive from your website or QR codes and someone needs to notice at 7:42 pm.
- New Reservation Received, for the same reason.
- POS Machine Registration Request, if you run multiple terminals — a device waiting for approval is a queue forming.
Only if you use it:
- Order Bill, if you actually email bills.
- Menu PDF Email, if you send your menu out.
The channels
The same message can travel four ways, and they're configured separately:
| Channel | Notes |
|---|---|
| Always available. Needs mail configured. | |
| Push notifications | Browser and device alerts for staff. |
| Add-on. Where your customers actually are. | |
| SMS | Add-on. Reaches anyone, costs per message. |
Choosing a channel per message
Match the channel to the urgency and the audience.
For staff, urgency matters most. A new order needs someone to notice. Push beats email — email is checked when someone remembers.
For customers, reach matters most. An email confirmation is fine and free. An OTP that has to arrive in ten seconds is better by SMS or WhatsApp.
A pattern that works:
| Message | Channel |
|---|---|
| New order | Push to staff |
| New reservation | Push to staff, email to customer |
| OTP | SMS or WhatsApp |
| Order status updates | WhatsApp if you have it, otherwise nothing |
| Bill, menu PDF |
Order notifications for staff
Separately, under Settings › Order Notification, you can hide new order notifications for a specific role.
That's for roles who genuinely don't need them — kitchen staff working a screen already see the tickets, and a notification for every order is noise on top of the work.
Turn it off per role rather than globally, so the people who need to notice still do.
Before you rely on any of it
Test each one you switch on. Place a real order, make a real reservation, add a test staff member. Then check it arrived.
Notifications fail quietly. Nobody reports the message that never came — they just don't get it, and you find out when a customer complains about a booking you never confirmed.
Re-test after any change to your email settings or your domain.
Good to know
- Notification settings are per restaurant.
- Email settings are separate from these switches. A notification that's on but with no working email configured sends nothing. See Email.
- Some notification types only appear when the matching add-on is on your plan.
- Customers can also see order progress themselves without any message — see Customer accounts and addresses.