Reservations and table management without a marketplace

What "real time slots" actually means

A reservation system that just hands a guest a calendar and lets them pick any time isn't really managing your room — it's managing a form. Real time slots are built from rules that reflect how your restaurant actually runs: the largest party you can seat, the minimum notice you need before a booking, and how far in advance you're willing to take reservations at all. A guest picking a Friday night for a party of eight only sees slots that your rules actually allow for that size and date — not every open half-hour on the calendar, regardless of whether your room could handle it.

Confirm, decline, and keep control

Taking the request isn't the same as accepting it. Every reservation you receive is something you confirm or decline from the admin side — which matters on a night where a party size doesn't fit your floor plan, where you've got a private event taking half the room, or where you'd simply rather leave capacity open for walk-ins and regulars. That's a meaningfully different posture than a self-service booking calendar that locks in the moment a guest clicks a button; you keep the judgment call.

No-shows: a policy decision, not a software setting

No-shows are a real cost — a held table that never gets used is lost revenue for that slot, no matter how the reservation was made. There's no single fix built into a booking system that eliminates them, so it comes down to policy choices you make deliberately: how far ahead you'll hold a table without a call, whether large parties need a deposit or a card on file, and how quickly you release an unconfirmed reservation back to the floor on a busy night. What real-time slots and a live table board give you is visibility — you can see which tables are sitting on an unconfirmed hold versus which ones are actually seated, so a no-show gets caught and released rather than quietly costing you a table all night.

The table board: what the floor actually works from

Reservations feed a room, but the room itself runs on the table board — tables, table sessions and table status in one view, plus any requests a seated guest sends from the table. A host glancing at the board can see what's seated, what's free, and what's coming up next from the reservation list, without cross-referencing a paper chart against a separate booking app. That single view is what lets reservations and walk-ins coexist instead of competing — a walk-in gets seated at whatever's actually open right now, reservations get seated at whatever was actually held for them, and nobody has to guess.

Party size limits exist for a reason

Setting a maximum party size isn't about turning business away — it's about being honest with guests before they show up rather than after. A table for six trying to seat a party of ten is a worse experience for everyone at the table than a clear limit stated up front, and it protects your other reservations and walk-ins from getting squeezed by a party your floor plan was never going to comfortably hold. The same logic applies to advance-notice minimums: a same-day request for a twelve-top on a Saturday isn't a problem your system should quietly accept and let you discover at 6 p.m.

Where deposits and cancellation fees can touch tax

If you charge a deposit or a cancellation fee tied to a reservation — common for large parties or private events — how that fee is treated for sales tax purposes can depend on the specifics of what it's for and whether it's later applied to a taxable food purchase. That's worth confirming directly with the Comptroller for your situation rather than assuming it follows the same treatment as the ticket itself.

Walk-ins aren't an afterthought

A room built entirely around reservations tends to treat walk-ins as an inconvenience, and a room with no reservation system at all leaves regulars unable to plan ahead. Running both off the same table board avoids picking one at the expense of the other — the host sees real availability either way, and a party that didn't call ahead gets treated the same as one that did, as long as there's actually a table.