Bookings and POS connected: what changes when the floor and the till talk

In almost every restaurant that takes bookings seriously, there are two screens that don’t talk. One holds the bookings: who’s coming, when, how many. The other is the till: which tables are open, what’s been ordered, what’s been paid. Between them sits a person —usually whoever is on the door— acting as translator.

It works, until it doesn’t. This article is about where that translation breaks and how we solved it by connecting Reserver with Comanver, the POS built by the same team.

Where two separate systems break

The table that was “free”

It’s 9:20 pm. Table 7 is empty on the till and a couple walks in without a booking. They sit down. At 9:30 the party of four that had that table since Tuesday arrives. Nobody made a mistake: the till didn’t know the table was committed, and the diary didn’t know someone had sat there.

The diary that lies

The reverse happens too. The booking system thinks table 12 frees up at 10 pm because the 8 pm booking “should” be done by now. But they’re on their second coffee, nobody has asked for the bill, and the system has just offered that table to another booking.

The status nobody updates

Did the booking arrive? Sit down? Leave? In practice, updating statuses by hand mid-service is the first thing that gets dropped. And without those statuses, your occupancy, table-turn and no-show reports are built on incomplete data.

The spend nobody sees

Knowing a guest has been in six times is good. Knowing what they spent each time is better. But that number lives in the till, and the booking record never hears about it.

Who owns what

The temptation when connecting two systems is to make both know everything. That usually ends in conflicts: two sources of truth that disagree, and nobody knows which one wins. We started from a clear split:

• Reserver owns the bookings. Who’s coming, when, and at which table. The POS reads them.
• The POS owns occupancy. Which table is open right now, and whether it has asked for the bill. Reserver reads it.
• Seating and closing a booking are specific commands the POS sends when it opens or pays a ticket linked to it.

With that split, each system stays in charge of its own data —including its own floor plan— and each piece of information travels in one direction only.

How it works, step by step

1. The booking reaches the floor

Today’s bookings appear on the POS floor plan and in the waiters’ app. Shortly before the booking time, the table is marked reserved, so nobody seats a walk-in there. If the guest is running late, the table stays reserved for a configurable grace period.

2. The guest sits down

Tap a reserved table and the POS asks “Is this the booking for…?”. It might not be —sometimes a walk-in arrives first— so the waiter decides. If it is, the ticket opens with the tables, party size and name already filled in. In Reserver, the booking moves to “At the table”, without anyone touching the booking dashboard.

3. Occupancy flows back to Reserver

While the table is open, Reserver knows. Today’s floor plan shows which tables are occupied at the till (and which have asked for the bill), and auto-assignment stops offering those tables to bookings in the next few hours. No more offering a table mid-dessert.

4. The guest pays

When the ticket is paid, the booking moves to “Finished” and stores the actual spend (“POS spend” on the booking record). If the ticket is voided without payment, the booking goes back to its previous status, as if it had never been seated.

What you don’t see: reliability

An integration between the till and another system has one non-negotiable rule: the till must never stop. That’s why:

• Everything the POS sends to Reserver is queued. If the connection drops, tickets still open and get paid, and sync completes as soon as it’s back.
• The POS keeps a local copy of today’s bookings. If Reserver doesn’t answer, the floor keeps rendering from the last copy.
• Everything resyncs every 5 minutes, even if a notification was lost. And if a POS is switched off, its tables don’t stay “occupied” in Reserver forever: the occupancy snapshot expires on its own.
• The link is authenticated with a key generated in Reserver and shown only once, and notifications from Reserver to the POS are signed.

How to set it up

1. In Reserver (Pro or Plus plan), go to Settings → POS and create the POS key.
2. In Comanver, with the Reservations module active, paste the key. Comanver shows you a notification URL and secret to paste back into Reserver.
3. Pair the tables. Comanver suggests pairs by name (“Table 05” with “table 5”). If you’re starting fresh, you can import the whole Reserver floor plan, with zones, tables and positions.

It takes a few minutes. From then on, the next booking that comes in already shows up on the floor.

What it doesn’t do (yet)

• It doesn’t merge the two floor plans. Each system has its own designer. If you move tables in Reserver after importing, they won’t be repositioned in Comanver.
• It doesn’t charge the booking upfront. Deposits and pre-auths are still handled by the Stripe integration.
• It only works with Comanver. If you use another POS and want something like this, tell us which one: we prioritise based on what we’re asked for.

In short

Connecting bookings and till isn’t about having more data; it’s about the person on the door no longer acting as translator. A reserved table shows as reserved where guests are seated, an occupied table stops being offered to another booking, and statuses update themselves.

All the technical details are on the Comanver integration page, and how Reserver models your floor is in Floor & tables.