A single bistro can get away with one menu and a drinks list. A hotel, a resort, a food hall or an attraction cannot. Guests want to know what is in the lobby café, what the restaurant is serving tonight, and whether the kiosk by the pool can feed a child who avoids nuts. Three PDFs in a welcome email do not answer that.
Multi-menu is built for that kind of place: every internal food venture on one live page, with a personal link when someone books.
One restaurant is already more than one menu
Before the destination case, most venues already split the offer:
- Breakfast, lunch and dinner, sometimes as separate menus
- A drinks list with its own allergens — milk in the cocktails, sulphites in the wine, gluten in the beer
- A kids' menu, a Sunday menu, a private-dining sheet
Those should not be five files with five QR codes. They are menus on the same venue, drawn from the same recipes, so a price or an allergen change does not have to be typed out again. Section lines such as "Served from 11:30am" tell guests when that part of the card is on. The address stays stable: /your-restaurant/menu.
Groups with several buildings have a different problem, covered in keeping allergen data consistent across sites. Multi-location control is about sister sites. Multi-menu is about many outlets inside one destination.
What guests should see at a resort or food hall
Attach each café, bar, kiosk and restaurant as an outlet. Each keeps its own menu. Guests browse them from one destination page and filter allergens across the lot, instead of opening a different PDF per unit.
That matters on arrival. A family deciding where to eat should not have to collect paper from four counters to find a dairy-free main. The same dietary tags and allergen filters they would use in a single restaurant apply to every outlet on the page.
The booking should carry the menu
The awkward moment is the email that says "menus attached" and then attaches last season. A better pattern: the reservation system posts a signed booking event, and Quiteful emails the guest a personalised menu link with their dates and party size.
The webhook is verified with an HMAC signature, so random posts do not generate guest emails. The guest opens one link, in a language they can read, and filters before they travel. No one on reception is chasing a PDF at 9pm.
Languages without a second set of menus
Destinations serve people who do not read the kitchen's first language. Multi-menu guest pages can switch among English, German, French, Spanish, Portuguese, Italian, Czech, Greek, Dutch and Polish, and the allergen filters stay with them.
The wording still has to be reviewed. Machine translation of a dish name is a convenience. Machine translation of an allergen warning is a safety step. That review workflow is DeepL-backed menu translation: one source recipe, a draft in the target language, a human check before guests see it.
What this is not
It is not a reason to flatten every outlet into one generic card. The pizza kiosk and the dining room should still read as themselves. Shared recipe data is what stays consistent; the guest-facing menus stay distinct. Branding can differ by location too — see themes that match the venue.
A practical next step
If you run one room, publish food and drink from the same account and retire the extra PDFs. If you run a destination, put the outlets on one page and connect the booking system so the link goes out with the reservation.
See multi-menu in Quiteful, or compare it with multi-location menus if the problem is several sites rather than several outlets under one roof.