An opening date is not a readiness criterion
A launch calendar describes when work is expected to finish. A readiness register shows whether the business can safely and consistently deliver the promised service. Separate those documents. A completed construction task may still leave a service dependency unresolved: installed equipment needs commissioning, staff need training, and opening inventory needs receiving and storage.
Begin with the guest journey and work backwards. What must be true for a guest to find the venue, book, arrive, order, receive the product, pay and resolve a problem? For each step, identify the facility, person, system and decision it depends on. This exposes gaps that a list of contractors’ tasks can miss. The launch leader owns the integrated picture, even where specialists own individual approvals.
Define ready
For each workstream, describe a verifiable completion condition. “Staff trained” is less useful than a named list of people who completed a practical rehearsal and know the escalation contact.
Assign a decision owner
Every open issue needs one person responsible for moving it forward. Identify who approves a change and which other tasks depend on it. Keep decisions and their reasons next to the task.
Rehearse the handoffs
Walk through a normal customer journey and a few failure scenarios. Check how information moves between teams. Turn the gaps into tasks with owners and repeat the rehearsal after fixing them.
Build a responsibility register people can use
Use a small set of fields: workstream, deliverable, accountable owner, contributors, approver, due date, dependency and evidence. One named owner moves an issue forward; that does not mean they perform every task. Avoid assigning responsibility to “the team” when a decision needs a specific person.
For example: “card payments ready” belongs to a named operations or finance owner; evidence is an authorised test in the intended environment and a reconciled result, not a screenshot of a provider account. “Menu ready” includes approved recipes, prices, availability rules and the versions used by both kitchen and service. Set the escalation route for missed dependencies before the deadline arrives, so the opening date does not become the only argument in every disagreement.
Six workstreams for the pre-opening checklist
Cover premises and equipment; product and purchasing; people and training; guest service; systems and money; and compliance. Each needs an acceptance condition. Equipment should be demonstrated in the intended workflow. Purchasing should include receiving, storage and alternatives for critical items. Staff should practise their tasks rather than merely sign an attendance sheet.
Guest-service checks include opening information, reservation ownership and complaint escalation. Systems checks include access permissions, backups of critical operating information and reconciliation responsibilities. Compliance checks must refer to the actual jurisdiction and business model. This article is an operating framework, not a complete licensing list. Do not use a generic checklist as evidence that permissions or inspections have been obtained.
Worked example: a late equipment delivery
Imagine a dishwasher delivery slipping by five days. The visible issue is logistics, but the dependency chain includes installation, utilities checks, staff practice, tableware circulation and service capacity. Mark each affected task and identify which assumptions about the opening no longer hold. A new delivery promise alone does not close the issue.
Compare options with the relevant specialists: a verified temporary arrangement, reduced service scope, or a later opening. For each, record capacity, cost, responsible approval and an expiry or review date. Do not compensate for a critical safety gap by calling the opening “soft”. A limited opening can test service, but it still requires the necessary readiness and permissions.
Opening in Thailand: separate local verification from operations
A project in Koh Samui needs a local verification track for the proposed premises, permitted use, entity, staffing and activities. The exact obligations depend on the situation. Appoint qualified local advisers and keep their written conclusions attached to the relevant decision. Do not infer permission from the fact that another venue nearby operates in a similar way.
Operationally, prepare bilingual acceptance criteria where teams or contractors use different languages. Keep a single approved version of the drawings, menu and task register. Write down the time zone and date for remote decisions. A photograph can show progress, but commissioning, training and document checks need their own evidence. Remote owner representation works better when the owner sees exceptions and decisions, not only attractive progress images.
The go/no-go meeting and the first week
Before opening, review critical blockers separately from cosmetic defects. Identify who has authority to postpone the launch. Run a rehearsal from reservation to payment and include an unavailable item, a late arrival and a system outage. Capture the result, owner and retest for each failure. A rehearsal is useful only if its findings can change the plan.
During the first week, use short daily reviews with a stable incident log. Avoid changing menu, staffing model and software simultaneously unless the situation requires it. Otherwise the team cannot tell which change improved the result. When is a task truly complete? When its acceptance criterion is met and the recipient can use the result. “Sent to the manager” is a handoff, not acceptance.
Sources and scope
ISO: quality management ↗
General process-management background; local permits require independent verification.