To identify where reservations come from without counting them twice, give each reservation one booking identity and assign it one reporting source. Keep the records that show how it arrived, but count the reservation only once. When the source is unclear, mark it unresolved rather than guessing.
That distinction matters when a reservation appears in a partner report and in your restaurant's booking system. Both records may be useful, but adding their totals together can make one party look like two. A good buying decision depends on whether the software can help you connect those records and explain the resulting count.
Decide what a booking source means
Start with a definition your staff can use consistently. For a basic source report, the channel is where the reservation was created: your direct website, a phone call entered by staff, or a partner booking path. Ask how the system records each one and whether that information stays attached to the booking when someone edits it.
A booking ID is the anchor. It should identify one reservation through its changes, even if the reservation also has an ID in a partner system. If the two systems use different IDs, you need a reliable link between them. Guest name and time can help staff investigate a possible match, but they are not proof: two parties can share a name or book the same time.
Separate what you observed from what you inferred. A record showing that a staff member entered a phone reservation is an observation. A guest saying they first found the restaurant on social media may be useful marketing context, but it does not make social media the booking channel under this definition. If you want to measure discovery as well, keep it in a separate field rather than replacing the booking source.
Also decide what the count represents. A reservation is one guest party, not one person and not necessarily one physical table. A party of six may need two tables, but it is still one reservation. Source reports should not be treated as table-capacity reports.
A restaurant reservation system may be one part of this workflow. Before choosing one, ask which source values it records automatically, which staff can enter, and how partner records are linked. If Google bookings are available for your setup, ask how those reservations appear in the same report.
Use a worksheet to correct a duplicate
The following example is hypothetical. Assume the restaurant reviews reservations created during one week, including those later canceled. Each row below is a system record, not necessarily a separate reservation. The partner record for B204 and the direct-system record for B204 have an explicit shared link. Assume the partner created that booking and the direct system received a copy.
| Record | Observed input | Reporting source | Count |
|---|---|---|---|
| A101 | Website booking | Direct website | 1 |
| A102 | Website booking | Direct website | 1 |
| P103 | Staff entry from a call | Phone | 1 |
| B204, partner record | Created on partner path | Partner | 1 |
| B204, direct-system copy | Linked to partner record | Partner, already counted | 0 |
The worksheet contains five records but four reservations: two direct, one phone and one partner. If the owner simply adds the direct-system copy as another website booking, the report shows five reservations and overstates the direct channel by one. The correction depends on the explicit link and the agreed rule that creation channel gets the credit.
Now compare two possible demonstration outcomes. In the first, the vendor shows the link, retains the partner as the creation source, and exports four unique bookings with the duplicate identifiable. That supports using its report for this definition. In the second, the vendor shows five unlinked records and cannot identify the copy in an export. The owner would need a separate reconciliation process or a different reporting solution; the displayed channel totals alone would not be enough.
If B204 had no reliable link, do not automatically merge it based on a matching name and time. Flag the possible duplicate, investigate it, and keep the source or identity unresolved until the evidence is sufficient. Your report can show a provisional total and an unresolved count instead of presenting an uncertain number as final.
Marketplace discovery and direct booking are different paths. OpenTable offers reservations, restaurant operations and a diner discovery network; a direct website booking starts on the restaurant's own site. Ask each provider how channel attribution, permissions, exports and fees work for your setup. Neither path should be credited merely because its report contains a copy of the reservation.
Protect the count when reservations change
Edits create another opportunity to inflate a report. Suppose a guest changes the time or party size. Under the worksheet's rule, that is still the same reservation and keeps the same booking identity and original creation channel. A changed value should not create another booking in the source total. Ask whether the export provides a current record, a change history, or both, and how to tell an update from a new reservation.
Cancellations require a separate choice. A report of bookings created during a week can include reservations that were later canceled. A report of active reservations for a service date should exclude canceled bookings. Neither number is inherently wrong; the heading and filters must make the difference clear. Keep status with the booking ID so staff can reconcile the two views without counting a cancellation as another reservation.
Assign the floor manager or reservations lead to review exceptions before the report is shared. That person checks possible duplicates, missing sources, changed IDs and unexpected status changes. The practical fix may be to link records, correct an entry through the supported workflow, or leave an item unresolved with a note. Avoid silently deleting a record just to make totals agree; preserve enough detail to explain the adjustment.
For operational context, compare the report with the reservation workflow staff actually use. Fleksa's table reservations documentation can help frame questions about that workflow. Separately, a guide to reservation no-show costs can help when you want to examine attendance. Source attribution and no-shows answer different questions and should not be combined into one unexplained number.
Set a pass-or-fail demonstration
Bring your definition and a small fictional dataset to the vendor. Request an export with the booking ID, any linked external ID, creation date and time, reservation date and local time, party size, source, current status, and a way to identify updates. Ask what each field means, which values staff can change, and whether the export includes canceled reservations. If a field is unavailable, agree on a documented alternative before relying on the report.
Have the vendor demonstrate the following in a simulated environment. The exercise must not send a real guest message or trigger a real payment or courier dispatch.
- Create fictional direct, phone and partner bookings, or use prepared fictional records that represent those paths.
- Show a partner booking and its copy in the restaurant system, with the relationship between their IDs visible.
- Change the time or party size of one booking, then cancel another. Show how the identity, source and status appear afterward.
- Export the records and reconcile the raw rows to unique booking IDs. Show the counts by source and a separate count of canceled and unresolved items.
- Have the reservations lead explain any exception and record the action needed before the report is accepted.
Pass: the vendor can demonstrate one count per linked reservation, the agreed source survives the edit, the cancellation is identifiable, and the exported totals reconcile to the unique bookings under the stated filters. Any unresolved item is visible and assigned to the reservations lead. Fail: the demonstration cannot distinguish the linked copy from a new booking, changes the count without explanation, hides the cancellation, or leaves an exception with no owner.
A simulation checks the proposed workflow; it is not proof of how every live booking path will behave. If the demonstration passes, agree on a limited live-service review with staff responsibilities and authorized access before making the report part of routine decisions. Reconcile actual records and investigate exceptions without assuming every channel will behave like the fictional test.
Next, write down your source definitions and export requirements, then compare your reservation workflow with Fleksa. Ask which fields, links and Google booking paths are supported for your setup before choosing a workflow.
Frequently asked questions
Is a website visit the same as a booking source?
No. A visit may explain discovery, while the booking source identifies where the reservation was created. Keep those measures separate unless you have a documented rule for combining them.
Should canceled reservations count by channel?
They can count in a report of reservations created, but should be excluded from a report of active reservations. Label the report and retain the cancellation status so the totals can be reconciled.
Can I merge bookings with the same guest name and time?
Not automatically. Those details can flag a possible duplicate, but different parties may share them. Use a reliable linked identifier or investigate and mark the case unresolved.
