Use dietary labels only when your restaurant can explain what each one means and support it with current ingredient and kitchen information. Put the label next to the dish, make its limits easy to find, and give guests a direct way to ask about their needs. Avoid absolute promises that your team cannot verify.
A label is a starting point for a conversation, not a substitute for one. A guest may use the same word differently from your kitchen, and an ingredient review alone does not describe what happens on a shared grill or prep surface.
Define labels with the people who make the food
Start with the dishes you actually serve and the labels guests are likely to look for. Resist adding a long list of badges simply because a menu design has room for them. Every label creates another detail someone must maintain.
Bring the kitchen lead and the person responsible for menu updates into the discussion. Ask them to write a plain-language definition for each label. For example, if you use “vegan,” decide which ingredients, garnishes, sauces, and preparation steps the label covers. If you use “made without gluten-containing ingredients,” make clear that this describes ingredients rather than a guarantee about shared equipment.
Build each decision from several inputs:
- The current recipe: The kitchen lead identifies every ingredient, garnish, sauce, and routine substitution.
- Product information: The purchaser or kitchen lead checks current supplier information for packaged ingredients and records questions that still need answers.
- Preparation: The people making the dish describe shared tools, surfaces, cooking equipment, and handling practices.
- Menu wording: The person publishing the menu translates the decision into a short label and a clear explanation guests can reach.
Check the whole dish as served, not just its main ingredient. A vegetable soup may contain broth, a finishing cream, or a garnish that changes the label decision. A sauce supplied separately still matters if it normally comes with the dish.
Keep informational labels separate from choices a guest can make while ordering. “Vegan” describes the dish under your stated definition. “Remove cheese” is an order instruction; it does not establish that the remaining ingredients or preparation meet that definition. If a label applies only to a particular version, say which version and make sure the ordering screen does not imply it applies to every variation.
Explain what the label does and does not cover
The useful middle ground is specific language. A badge can help a guest find a possible choice quickly, while a short menu note explains the scope. Neither should suggest that a dish is safe for every person or every dietary need.
For a hypothetical restaurant, suppose the kitchen reviews a mushroom soup and finds no dairy ingredients in its standard recipe. The team also uses the same prep area for dairy products and cannot verify that dairy contact is prevented at every step. A practical label could be “Made without dairy ingredients,” paired with a note such as: “Prepared in a kitchen that also handles dairy. Contact us with questions about ingredients or preparation.”
That wording describes the ingredient decision and the known preparation limit separately. It does not call the soup dairy-free or promise that contact cannot occur. The note must match the restaurant’s actual practices; a generic shared-kitchen sentence is not a replacement for asking how the dish is made.
Place the explanation where a guest can find it before ordering. A short note near the menu or the affected item is more useful than a statement buried in a site footer. On a phone, check that the badge, dish name, and explanation are readable together. If a guest must open a separate page to see definitions, make the link obvious and test that it leads to the right section.
Consider how much detail the label can carry. A compact badge keeps a menu easy to scan, but it cannot describe every ingredient and preparation step. Longer notes provide context, but a wall of warnings beside every dish can make the menu difficult to use. Use a consistent short label, then provide the relevant explanation and contact path nearby.
Do not guess when a guest asks about a serious restriction. Give staff a way to check with the kitchen and explain what is known and unknown. If the team cannot answer confidently, say so rather than turning an uncertain label into a promise.
Use a verification matrix and update it after changes
A simple matrix connects the website label to the people and information behind it. The example below continues the hypothetical soup scenario. It is a working record, not a statement about a real restaurant or a universal definition of any label.
| Decision | Evidence or action | Owner | Website result |
|---|---|---|---|
| Ingredient wording | Review the recipe, broth, garnish, and current supplier details for dairy ingredients. | Kitchen lead | Use “Made without dairy ingredients” only while the review supports it. |
| Preparation limit | Confirm that the prep area is also used for dairy and record what is not controlled. | Kitchen lead | Show the shared-prep note near the menu. |
| Recipe or supplier change | Hold the label for review when the broth, garnish, or preparation changes. | Purchaser and kitchen lead | Remove or pause the label until the revised dish is checked. |
| Guest question | Check the current record and route unanswered questions to the kitchen. | Shift lead | Provide a contact method and avoid guessing. |
The matrix makes the handoffs visible. It also shows the difference between checking an ingredient list and understanding preparation. Keep the record somewhere the people buying, cooking, and publishing can reach it. Add the review date, the specific products checked, and the person who approved the current wording.
Now suppose the hypothetical restaurant changes the soup broth. The purchaser tells the kitchen lead before the new broth is used. The kitchen lead reviews its current product information and the full recipe. Until that review is complete, the website editor removes or pauses the dairy-ingredient label. If the new broth contains dairy, the label stays off and the menu wording is revised. If the review supports the original wording and preparation remains the same, the editor can restore it.
That example does not establish how any particular menu system handles a change. Ask how quickly your team can edit a label, whether a change appears on both the website menu and ordering view, and who can publish it. If those are separate screens, include both in the update checklist.
Run a simulated check before a busy service: give the team a pretend broth change, have the responsible people identify the affected label, and review the intended website edits without publishing an incorrect menu. No guest order or message is needed. Then inspect the real published menu after an authorized update. A simulation checks the handoff; it cannot prove that every future supplier or kitchen change will be caught.
Set a regular review schedule as well as a change-triggered review. During a shift, substitutions happen quickly. Give staff a simple way to flag them, and decide who can temporarily remove a label when the person who normally publishes the menu is away.
Make questions easy to ask before ordering
Choose a contact path that your team can actually monitor. A phone number may work well when someone can reach the kitchen during service. A written inquiry may be useful for guests planning ahead, but only if someone checks it and knows when to involve the kitchen. State the practical availability of the channel rather than implying an immediate response at all hours.
Train the person answering to ask which dish and which ingredient or preparation concern the guest means. They should consult the current record, check with the kitchen when needed, and describe limits plainly. Avoid making a guest repeat the same question to several people if a shift lead can coordinate the answer.
Review the contact path on the website and alongside online ordering. A guest who reaches an ordering page directly still needs a way to ask before placing an order. Also check that labels on the ordering view match the labels on the main menu. If the same dish appears in multiple places, assign someone to check each one after an update.
When evaluating a restaurant website builder, ask to see how your own team would edit a dish label, add a nearby explanation, and update a contact method. Check the mobile view and ask whether you can keep control of the site address; this domain ownership guide covers that separate decision.
Use the matrix to review one current dish with your kitchen lead, then check its published wording and contact path. If you are considering a new restaurant website, ask Fleksa about current US availability and how your team would manage those updates in the setup you are considering.
Frequently asked questions
Should every menu item have a dietary label?
No. Label dishes only when the team has a clear definition and enough current information to support the wording. An unlabeled dish can still have a useful description and a contact path for questions.
Can removing one ingredient make a dish eligible for a label?
Not automatically. Review the rest of the recipe, standard accompaniments, and preparation under your restaurant’s definition. Make clear whether the label applies to the standard dish or only to a specific version.
What should we do when a supplier changes an ingredient?
Flag every affected dish, review the new product information and recipe, and update all relevant menu views. Pause or remove a label while the team cannot support it, and restore it only after the review supports the published wording.
