A daily special needs one clear owner, one named service window, and one public menu version. Before service, publish the item with the choices a guest can make, test the route on an ordinary phone, and tell the team where to verify it. After service, remove or deliberately renew it so yesterday’s offer does not become today’s promise.
Give the special a start and finish, not just a title
“Today’s special” is not enough information for a guest or the next shift. Write down who owns the decision, which location serves it, when it begins, and what ends it: a time, a service, a quantity, or a manager’s replacement decision. That scope prevents a lunch offer from appearing during dinner just because it was still live.
| Check | Confirm before publishing | Owner |
|---|---|---|
| Service window | Location, first service, and planned end | Shift manager |
| Guest entry | Name, price, choices, and availability wording | Menu owner |
| Public route | Mobile menu, QR destination, and saved link | Tester |
| Team handoff | Where the current offer is verified | Floor or counter lead |
| Closeout | Remove, mark unavailable, or renew | Same owner who opened it |
This is a practical workflow, not legal advice. When a special includes an advertised price, use the restaurant’s local consumer and pricing requirements; the FTC’s advertising guidance is one U.S. reference point.
Write the decision a guest can actually make
Name the dish the way a guest can identify it at the table or counter. Then show the price and every option that changes the result: size, add-on, side, dietary substitution, or limited quantity. A photo, staff note, or vague “ask us” label should not be the only place an important choice appears.
Clear labels save the team from translating the menu mid-service. The W3C guidance on labels and instructions is a useful review: a person should understand the action and choice before making it. Use the digital-menu modifier guide when an option needs its own explanation.
Test the public menu, not the editor view
An internal screen proves that someone saved a change. It does not prove that a guest can see the right offer. Leave the staff account, stand where a guest scans, and follow the public route on a phone.
- Scan the printed QR code or open the public link used in the room.
- Confirm the special appears at the intended location and service.
- Open each price-changing choice and read the final guest-facing wording.
- Check that the item is not confused with an unavailable-item process.
- Ask the shift lead what they will do if the public page and verbal briefing differ.
If the special replaces or temporarily changes a regular item, also use the price-update checklist. A special is short-lived, but the guest should still see one reliable price path.
Brief the team with one source, then close the loop
The handoff can take a minute: say what the special is, when it runs, where to verify it, and who can decide an exception. Do not ask staff to remember a second menu version. If someone notices a mismatch, correct the public source and record only the operational cause, never a guest name, phone number, or order details.
At close, choose the next state deliberately. Remove the entry if it is over, mark it unavailable if stock ended, or renew it with a new service window. A seasonal menu update handles a broader menu transition; a daily special needs the smaller discipline of opening and closing one short offer. Include that check in the wider mini-site content review when hours, location, or guest instructions also change.
Daily-special sign-off before service
- Does one person own the offer and its end time?
- Can a guest see the name, price, choices, and availability on a phone?
- Did someone test the actual QR code or public link?
- Does the floor know which public page answers a guest question?
- Is the closeout action already assigned?
The goal is not to make a daily special bureaucratic. It is to keep a useful, short offer from becoming an avoidable service conversation.