Keep a reservation note for one visit when it describes something the team needs to do for that booking. Keep a preference across visits only when it is useful again, appropriate to retain, and subject to review. Leave out personal details that staff do not need to deliver service.
That distinction matters more than the number of fields on a booking form. A note can be brief and still follow a guest for years, appear to the wrong staff member, or describe a preference that has changed. Your restaurant reservation guest notes policy should say what goes where, who can see it, and how it gets corrected.
Separate a celebration from a seating preference
Start with the service decision. Does the note help with this booking, future bookings, or neither? If a future team could not take a useful action from it, there is little reason to keep it as a standing note.
Hypothetical example: A guest named Maya books a table and says the party is celebrating a promotion tonight. Maya also asks for a quieter table when possible and shares a private story about a coworker. The team should prepare for the celebration on this reservation. A quiet-table preference may be useful on future visits if Maya wants it remembered. The coworker story does not belong in the record.
Use the following sorting guide when writing your own policy. The final column shows the action a host should take, not a promise that every reservation system supports that storage or deletion method.
| Sample note | Category | Decision |
|---|---|---|
| Promotion celebration tonight | Visit only | Keep with this booking for the host handoff; do not make it a standing guest preference. |
| Prefers a quieter table when possible | Reusable, if the guest wants it remembered | Record a short preference where appropriate; confirm rather than promise availability. |
| Private story about a coworker | Do not record | Leave it out; it does not help staff serve the booking. |
| Needs a step-free route for this visit | Visit only unless the guest asks otherwise | Share the practical seating requirement with the staff arranging the visit. |
| Staff member's opinion about a guest | Do not record | Remove subjective labels; escalate an operational concern through the restaurant's normal process instead. |
The table also shows why a preference is not a guarantee. A quiet area may be full, or a guest may want a different seat when dining with a larger party. A standing note should prompt a question, not override the request for the current visit.
For food allergies or other dietary needs, write an actionable service request rather than unnecessary medical history. Follow the restaurant's food-safety procedures and confirm what the kitchen can accommodate. Do not assume an old note is complete or current. If the guest wants a dietary preference remembered, decide who can record it and how it will be confirmed on future visits.
Compare visibility and retention controls
The policy must fit the software and the way your team works. A reservation note, a guest profile, an exported list, and a printed shift sheet can each have a different audience and lifespan. Ask where a note appears after it is saved, not just where it is entered.
For a hypothetical review, imagine that a host needs to see Maya's celebration request before seating the party, while a manager handles corrections to standing preferences. Ask the vendor whether those roles can have different access, and whether a visit note can stay on the booking without also appearing as a permanent profile note. If the answer is no, decide whether a narrower note or a different workflow can meet your policy.
Walk through these questions with each vendor:
- Placement: Can staff distinguish a note for one reservation from a reusable guest preference? What happens when the same guest books again?
- Visibility: Which roles can read, add, edit, or remove notes? Are notes visible on shared devices, printed sheets, or connected tools?
- Retention: Can the restaurant set a review or removal schedule? What happens to a note when a reservation is canceled or a profile is merged?
- Corrections: Who can update an outdated preference, and can staff tell which version is current?
- Copies: Are notes included in exports or integrations? How can the team find and correct copies that have already been shared?
Ask to see the answers in a demonstration using fictitious records. If a control is important, include it in the written evaluation rather than assuming it comes with a reservations product. Also ask about fees for the workflow you need and compare written quotes on the same terms. For Fleksa's current plan details, see plans and pricing; pricing was checked in November 2026. Confirm current availability and any quote details before deciding.
Trace a request from booking to host handoff
A policy works only if the note reaches the person who needs it in time to act. Trace the request from the booking channel through the shift handoff, including any manual step. Direct website bookings and bookings from other channels may reach the team differently, so ask how each channel displays special requests.
Continue the hypothetical Maya booking. A staff member reads the celebration request, records a short visit note, and checks whether a quiet table is possible. If Maya has asked the restaurant to remember the seating preference, the staff member uses the approved location for a reusable preference, if the system supports one. Otherwise, the team should not assume that the note will be separated or carried forward correctly.
Before service, the host sees the celebration note and checks the seating plan. The handoff might say: “Promotion celebration; quieter table requested if available.” It does not need the coworker story. At arrival, the host can confirm the seating choice without announcing a private note to the party.
Run this as a simulation with fictitious data before relying on the workflow. Create or display a sample booking in an appropriate practice environment, then ask a host and a manager to follow it through their normal screens. Check whether the note appears where each person expects it, whether a change is visible, and whether the visit-only note appears on a later sample booking. Do not send a real guest message, take a real payment, or dispatch a courier during practice.
A live service pilot is different: use the agreed policy with actual bookings, authorized staff, and normal guest communication. Assign a manager to check a small set of handoffs and collect staff feedback. Avoid copying real guest notes into a separate practice file. If the team discovers that a note is missing or too broadly visible, pause and adjust the process before expanding it.
For channel-specific workflow questions, start with the reservations FAQ. Ask the vendor how requests arrive from your website and, where available, Google bookings. Confirm what the host can see and edit for each channel rather than assuming every source passes the same information.
Review and correct notes before they go stale
Give one role ownership of the policy and name a backup. That person does not need to read every guest record. They do need to set a review rhythm, train staff on appropriate wording, and decide how corrections move through the systems the restaurant uses.
For visit-only notes, define when the operational need ends and what staff should do if the software cannot remove the note on your preferred schedule. For reusable notes, set a review interval that suits your operation and the controls available. A preference should be reconfirmed when it affects a decision, particularly if it conflicts with the current booking.
Suppose Maya later says the quiet-table preference is no longer important. The host should follow the restaurant's correction process instead of adding a second, contradictory note. The manager should check the current profile and any active booking where the old preference matters. If information was exported or printed, follow the restaurant's process for updating or disposing of those copies too. The exact steps depend on your tools and access permissions.
Train staff to write observations as practical requests: “quieter table if available,” not a personality judgment. If a guest asks what is recorded or requests a correction, route the request to the designated person. Ask qualified advisers about any legal or tax questions that affect your own retention and response process.
As a next step, bring the sorting table and one fictitious booking to a vendor demonstration. Ask the team at Fleksa to show the relevant workflow and confirm current availability for your restaurant in its restaurant reservation system.
Frequently asked questions
Should every special request become a guest preference?
No. Keep a request with the visit when it applies to that occasion. Consider a reusable preference only when it may help future service and the guest wants it remembered.
Who should be able to see guest notes?
Give access to staff who need the information for their work, and check whether the software can support the roles you choose. Review shared screens, exports, and printouts as well as the main reservation view.
What if the software cannot separate visit and profile notes?
Ask the vendor about available alternatives and their limits. If the team cannot reliably keep a note temporary, use a narrower approved workflow or reconsider whether the tool fits your policy.
