What should restaurants confirm before going live with HETable?

Before going live, most restaurants should confirm the published floor plan, booking settings, section and assignment readiness, the host screens for service, and any guest-facing booking, self-seat, or kiosk paths they want to expose.

Which teams should know what to open on launch day?

Managers usually confirm setup and controls first. Hosts work from Host Stand, Reservations Manager, and Wait Board. Floor teams use station assignments and Pocket View. Guests use public booking, confirmation, self-seat, or kiosk flows only where the restaurant enables them.

Does the go-live checklist include integration and security review?

Yes. Operators should review permissions, audit visibility, API keys, webhooks, and security-policy settings before launch whenever those controls are part of the rollout.

HETable go-live checklist

Use this final launch checklist before your first live shift

This page is designed for the last review before you go live. It keeps the launch sequence practical: confirm the room, confirm role workflows, decide what guests can access, review controls, and then open the shift with the right screens in front of the right people.

Start with the rollout guide See the real screens by role

1. Confirm the room and booking setup

Publish the correct floor-plan version for the room the team will actually run.
Confirm sections, station coverage, and any assignment prep needed before opening.
Review booking settings such as hours, intervals, lead times, and party-size limits.
Make sure the host tools are looking at the live room rather than an outdated draft.

Floor Plan Builder Versions & publish Sections Booking settings

2. Confirm what each role will open during service

ManagerBooking Settings, reports, sections, Smart Assign, locations, permissions, audit, webhooks, API keys, and security policies.

HostHost Stand, Reservations Manager, Wait Board, and the live room view tied to the published layout.

Server / floor teamStation Assignments and Pocket View for follow-through after the host stand decision.

GuestPublic booking, reservation confirmation or cancellation, self-seat, kiosk, and concierge paths only where enabled.

3. Decide which guest-facing paths are live on day one

Not every restaurant should turn on every guest-facing path at the same time. A safer launch is to decide exactly which guest experiences are part of day-one service.

Public bookingUse when reservation intake and confirmation flow are ready for live guests.

Self-seatUse only when the room, party-size fit, and guest-led arrival workflow are ready to be trusted live.

Guest kioskUse when the arrival experience, table suggestion logic, and waitlist fallback are part of the service model.

Waitlist / Wait BoardUse when hosts need a live queue and clear quoted-wait visibility during service.

4. Review control, security, and integration settings

PermissionsConfirm who can change settings, run admin workflows, or override sensitive actions.

Audit visibilityMake sure operators know where to review important admin activity after launch.

API keys + webhooksReview any integration surfaces that are part of the rollout so launch-day behavior is predictable.

Security policiesReview idle timeout, IP allowlist, and brute-force lockout settings when those controls matter for the operation.

5. Launch in this order

Manager review: confirm room, rules, staffing, permissions, and any location-level settings.
Host review: confirm Host Stand, Reservations, Wait Board, and live room visibility before guests arrive.
Floor-team review: confirm station assignments, sections, and Pocket View access if used on the floor.
Guest-channel review: expose only the guest-facing paths the restaurant actually wants live on day one.
Post-shift review: use reports, moves, audit, and oversight screens to tighten the next shift.

Direct answers

What is the safest way to launch HETable?

The safest launch is to confirm the live room, booking rules, staffing workflows, and role-specific screens first, then expose only the guest-facing paths the restaurant actually wants on day one.

Should every restaurant enable self-seat and kiosk immediately?

No. Restaurants should enable guest-led arrival paths intentionally. Many teams launch with host-led booking, reservations, and waitlist first, then add self-seat or kiosk flows once the operation is comfortable.

What should managers review after the first live shift?

Managers should review reports, table moves, reservation outcomes, assignments, audit activity, and any security or integration settings that need tightening after real service.

Getting started with HETableSee the rollout order most restaurants follow before this final launch check. What teams open in HETableConfirm which screens each role should actually use during service. HETable engineering overviewReview technical boundaries, integrations, and controls with an engineering-friendly lens. Integrations and securityReview the admin-grade controls that surround the workflow.