Overview
This article describes how to configure Genius for Restaurant to work with the OpenTable reservation management service. OpenTable provides real-time updates from the POS directly into the OpenTable platform. This connection enables restaurant staff to see table status changes and guest ticket information as they happen, making it easier to manage seating, monitor service progress, and access meaningful insights about guests—all within OpenTable.
The integration between Genius for Restaurant and OpenTable is unidirectional; data is only transmitted one way, from the Genius POS to OpenTable. No data is sent from OpenTable back to the Genius POS. For example, reservations or guest notes made in OpenTable will not appear in the Genius POS.
This guide explains how the integration works, what features are supported, and how to use the integration correctly to ensure a smooth experience for both staff and guests.
| Contents |
Connecting a ticket to a reservation
For OpenTable to display information about a ticket from Genius, it must first be able to match that ticket to a reservation. This matching happens automatically, based on a combination of timing and table number.
Once a guest arrives, their reservation should be marked as Seated in OpenTable. After that, the staff should open a ticket in the POS using the same table number assigned to the reservation in OpenTable. They must open this ticket within a specific time range: no earlier than 30 minutes before, and no later than 60 minutes after the reservation has been seated.
If both the table number and the timing are within those parameters, OpenTable will link the reservation to the ticket. Once linked, the table will show as Seated in OpenTable, and additional ticket details will begin appearing automatically.
Aligning table numbers between Genius and OpenTable is critical. If the table name and/or numbers do not match exactly, OpenTable cannot make the connection—even if the timing is perfect. During onboarding or when floor plans are changed, take extra care to ensure both systems are using the same table labels.
Seating best practices
To support the integration and keep information flowing correctly, restaurant staff should follow these seating guidelines.
Guests should also be seated at the same physical table listed on the reservation in OpenTable. If the party is seated across multiple tables, make sure the reservation states that. After being seated, if a guest is moved to a new table, staff should update the table assignment in both OpenTable and the POS.
Finally, we recommend you only open tickets in the POS after a guest is marked as Seated in OpenTable. Avoid opening tickets early, even as placeholders.
Understanding automated table statuses
As guests move through their meal, OpenTable will automatically update the table status based on certain events within the POS. When key actions occur, the POS sends specific table status indicators to OpenTable. The most common statuses are:
- Seated: This status is triggered as soon as a ticket is opened in the POS for a table that matches a reservation in OpenTable.
- Paid: This status appears when the ticket’s balance reaches zero. For split tickets, all parts must be fully paid before the table is designated as Paid.
The Paid status includes discounts, comps, and other adjustments. If any portion of the ticket remains unpaid (regardless of receipt type), the table will not display as Paid in OpenTable. Also, if you void a payment after the ticket’s Paid status is applied, OpenTable will not remove the Paid status.
Note: These table status updates are only visible in OpenTable. They do not appear inside the POS.
Advanced course progression (optional)
In addition to the basic Seated and Paid statuses, OpenTable can also enable and display course-level progression statuses, such as Appetizer, Entrée, and Dessert, along with other table statuses. These are automatically inferred based on the menu items ordered in the POS, using category mapping.
This mapping feature is not enabled by default. To gain access, the location must first meet two requirements:
- It must run at least ten shifts with active POS ticket activity.
- OpenTable must detect a ticket-to-reservation match rate of 85% or higher over a two-week period.
Once eligible, OpenTable uses menu item categories (included in the ticket data from the POS) to determine which course is being served. The POS does not send course status updates directly; OpenTable interprets this from item categorization.
These statuses only move forward. For example, once a table is marked as having received Dessert, it will not revert back to the Entrée status if new entrée items are ordered.
Viewing ticket details in OpenTable
When a POS ticket is linked to a reservation, OpenTable displays several ticket-related details. These details are visible within multiple parts of the OpenTable platform, including the floor plan, the reservation card, and the guest’s visit history.
Staff will be able to see:
- The total amount spent (including taxes and tip).
- The list of items ordered (excluding modifiers).
- Adjusted item prices (if item-level discounts are applied).
- The subtotal (including other charges, but excluding ticket-level discounts).
- The final total (including all service charges and taxes).
- The date and time of the ticket.
- The server assigned to the ticket.
- The POS ticket number.
Note: This information is for viewing purposes only. It is not editable in OpenTable.
Using OpenTable in the POS
OpenTable impacts the following tasks in the POS.
Splitting tickets
OpenTable tracks multiple tickets associated with the same table. A table will only display as Paid once all split tickets are fully paid and closed. If even one split ticket remains open or unpaid, the table will not transition to the Paid status.
Voiding tickets
If you void a ticket after its table is marked as Paid, its status in OpenTable will not change. OpenTable does not retroactively remove a status based on post-ticket changes.
Moving tables
If a party is moved to a different table during service, you should update the ticket’s table assignment within both the POS and OpenTable. Since OpenTable relies on table numbers and timing to maintain accuracy, any mismatches could lead to incorrect associations.
Reusing tables
When a table is closed and reseated, OpenTable handles the transition without issue. If a new ticket is opened for the same table after a prior ticket is closed, OpenTable processes and displays the new ticket separately. The POS flags each ticket as either an “add” or “update,” allowing OpenTable to understand which ticket belongs to which party, even when tables are reused.
Timeliness of updates
Most ticket and status updates appear in OpenTable quickly, especially during initial syncs at the start of a shift. In some cases, ongoing updates (such as payments or ticket closures) may take a few minutes to display in OpenTable.
There is no need for staff to manually push updates or refresh the system. All data is sent from the POS automatically.
Final reminders for staff
To ensure accurate ticket visibility and table updates:
- Always seat guests in OpenTable before opening a ticket in the POS.
- Use the same table number across both systems.
- Open tickets within the permissible time range (30 minutes before to 60 minutes after) of their seated times.
- Bring all tickets to a $0 balance before marking the reservation as Finished.
- If tables or party sizes change during service, keep OpenTable updated.
By following these best practices, staff can rely on OpenTable to display accurate, real-time information that improves visibility, timing, and guest experience.