1. Prepare one authoritative menu source
Start with the menu the venue is willing to treat as correct. A PDF, spreadsheet or clear set of photos can be enough for an initial import, but it still needs a human review. Confirm category order, item names, descriptions, prices, VAT information where the workflow requires it, availability, and which images are approved for public display.
Mark what is temporary. A seasonal item, a sold-out item and a hidden draft are different states. Keeping them separate makes later edits safer than deleting and recreating products whenever the room changes.
2. Choose where orders go
Decide whether the launch is view-only, customer ordering, or waiter-led service. If guests can submit orders, name the operational destination before printing a single QR code: a receipt printer, an iPad order board, a kitchen display, or another staffed surface.
Test who acknowledges an order and what happens if the normal device is offline. The fallback may be as simple as switching temporarily to view-only service, but it should be an agreed decision rather than a discovery during a busy period.
3. Treat payment as its own go-live track
A menu can be ready before online payment is ready. If the venue will take payment in the customer flow, confirm the intended timing, the payment provider account, the settlement currency, the visible fees and the webhook or reconciliation path used to confirm payment.
Fiscal and receipt integrations also have explicit provider and venue activation gates. Sandbox tests, a configured button, or a successful menu build do not by themselves guarantee live issuance or legal compliance. The venue and its professional advisers remain responsible for confirming the operating requirements that apply to it.
4. Review language and food information
Choose the menu's primary language, then review each enabled translation as customer-facing copy. Names, ingredients and preparation terms often need venue context that a literal translation cannot supply.
Allergen information needs a separate confirmation step. Do not publish generated, imported or incomplete allergen data merely because it exists in a draft. Guests should see only the information the venue has reviewed and chosen to make live, together with an obvious way to ask staff when needed.
5. Put QR codes where a guest can actually use them
Choose the physical format for each part of the room: a table cube or acrylic stand for shared tables, a durable sticker where space is tight, a framed menu at an entrance, or weather-appropriate signage outdoors. Keep the code flat, well lit and large enough for the expected scanning distance.
Print only after the production hostname and redirect behavior are final. Scan every item with more than one phone, from a seated position, and confirm that a damaged or moved sign can be replaced without changing the menu address.
6. Run a staff rehearsal
Use real products but a controlled test shift. Change one price, hide one item, place an order in every enabled mode, confirm what appears on preparation and till screens, and walk through cancellation or recovery. Check the guest experience in each enabled language.
Finish with ownership: who updates the menu, who checks incoming work, who can pause ordering, and who contacts support. A launch is ready when those answers are clear, not when every optional feature is switched on.