An unanswered reservation is usually a lost evening, not a bad guest
A reservation for six people on Friday night is a promise for the floor manager. Waiters prepare the table, the kitchen counts portions. A queue of couples without reservations waits at the door. The guest who didn't show up and didn't respond takes that evening away forever. The guest is usually not to blame - it's the lack of a reservation confirmation process. A good process confirms the guest's presence before the table disappears from the schedule.
Before confirmation even comes into play, many establishments lack a place where a reservation can be recorded.
A table inquiry then goes nowhere except into the memory of the person who took the phone call.
What the confirmation chain looks like: reservation → SMS → phone → table release
- 01Reservation
- →02confirmation SMS
- →03reminder the day before
- →04phone on the day of the visit
- →05decision to release the table
The first SMS is sent automatically by the system, immediately after the reservation is saved in the reservation system. The second message, the day before, reminds the guest of the time and the number of people. If the guest doesn't respond by the agreed time, the floor manager or receptionist makes a call. Only a lack of response to the third contact gives grounds to release the table to someone else.
Reservation Accepted: {data}, {godzina}, {liczba osób}
Reminder about tomorrow's reservation. Reply YES to confirm.
First message goes after saving reservation, second the day before. Number of steps and intervals are property settings, not measurement result.
The number of steps and the intervals between them are settings to be agreed with the establishment, not a measurement result - we don't have a study that would give one correct number here. If after a month reservations still wait unanswered until the last moment, the chain isn't working. Then you need to check the integration of automated messages with CRM, not add another SMS. The metric worth watching from week one is the number of unanswered reservations before service starts.
One thing here regularly breaks: the waiter manually releases the table in the reservation book, but nobody updates the CRM. The system then sends an SMS to a guest whose reservation no longer exists, and a new guest gets a double-booked table. The error is visible in complaints at the entrance, not in a report - that's why the floor manager should check the CRM change log once a day, not just the paper schedule.
Who monitors whether the chain works at all? In practice, it's the floor manager, because they have access to CRM and see the schedule live. The owner receives a report on this - not daily, just a weekly summary - and on that basis decides whether the prepayment threshold needs to change.
Who and what manages the reservation: roles and tools
The process is usually the responsibility of the floor manager, not the owner personally. The owner sets the rule, the floor manager enforces it daily based on data from CRM, not shift memory. Confirmation messages are sent by CRM connected to SMSAPI or WhatsApp Business, depending on which your guests use. The scenario that connects a reservation with the sending is usually built in n8n - this tool lets you connect the reservation system to the floor calendar without writing the integration from scratch. The deposit, if the establishment collects it, goes through BLIK or Przelewy24, and the payment confirmation automatically closes the reservation in the system.
- Room phone
- Booking system
- Message from guest
- CRM — reservation card
- SMSAPI or WhatsApp Business
- Task for hall manager
- BLIK / Przelewy24 — deposit
This can be a directory, a reservation portal, or a social media profile, without their own page to record a reservation. The guest's phone number that goes into CRM is personal data - its storage is subject to GDPR, and we write about where such data physically ends up separately.
How much implementing the confirmation chain costs
Automated messages — SMS and WhatsApp sent without receptionist involvement — guard a booking that already exists. The reservation system that sees the entire table schedule and blocks dates itself makes sure that booking is created correctly in the first place. Integration with Telegram or WhatsApp opens the channel the guest actually replies on. These are three links of one confirmation chain, and the scope is settled after a conversation about how that chain works today.
There is nothing to add up here. The messaging module and the reservation module guard two different moments of the same visit, and the order depends on where more tables are lost today: at the booking or at the reminder.
Prepayment as a boundary: when to request a deposit
Prepayment doesn't eliminate no-shows, but it sets a limit on the risk. A reservation without a deposit is a declaration. A reservation with a deposit is a decision the guest has already paid for. For a table for two, a deposit usually doesn't make sense - the cost of payment processing exceeds the risk. For group reservations, communion, or a special event with a set menu per person, a deposit protects the kitchen from purchasing products for a guest who won't show up.
The threshold from which you collect a deposit is the owner's decision, not the system's. The system only ensures the rule is the same for each type of reservation.
When it doesn't make sense: small establishments and walk-in reservations
The confirmation chain makes sense where reservations flow from several channels at once and nobody has time to manually call every guest. In a bistro with eight tables, where the owner knows guests by name, an additional system is often unnecessary - phone and memory are enough, and automation just adds another tool to maintain. We don't promise that SMS alone will reduce empty tables - it also depends on whether anyone actually reacts to the guest's lack of response.
Walk-in reservations made for the same half-hour also don't need a chain. What matters then is table availability at that moment, not confirmation in advance. A broader overview of what's worth automating in gastronomy and what's better to leave to people is described in the restaurant automation text.
The confirmation chain won't fix a wrongly-sized table either, or a guest who books for six people and arrives with ten. It won't replace a conversation for special occasions - a communion or a banquet - where the menu and the room require arrangements, not an automated reminder.
Frequently Asked Questions
Does prepayment solve the no-show problem?
Not fully. A deposit limits the number of reservations abandoned without a word, because the guest loses money, but it doesn't change the situation where someone really can't come and doesn't inform. That's why we combine prepayment with an SMS reminder rather than treating it as the only protection.
How much does implementing the confirmation chain cost?
It depends on how many links of that chain have to be closed: sending the messages is one thing, a schedule that blocks dates by itself is another. The scope is settled after a conversation about what exactly your confirmation process needs to do.
Is SMS enough, or do you need to call?
SMS handles a normal reservation, but not every situation. The phone remains the last step before releasing the table, for guests who didn't reply to two previous messages. A conversation also gives a chance to hear directly that the guest won't come after all, instead of guessing.
What happens to the guest's phone number after the reservation?
It goes into CRM and is subject to GDPR like any other customer personal data. We write about where we physically store such data and for how long in the GDPR in automation text.
Does this make sense for a small restaurant with a few tables?
Usually not right away. With a few tables and regular guests, the floor manager often remembers reservations without system support. The confirmation chain starts to pay off when reservations come from several channels at once and nobody can keep up manually.
Let's talk about the confirmation chain for your restaurant in Warsaw.