Kids’ menu, vegan menu and gluten-free menu in the hotel: how to catalog them without multiplying the menu

The family arrives at your hotel’s restaurant on a Saturday: two adults, a six-year-old girl and a grandmother who does not eat gluten. The server brings the menu, the kids’ menu, asks whether they want to see the gluten-free menu, and the table ends up with four different documents, three prices for the same chicken and a grandmother who cannot tell whether the salad on the main menu is the same one as on the special menu. The kitchen, meanwhile, receives three tickets that look like they came from three restaurants.

The problem with parallel menus

The intuitive way to serve a special audience is to give it its own menu. Kids’ menu, vegan menu, gluten-free menu, corporate traveler menu, all-inclusive menu. Each one is born with good intentions and each one becomes an independent document someone has to maintain. In a hotel, with four or five revenue centers and two languages, the number of documents multiplies very fast.

• The same dish exists three times in the point of sale, with three codes, and sales are split among the three: the mix report no longer tells the truth.
• When the price of chicken goes up, it has to be changed on every menu, and one always gets left behind.
• The allergen is marked on one menu and forgotten on another, and the “gluten-free” dish on the special menu is not the same as the one on the main menu.
• The kitchen receives tickets with different names for the same plate, and the new cook does not know they are the same.
• Translation is done per document: four menus, eight translations, and none of them match completely.
• The front desk does not know which menu applies to the guest’s agreement or meal plan, and asks the restaurant every time.

None of these problems come from serving children or vegan guests well. They come from modeling that service as separate menus instead of as properties of the dishes you already have.

One catalog, many attributes

The alternative is simple to state and takes discipline to execute: the hotel restaurant has a single catalog, and every dish carries attributes that say who it is suitable for. An attribute is a structured label, not text: “suitable for kids”, “vegan”, “gluten-free”, “vegetarian”, “lactose-free”. It is ticked with a checkbox on the product card and from there it governs everything else: what the guest sees, what the kitchen sees and what the controller sees.

The kids’ menu stops being a document and becomes a view: every dish with the “suitable for kids” attribute. The vegan menu is another view of the same catalog. If the guest wants to see vegan and gluten-free dishes at the same time, they combine two filters and the digital menu (Digital menu) shows the intersection. Nobody had to design a “gluten-free vegan” menu because it is not needed: both labels were already on the dishes.

When it really is a new dish

An attribute describes a dish that already exists. When the special dish is genuinely different, with another recipe, another cost and another process in the kitchen, then it is a new catalog product: the vegan burger with its own protein, the gluten-free pasta with its different pasta. Those enter the catalog like any other dish, with their recipe and their attribute ticked. What you do not do is duplicate the grilled chicken just because children can order it too.

The three cases, one by one

Kids’ menu

The children’s menu in a hotel is, in practice, three things: dishes from the main catalog in a smaller portion, two or three dishes only children order, and a different price. The smaller portion is handled with a product variant, not a new product: the same chicken, “kids” size, with its own weight and price. The exclusive dishes enter the catalog with the attribute ticked. And the price lives on the variant, so when the cost of chicken goes up it is adjusted in one place.

In a family hotel, this menu is usually tied to policies as well: children under a certain age eat at no charge with the meal plan, or the included breakfast covers the kids’ menu. That rule is applied to the attribute, not to a menu: the system knows which dishes are “kids” dishes and can apply the policy without the server having to remember.

Vegan menu

The vegan attribute is inherited from the recipe more easily than any other: if none of the ingredients is of animal origin, the dish is vegan. When the catalog has recipes, the chef does not tick the attribute by hand; the chef confirms it. And when the recipe changes and butter comes in, the attribute drops on its own and the dish disappears from the vegan view before a guest orders it by mistake.

The distinction between vegan and vegetarian matters and it is worth having as two attributes, not one. The guest who filters for vegetarian accepts egg and dairy; the one who filters for vegan does not. A menu that mixes them forces the guest to read ingredient by ingredient, which is exactly what the filter should spare them.

Gluten-free menu

Here the attribute crosses paths with the allergen, and the difference has consequences. “Gluten-free” as a preference is a diet; “gluten-free” as a medical need is an allergy or a serious intolerance. The catalog attribute should distinguish the dish that has no gluten in its recipe from the one that is also prepared without cross-contact in the kitchen. If the hotel cannot guarantee the second, it says so in the attribute, and the guest decides with that information.

