Connect a reservation to a guest profile when the booking details identify one existing record under a rule your restaurant accepts. When a phone number or email belongs to more than one person, leave the link unresolved until a manager reviews it. A plausible match is not the same as a confirmed identity.
The buying decision is therefore about more than whether two systems can exchange data. Ask where the proposed match appears, who can correct it, and whether a correction changes only one reservation or combines entire guest profiles. A host needs a dependable booking list; a manager needs a clear place to handle exceptions.
Map the booking to the right guest record
Start with a sample booking and identify the source of each field. A reservation made on your website might provide a name, phone number, email, date, time, party size, and any request the guest entered. A booking made through another channel may provide a different set of fields. Ask vendors which fields arrive from each channel you use, including Google bookings where available.
The guest profile may already contain a name, contact details, past reservations, and other information your team is permitted to use. The reservation is an event; the profile is a record about a person. Linking them should let staff find relevant history without changing the facts of the booking.
For the following hypothetical example, assume a restaurant receives a website booking for Lena Ortiz, party of three, at 7:00 p.m. The booking contains the email lena@example.com and phone number 555-0104. An existing profile has the same name and email. A second profile, for Mateo Ortiz, has the same phone number but a different email.
The submitted name, email, phone, and party size are booking inputs. The profile details are existing records. The idea that Lena and Mateo share a household phone is only an assumption; the records do not establish their relationship. Nor does the party size mean the other two diners are Lena or Mateo. The reservation contact is the person to match, not every member of the party.
Decide which fields can support a match and which are only clues. An exact email match may be useful, but email addresses can be shared or changed. A name alone is usually too weak for automatic linking. Ask whether the system shows the actual fields used to make or suggest a match, rather than merely displaying a confidence label.
Compare exact and ambiguous matches
Use a worksheet like this before a demonstration. The outcomes below are decision rules for the fictional booking, not claims about any product. They assume the manager has agreed that one exact email match can support a link when no conflicting evidence appears.
| Input or issue | Possible result | Manager’s decision | What to inspect |
|---|---|---|---|
| Lena’s email matches only Lena’s profile | Link the booking to Lena | Accept if the displayed booking details remain intact | Booking record and linked profile |
| Phone matches Mateo; email matches Lena | Flag a conflict or link based on an approved rule | Review before accepting if the rule treats the phone as evidence of Mateo’s identity | Both candidate profiles and match reason |
| Email is missing; phone appears on both profiles | Leave the booking unlinked and request review | Do not choose a profile from the phone alone | Unmatched or exception queue |
| A booking is linked to the wrong profile | Remove or correct the link without merging profiles | Confirm the booking and both profiles remain accurate | Corrected booking and any change history |
The first and third rows lead to different actions. With one accepted exact email match, a direct link may save the host a lookup. With only a shared phone number, an automatic choice could attach the visit to the wrong person. If a vendor cannot hold the second case for review, that limitation may outweigh the convenience of automatic matching.
The conflicting-fields case deserves a specific question: does an exact email take priority, does a shared phone stop the link, or does staff choose between candidates? Any of these approaches needs a visible rule and an owner. The manager should decide whether the behavior fits the restaurant’s tolerance for an incorrect link.
Also distinguish a reservation link from a profile merge. Reassigning one booking should not silently combine two people’s histories. Ask what happens to future bookings and past visits when a contact detail changes. If a correction affects more records than intended, staff need to know before they confirm it.
Put mismatches where a manager can act
Give the host a simple job during service: notice and flag a questionable link, but do not guess which profile is right. For example, the host may see Lena’s booking displaying Mateo’s history. The host can keep the reservation usable for seating while sending the identity issue to the manager through the restaurant’s chosen process.
The manager should review the booking, both candidate profiles, and the reason for the proposed match in one accessible workflow. That might be an exception queue, a reservation detail screen, or an administrative view. The important buying question is whether the manager can find unresolved cases without searching through every booking.
For the fictional case, the manager compares the booking’s name and email with the two profiles. If the restaurant’s approved rule supports Lena’s match, the manager links the booking to Lena and leaves Mateo’s profile separate. If the available fields remain inconclusive, the manager leaves the booking unlinked and resolves it later through an appropriate staff process. The action that prevents a misleading history is to stop the incorrect link, not to delete the reservation.
Agree on who owns outstanding exceptions after a shift and how often they are reviewed. Ask what staff see when they lack permission to inspect or change a profile. A host should be able to flag a problem without needing broad editing access; the manager should have enough access to resolve it. Confirm whether the system records who made a correction and what changed.
Keep the identity check separate from your policy for guest notes. A note’s content may be appropriate while the profile carrying it is still the wrong one. Likewise, a correct profile link does not make every note relevant to every staff member.
Run a vendor demonstration with pass conditions
Give each vendor the same fictional records and ask them to show the workflow rather than describe a generic integration. Use a test environment or another safe simulation. The exercise must not send a guest message, take a real payment, or dispatch a courier. Do not enter actual guest details just to make the demonstration more realistic.
- Show the input. Enter the fictional booking and identify the channel and fields received. Pass if the displayed reservation retains the entered name, date, time, party size, and contact details.
- Show the accepted match. Use the unique email case. Pass if staff can see which profile is linked and understand the rule or evidence behind the link.
- Show the ambiguous case. Remove the email and use the shared phone. Pass if the booking remains available for service without silently attaching it to either profile, and the manager can find it for review.
- Correct a wrong link. Deliberately link the fictional booking to Mateo, then correct it. Pass if the manager can remove or reassign that link without merging the two profiles or deleting the booking.
- Check access and follow-up. Show what a host can flag and what a manager can change. Pass if the manager can identify unresolved exceptions and confirm the result of a correction.
Fail the demonstration against these criteria if an ambiguous booking is silently attached to a profile, the manager cannot locate the exception, or correcting one booking unintentionally combines the profiles. Record any partial result as a condition to resolve before signing, not as a pass. Ask the vendor to name the configuration or outside system needed for each step and whether it is included in the written quote.
Then ask about access and portability: Which roles can view contact details or edit links? Can a manager export reservations and profile identifiers, and in what format? Does an export preserve booking channel, status, and the link between a reservation and its profile? If another system holds the profiles, which side is the source of truth when contact details differ?
For a migration, appoint a cutover owner and ask both vendors for supported, authorized transfer methods. Reconcile reservation counts and inspect booking identity, local date and time, party size, status, and appropriate special requests. A rehearsal can expose mismatches, but it cannot promise an uninterrupted changeover.
Choose a workflow your team can maintain
Favor the option whose matching rules and exception workload fit your staffing. A smaller team may prefer fewer automatic links if it can review uncertain cases quickly. A busier operation may accept more automation, but should still require a visible way to identify and correct mistakes. Ask for the expected review steps, not a promise that mismatches never happen.
For context on the wider setup, compare your profile requirements with your restaurant management software and review the Fleksa table reservations workflow. Booking identity is also separate from the operational impact of missed visits; the guide to measuring reservation no-show costs covers that decision.
Next, take the worksheet and demonstration checklist to Fleksa. Compare your requirements with its restaurant reservation system and confirm current support for matching, review, permissions, and export before choosing a workflow.
Frequently asked questions
Should every reservation automatically create a guest profile?
Not necessarily. Ask whether a booking can remain usable without creating or linking a profile, and decide how your team will review duplicates and incomplete records.
Is a matching phone number enough to identify a guest?
It can be a useful clue, but people may share a number. When more than one profile has that number, review other available details rather than choosing automatically.
Where should a manager review mismatches?
In an accessible exception queue, booking screen, or administrative view that shows the reservation, candidate profiles, and reason for the match. Confirm that the manager can correct the link and find cases still awaiting review.
