Drag-and-drop floor plan with live table status.

No, and this is the single most important thing to understand before you put a screen at the host stand. Vertex does not see your dining room. There is no sensor under the seat, no camera, no chip in the tablecloth. Every colour on that floor plan is there because something was recorded: a host seated a party, a server fired an order against a table, a check was closed, somebody tapped a table into the cleaning queue, somebody tapped Mark Ready. Where the action happened but nobody recorded it, the board does not change. A four-top that got up ten minutes ago is still green-for-occupied until a person says otherwise; a table wiped down by a runner who did not open the queue on their way past is still sitting in the dirty column. So read the board as what it is — a shared picture of what your team has told the system, and a very useful one — rather than as a reading of the room. The uncomfortable part is that the gap opens widest exactly where you least want it. On a quiet Tuesday everybody taps, because there is time to. At half past seven on a Saturday, with a section down a server and three parties at the door, the tap is the first thing to go, and that is precisely the hour when the host stand is leaning on the board hardest to decide who gets seated next. Nothing in software fixes that; what fixes it is deciding whose job the tap is, keeping it to one action at the moment it naturally happens, and having the host confirm with their own eyes before they walk a party across the room on the strength of a green square. The same caution applies to the cleaning queue: the elapsed dirty time is the time since somebody flagged the table, not the time since the guests actually left, and if the flag went in late the clock understates it. Treat any table state as a claim made by a colleague a few minutes ago, which is roughly what it is, and build your service around checking rather than trusting.

"Real-time status", "live table state" and "updates go live instantly" are the design's own phrasing, and it is worth translating them into something you can plan around rather than repeating them back to you. What they describe is a change made on one device becoming visible on the others: a host seats a party on the stand tablet, and the intention is that the terminal on the pass and the screen in the back office show that table as occupied without anybody refreshing anything. That propagation runs over your venue's network and out to devices that are switched on and connected. Everything that is ordinarily true of a restaurant network is therefore also true here. A tablet on a patio at the edge of the wireless, a terminal somebody powered down at the end of the shift, a line that drops while the building's connection is being worked on — none of those receive an update while they are out of touch, and what is on their screen is what was true when they last heard anything. This page does not state a sync interval, a push mechanism, a retry behaviour or an offline mode, so we are not going to describe one to you; if the behaviour of a device that loses connection mid-service matters to how you would run the room — and in most rooms it does — ask sales for it specifically and get the answer in writing before you design a routine around it. There is also a second sense of "real time" hiding in the same words, and it is the weaker one. Figures like the average turn time are computed from what was recorded, so their timeliness is capped by the timeliness of the taps described in the previous answer, not by how fast the network is. A turn time is only the interval between two moments somebody logged. The design's line that you will "never lose track of table turn times again" overstates it: what you get is a consistent record of the times that were entered, which is a genuine improvement on a paper book and a memory, and is not the same thing as never losing track.

Zones are how you cut the drawn room into the areas you actually talk about at pre-shift. The design shows a main dining area, a bar zone, a kitchen and a service aisle marked on the canvas, and names the patio and the bar as examples of areas you would define; the change log in the publishing panel refers to adding high-tops in the Bar Zone and adjusting VIP table spacing in Main Dining, which is roughly how a real week of edits reads. Practically, a zone is a boundary you draw and label, and its value is that everything downstream can then speak in the same terms — a status count for the patio means something once the patio exists as a shape rather than as a thing everyone knows in their head. Table identity is what stitches the two halves together. Each table you place carries an ID you set in the editor, and the design notes on the layout screen that those IDs connect to the live status board, which is the mechanism behind a T12 on the plan being the same T12 the server fires an order against. That is worth taking seriously when you name things: use the numbering your team already says out loud, keep it stable, and think twice before renumbering a section mid-season, because every printed cheat sheet, every habit and every conversation across the pass is keyed to the old names. On servers and stations, be clear about what an assignment is and is not. Splitting the room into sections and putting a name against each one is a plan for the shift, and having it on a screen that the host stand, the floor and the manager all see beats having it on a whiteboard by the door that half the team never walks past. It does not enforce anything. If a server picks up a table two sections over because they were closest and the guest caught their eye, the room worked correctly and the plan is now slightly out of date — which is fine, and is exactly why the plan is a communication tool rather than a rule. The page shows no scheduling, no payroll and no tip-distribution behaviour attached to sections; if you want a section assignment to drive any of that, treat it as a separate question for sales rather than an assumption.

Real upkeep, and you should budget for it, because a floor plan that has drifted from the room is worse than no floor plan at all. A host trusting a stale layout will walk a party to a two-top that is currently part of a fourteen-cover private table, or hold back a section that was struck last week; a whiteboard at least looks provisional, whereas a screen looks authoritative and gets believed. Whoever owns the room needs to own the drawing, and the moment to update it is when the furniture moves, not the following Tuesday. The design does give you a sensible way to do that mid-week. Changes are built as a draft in Design Mode rather than applied straight to the floor, you review a change log summarising what altered — the example reads "Added 2 high-tops in the Bar Zone. Adjusted VIP table spacing in Main Dining" — and then confirm the publish when the timing suits, with the panel noting the draft is ready for Saturday lunch service. That is the right shape for a working restaurant: you can lay out next month's patio configuration on a Monday afternoon without the host stand suddenly showing tables that do not exist yet. Some practical habits make it survivable. Keep one layout per genuinely distinct configuration rather than nudging a single plan back and forth, so the standard Saturday service is a thing you publish rather than a thing you rebuild. Write the change log for the person reading it at the host stand, not for yourself. Publish between services rather than during one, and tell the floor when you have, because a plan that changes under someone mid-shift is disorienting in a way that costs more than it saves. And accept that a one-off — the twelve-top assembled from three tables for a birthday, then broken up at the end of the night — is often better handled as a verbal brief than as a published layout, since the effort of drawing it and unwinding it exceeds the value of having it on a screen for four hours. The tool is worth the maintenance for the configurations you run repeatedly. It is not worth the maintenance for every improvisation, and pretending otherwise is how plans go stale.

On hardware, we are not going to specify anything from a marketing page. The comp shows the editor and the status board on unbranded tablets and a counter terminal, and that is an illustration of the kind of surface this is used on, not a compatibility statement — no model, no screen size, no mounting arrangement, no wall display and no minimum specification is stated anywhere on this page, and inventing one here would be doing you a disservice. What you can reasonably assume is that a floor-plan editor wants a screen big enough to work on comfortably and a status board wants to be readable from a step or two away at the host stand; everything past that — which devices are supported, what happens on the specific terminals you already own, what the host stand actually needs — is a procurement question with a real answer, and it belongs with sales before you buy anything rather than in a paragraph here. Ask it in writing, and ask it about the devices you have, not the devices you might buy. On the booking side, this page names no third-party reservation platform, no directory and no marketplace, so we are not going to imply a connection to one. What it does show is inside Vertex: tables in a reserved state on the live floor plan with a time against them, a benefit tile reading "Reservations — sync guest books", and a hero line about seeing live reservation, seating and service states in one workspace. That describes the floor plan being aware of Vertex's own bookings, which is a different and much smaller claim than a feed from an outside platform. If you take covers today through a booking site and you need those reservations to colour tables on this plan, that is a genuine integration question — ask what is supported, in your market, in writing, and confirm it before you sign rather than after. It is also worth asking what happens the other way: whether a table you merge, split or renumber in the editor is understood by whatever holds your bookings, because the failure mode people actually hit is not a missing integration but a half-integration that quietly stops matching after somebody rearranges the room.