As with vegan, the attribute is inherited from the recipe and reviewed every time it changes. The gluten-free pasta is a new product; the grilled fish with vegetables is the same product as always with the attribute ticked. Two different cases, one catalog.

How the guest sees it

The guest does not see attributes or catalogs. The guest sees a menu with clear filters at the top: kids, vegan, vegetarian, gluten-free, lactose-free. They tick the ones they need and the menu shrinks to what they can order, with the correct price of the matching variant. In room service from the room, at the table with the QR code or on the menu the server shows on a handheld, the experience is the same because the source is the same.

And what the guest appreciates most: the kids’ menu is not a separate sheet with drawings and three options. It is the hotel’s menu, filtered. If the girl wants the fish of the day in a smaller portion, it is there, because the fish has its kids’ variant. The hotel stops deciding for the family what the children can eat and lets them choose.

How the kitchen and the controller see it

The kitchen sees a single ticket with the usual dish name and, when it applies, the variant: “grilled chicken, kids portion”. There are not three codes for the same chicken. The new cook learns one catalog, not four. And when the “gluten-free” attribute is flagged on the order because the guest filtered for it, the ticket shows it highlighted, as if it were an allergy, because in the kitchen it is treated the same way.

The controller gains the most. With a single catalog, the sales mix says how much chicken was sold, regardless of who ordered it, and it can also say how much was sold as a kids’ portion or with the vegan filter active. Cost of sales is calculated on one recipe per dish, not on three copies. And the departmental report under USALI (What USALI is and why it pays off even with twenty rooms) remains by revenue center, without special menus distorting it.

Illustrative example: how many records you maintain

The figures below are invented to show the calculation; they do not describe any hotel. Suppose the hotel restaurant has 80 dishes on the main menu. With parallel menus, the kids’ menu repeats 12 dishes from the main one and adds 3 exclusives; the vegan repeats 15 and adds 4; the gluten-free repeats 20 and adds 2. With attributes, every repeated dish is the same record with a box ticked, and only the exclusives are new records.

In the example, the difference is 136 records against 89: 47 fewer cards to enter, translate, cost and review every month. And the chicken price change goes from three edits to one. With two languages and four revenue centers, the real difference in hours of work is even larger, because every record is translated and assigned to every revenue center.

Prices and portions: variants, not products

A good part of what motivates a special menu is price. The kids’ menu costs less because the portion is smaller. The solution is not a separate product; it is a size variant with its own price and its own weight in the recipe. The point of sale treats the variant as part of the same dish: the report adds the two together, the cost is calculated with the correct weight and inventory deducts what applies.

The same goes for substitutions: gluten-free bread instead of the house bread may or may not carry an extra cost, and that is a modifier on the dish, not a new dish. When the catalog handles variants and modifiers well, the temptation to create parallel menus disappears, because everything the special menu did, the catalog already does.

Groups, all-inclusive and agreements: when the attribute decides who can order

In a hotel, the attribute has an additional use that does not exist in a street restaurant: it defines what each plan covers. The convention group has an agreed menu; the all-inclusive guest has a meal plan that covers certain dishes and not others; the corporate agreement covers dinner up to a cap. In all three cases, what is covered is defined by attributes or by catalog dish lists, not by different printed menus.

When the server opens the room charge and the system knows the guest is all-inclusive, the menu on screen already shows what is covered and what generates a charge. The child of the family with a meal plan orders from the kids’ menu and the charge goes to zero because the attribute and the policy crossed on their own. Nobody had to call the front desk to ask. That crossing, in groups and banquets (Groups and banquets), is what avoids most of the arguments at check-out.

What to do this week

1. Count how many different menus your hotel restaurant has today, in how many languages and at how many revenue centers, and how many dishes repeat across them.
2. Define with the chef the list of attributes you will manage: kids, vegan, vegetarian, gluten-free, lactose-free, and whatever your guests actually ask for.
3. Tick the attributes on the 20 best-selling dishes first, and verify that vegan and gluten-free are inherited from the recipe.
4. Convert kids’ portions into variants of the original dish, with their price and weight, and retire the duplicate codes.
5. Open the digital menu as a guest with two filters at once and confirm the intersection shows the right dishes at the right price.
6. Review with the front desk what the meal plan and the corporate agreement cover, and tie that coverage to attributes instead of a printed menu.

In Inn Restaurant a dish is entered once, with its attributes, variants and modifiers, and the hotel’s digital menu filters by what the guest needs at each revenue center. If you want to see what the kids’ menu and the vegan menu look like without having created either of them, book a 15-minute demo (contact).