To prevent missing or duplicate reminders during a reservation system switch, assign each scheduled reminder to one sending system. Use the reminder’s due time—not just the reservation date—as the dividing line. Then check pending messages, booking changes and send failures on both sides of that line.
The switch is not complete just because future reservations appear in the new calendar. A reminder may already be queued in the old system, while the new system may schedule another as soon as the booking is added. Decide who owns each message before enabling the new schedule.
Draw both reminder schedules against the switch time
Start with a single cutover time, including the restaurant’s local time zone. Write down every reminder you intend to send, such as a message one day before a booking and another on the day of service. For each one, identify its scheduled send time and the system responsible for it.
A practical boundary is: the old system owns reminders due before cutover; the new system owns reminders due at or after cutover. That rule works only if you can stop or account for messages already queued in the old system and prevent the new system from sending an overlapping message.
Hypothetical example: A restaurant switches at noon local time on Tuesday. It normally sends one reminder 24 hours before a booking and another two hours before it. The table shows ownership for individual reminders, not just whole reservations.
| Booking | Reminder due | Owner | Check before cutover |
|---|---|---|---|
| Tuesday, 1 p.m. | Monday, 1 p.m.; 24-hour reminder | Old system | Check send status; do not schedule another in the new system |
| Tuesday, 1 p.m. | Tuesday, 11 a.m.; two-hour reminder | Old system | Check status before the noon switch |
| Tuesday, 2 p.m. | Tuesday, noon; two-hour reminder | New system | Confirm the old system has no message still queued |
| Wednesday, 1 p.m. | Tuesday, 1 p.m.; 24-hour reminder | New system | Confirm the booking and reminder are ready in the new system |
In this example, a reminder due exactly at noon belongs to the new system. A booking can therefore have one reminder owned by each system. If a reminder is overdue or its status is unknown, do not assume it was sent or automatically send another. Put it on an exception list for a person to resolve.
Ask both vendors how scheduled and queued reminders can be viewed, stopped or rescheduled. Also ask what a status such as “sent” means: accepted for sending, delivered, or something else. If the old queue cannot be stopped or inspected, adjust the cutover plan rather than relying on the clock alone.
Map future bookings to one sender per reminder
Build a worksheet before changing reminder settings. Give each booking a stable reference that staff can match across systems. Record the local reservation date and time, party size, current status and any special requests appropriate to transfer. Add the reminder type, due time, assigned sender and last known message status.
Keep booking identity separate from guest contact details where possible, and limit access to people who need the worksheet. Use authorized access and a supported transfer method. Ask each vendor what can be exported, imported and matched; do not assume the new system will recognize an existing booking or its reminder history.
For each reminder, make one of these decisions:
- Old system sends: Leave it responsible and prevent an equivalent reminder from being scheduled in the new system.
- New system sends: Confirm that the old system will not send it and that the new schedule is ready.
- Hold for review: Use this when a queue or send status is uncertain. Assign a person and a deadline rather than letting both systems act.
Check the booking channels too. A reservation made on your website, by phone or through a discovery service may reach the calendar differently. Ask how channel attribution and subsequent changes are handled, and whether Google bookings are available for your setup. A discovery network and a direct booking tool serve different purposes; a switch does not automatically settle which system can update each booking.
When comparing reservations software, ask vendors to show how a staff member would find an upcoming reminder, identify its owner and stop a duplicate. If a setting applies to every booking rather than an individual message, plan around that limit before turning it on.
Test edits and cancellations across the boundary
A clean ownership list can become outdated as soon as a guest calls to change a time. Decide where staff should enter changes during the transition and how the other system will be updated. Name the system staff should treat as the current booking record at each stage, while still checking the old reminder queue until its responsibility ends.
Before the switch, run simulated checks in a safe practice environment or with sending and dispatch disabled. Use fictional guest details and do not trigger a real card payment, guest message or courier dispatch. If the vendors cannot provide a safe way to simulate a step, review that step with them rather than trying it on a real guest.
Walk through these cases and record the expected result before each check:
- Time change: Move a booking so its reminder falls on the other side of the cutover. The old reminder should not remain active alongside the newly assigned one.
- Cancellation: Cancel a booking with a reminder pending. Confirm that the responsible system will not send the canceled booking’s reminder.
- Party-size or request change: Update the booking and confirm staff can see the current details. Check whether the reminder itself needs to change.
- Late booking: Add a reservation after cutover when its normal reminder time has already passed. Decide whether to skip that reminder or use an approved staff follow-up, and check that the system does not send unexpectedly.
For each case, an acceptable result is a current booking record, no active duplicate reminder and a clear owner for any intended message. Record unexpected results and resolve them before enabling the affected schedule. Ask the vendor what happens to already queued messages when a booking is edited or canceled; changing the calendar alone may not answer that question.
A simulation checks the workflow without contacting guests. A live service pilot is a separate, deliberately enabled period using real bookings. If you choose one, give the shift lead a short list of messages to monitor, agree on escalation contacts and be ready to pause the affected schedule. Do not describe a simulated result as proof that every live message will arrive.
Reconcile sends and assign an escalation owner
Choose one cutover owner before the switch. That person does not need to send every message, but should be able to see the worksheet, reach both vendors and decide who handles an exception. Give the floor team a backup contact for evenings and weekends.
Review the worksheet at cutover and again before the next service. Compare the reminders due in that window with the old and new systems’ available statuses. Reconcile by booking reference and reminder type, not just by total counts: matching totals can hide one missed message and one duplicate.
For each exception, record the booking reference, reminder due time, assigned sender, observed status, owner, next action and resolution. Separate a confirmed failure from an unknown status. If a send failed, the owner should first check whether another attempt is already queued. Then follow the restaurant’s agreed process for a manual follow-up or a retry. If the status cannot be established, avoid an automatic resend and escalate promptly.
Set an operational deadline tied to service. A reminder for tonight needs attention sooner than one for next week. Once an exception is resolved, update the sheet so the next shift does not repeat the action. Keep reviewing until all old-system reminders in the transition window are accounted for and the new schedule is operating as intended.
Reminders are one part of a wider no-show plan. For other questions to ask about the cost of empty seats, see the guide to measuring reservation no-shows. Also make sure the person responsible for reminders can coordinate with the team handling the rest of restaurant management.
Before choosing a switch date, take your reminder worksheet to both vendors and ask them to walk through queue controls, changes and failure handling. To compare the workflow and current product fit with Fleksa, discuss your requirements.
Frequently asked questions
Should the cutover boundary use the booking time or reminder time?
Use the reminder’s scheduled send time to assign its sender. One booking can have reminders on both sides of the boundary, so assigning the whole booking to one system can leave a gap or overlap.
What if the old system cannot confirm whether a reminder was sent?
Mark the status as unknown and assign an owner to investigate. Check for pending retries or queued messages before deciding whether a manual follow-up is appropriate.
When should we turn off the old system?
Agree on the timing with the vendor after accounting for its remaining reminders and any booking changes still reaching it. Keep access long enough to resolve the transition window, subject to your agreement and operational needs.
