A daypart is a public service decision, not a clock setting hidden in the kitchen. Breakfast, lunch, and dinner each make a different promise about what a guest can choose right now. When that promise is unclear at the changeover, the host, server, and guest end up negotiating information that the menu should already answer.
This guide covers recurring transitions between services. It does not replace a location-availability plan for one address, a daily-specials checklist for a short offer, or a seasonal menu update for a planned menu revision.
Define the menu that is true now
Restaurant opening hours and menu availability are separate facts. A dining room can be open while breakfast has ended, while lunch is being prepared, or while a limited transition offer is the only service the kitchen can fulfill. Put that distinction in one transition map before the shift starts.
| Daypart | Starts when | Ends when | Public state | Exception owner | Next review |
|---|---|---|---|---|---|
| Breakfast | Kitchen accepts breakfast tickets | Lunch preparation changes the offer | Breakfast menu is current | Shift lead | At the lunch cutover |
| Lunch | Lunch menu can be fulfilled | Dinner setup changes the offer | Lunch menu is current | Kitchen lead | At the dinner cutover |
| Dinner | Dinner menu can be fulfilled | Service closes or a late-night rule begins | Dinner menu is current | Manager on duty | At close or the late-night cutover |
| Transition | A documented exception is active | A named person ends it | One labelled, limited choice is current | Named approver | At the stated time |
The table does not need a complicated system. It needs names for the facts a guest-facing menu cannot guess: what service is active, what changes at the cutoff, and who can decide if the cutoff moves. If a price changes with the service, run it through the digital-menu price update checklist as a separate review instead of treating it as a minor timing note.
Public descriptions should be specific enough for a guest to rely on. This is an operational guide, not legal advice; local requirements still apply to the restaurant’s public menu information.
Use a three-part changeover protocol
The riskiest moment is not the first lunch order. It is the few minutes where one person sees breakfast on a phone and another hears that lunch has started. Give the team a short routine that makes that boundary visible.
- Before the cutoff, confirm readiness. The kitchen lead says whether the next service can be honored. The menu owner checks which current items, modifiers, and notes must leave or remain. If the next service is not ready, decide the guest-facing transition state before the old one expires.
- At the cutoff, publish one understandable state. Show the menu that can be fulfilled, or show a clear limited transition. Do not leave two full menus visible merely because the team has not decided which one applies.
- After the cutoff, test and record the exception. If brunch runs late, a private event delays dinner, or one preparation item holds the next service, record the active public state, the approver, and the next review time. A verbal workaround does not travel to the next shift.
An item becoming unavailable during an active service is a different incident. Use the sold-out item process rather than turning the whole service transition into an inventory workaround.
Test the route a guest actually uses
Saving a menu edit does not prove the public page tells the same story. Test from the QR code, saved link, or other entry point a guest has—not from an employee view that skips the normal path. Run the check immediately before and immediately after each changeover.
- Open the link on a standard phone with no employee session.
- Confirm the visible daypart, location, and next available service agree.
- Read item names, modifiers, availability notes, and prices as a guest would.
- Check that a person can understand the state without colour, staff shorthand, or a separate explanation.
- Record who fixes a mismatch and when the page will be checked again.
The W3C guidance on labels and instructions is a practical clarity test: a person should understand what to choose before they act. If hours also change for a holiday or special event, keep the public profile aligned; Google’s special-hours guidance is a useful operational reference for that separate listing.
Make exceptions small and visible
A late breakfast, overlapping brunch, or delayed dinner can be legitimate. The problem starts when the exception has no boundary. State what remains available, what is unavailable, who approved the exception, and when the next review happens. Do not convert a temporary condition into a vague “menu may vary” message that leaves every guest guessing.
For a scheduled seasonal change, use the seasonal menu update checklist. For a service that differs by address, use the location guide. Those distinctions keep a daily cutover from spreading into a broad, stale menu policy.
Hand the next shift a decision, not a rumour
The handoff can fit in five fields: active daypart, current public state, exception if any, next review time, and decision owner. It should not include copied guest conversations or personal details. The incoming team needs to know what the menu promises and who can change it.
Review one or two changeovers after a busy day. Could a guest tell which service was available without asking? Did the public path change at the right moment? Did the next shift see the same state? Use the answers to improve the transition map before adding more rules. When comparing tools for that workflow, use this checklist alongside the restaurant digital menu software page.