Yes, guests can use dietary filters as a browsing aid without treating them as an allergen guarantee—but only if the menu makes that distinction clear and the restaurant keeps the underlying dish information current. A useful filter narrows choices; it does not establish that a dish is safe for a particular guest.
Before buying, ask the vendor to show you how a staff member assigns a filter, how an uncertain ingredient affects the result, and what a guest sees after selecting it. Then decide whether your team can maintain those records during ordinary service, not just on setup day.
Map ingredients and labels before choosing filters
Start with a short list of filters your kitchen can support. “Vegetarian” and “contains milk” answer different questions: one describes a dietary pattern, while the other identifies an ingredient. Write a plain-language definition for each label so the person updating the menu does not have to guess.
For a filter such as “no milk ingredients,” define what evidence is needed before a dish is included. Include sauces, dressings, garnishes and components made by suppliers. A blank field should mean unknown, not automatically mean the ingredient is absent. Also keep preparation and cross-contact information separate from an ingredient filter; removing milk from a recipe does not establish that a dish is free from milk exposure.
The following worksheet is hypothetical. Assume the restaurant wants to offer a “no milk ingredients” filter and has reviewed the recipes as shown. The results describe ingredient records only; they do not promise safety for anyone with a milk allergy.
| Dish | Ingredient record | Staff classification | Filter result |
|---|---|---|---|
| Tomato rice bowl | Reviewed components list no milk ingredients | Eligible for the filter | Show in results |
| Roasted vegetable flatbread | Feta is listed in the recipe | Contains milk | Do not show in results |
| Chickpea salad | Dressing supplier information has not been verified | Milk status unknown | Do not show in results until verified |
The boundary is deliberate: the bowl can appear because its listed components were reviewed; the flatbread cannot because its recipe includes feta; the salad stays out because missing information is not evidence of absence. If the software only offers a yes/no tag, ask how staff can distinguish “reviewed and absent” from “not yet checked.” A separate internal record or a clear update procedure may be needed.
Apply the same discipline to other filters. For a vegetarian label, for example, agree how staff will check broths and sauces. For any label, record who owns the definition and where staff can find the current ingredient details. A filter with no maintenance owner becomes less useful each time a recipe or supplier changes.
Compare staff tags with the guest's screen
A vendor demo should cover both sides of the menu. Ask to see the staff editing view and the guest view on a phone. Start with an unfiltered menu, select the dietary filter and inspect the results. Then open a dish detail page to see whether the label and any explanation remain visible.
Look closely at the words around the filter. “No milk ingredients” is more specific than a bare “milk-free” badge, but even a specific label needs a nearby explanation that it describes listed ingredients, not cross-contact or an allergen guarantee. Ask whether the restaurant can edit filter names and explanatory text, and where that text appears. A warning buried on a different page may not be seen when a guest is making a choice.
Check the result count and the empty state too. If no dishes match, does the menu clearly say so, or does it return guests to the full menu in a way that could look like a filtered list? Ask how the selected filter stays visible as guests move between categories and dish pages. If guests must clear it to see other items, that action should be obvious.
Use a simple comparison for each dish: the recipe record, the staff tag and the screen a guest sees should agree. Have the vendor explain whether one tag controls every menu view or whether staff must update separate copies. If multiple locations use different recipes, ask whether each location can maintain its own information without overwriting another location's menu.
QR menus differ from full ordering systems. Fleksa's QR ordering software lets guests scan, order and pay at the table in a browser without downloading an app. Whether a particular dietary filter and its wording fit your workflow is a separate question to review in a product demonstration. For the broader service decision, see the guide to placing QR ordering in table service.
Run a safe acceptance check for conflicts and unknowns
Use a practice menu or an isolated demonstration environment for the check below. It should not create a real payment, send a guest message or dispatch a courier. Confirm the environment and its safeguards with the vendor before anyone starts. This is a simulation, not a live service pilot.
- Check a valid match. Enter the hypothetical tomato rice bowl with its reviewed ingredient record and the eligible tag. Apply the filter on a phone. The bowl should appear, with the restaurant's ingredient-only explanation available to the guest.
- Create a conflict. In the practice menu, mark the flatbread both as containing milk and as eligible for the no-milk-ingredients filter. Check what the editing screen permits and what the guest sees. Ask whether the system blocks the conflict, flags it for staff or displays the dish anyway. Do not assume a tag resolves a contradictory ingredient record.
- Check an unknown. Leave the chickpea salad's dressing unverified. The acceptance boundary is that the salad stays out of the filtered results until a staff member verifies the dressing and updates the record. Ask how the system represents that unknown status.
- Make a change. In the practice menu, change the bowl's recipe record to include a milk-containing sauce. Update the relevant tag and refresh the guest view. Ask how quickly changes appear and whether an older view can remain visible.
- Recover from an error. Ask who can remove a misleading label, how staff can identify affected menu items and whether the previous change can be traced. Agree on who checks the guest view after the correction.
A workable result does not require every product to have the same safeguards. It does require a dependable operating rule. If conflicting tags can be published without a warning, can your team reliably catch them before publication? If unknown ingredients cannot be represented, can staff keep an accurate record outside the menu and prevent uncertain dishes from entering the filter? If the answer is no, leave that filter off until the workflow is workable.
After the simulation, a live service pilot is a separate decision. Brief the team, designate a person to handle menu corrections and observe how guests use the filter during a limited service period. Use normal service procedures for real orders; do not create artificial guest transactions to test the menu. Stop or remove the filter if the team cannot keep the displayed information aligned with the recipes.
Set a confirmation path and update routine
Give guests a clear next step near the filter and dish details: ask a staff member about dietary needs and ingredient concerns before deciding. Staff should know where to find the current recipe and supplier information, who can answer preparation questions, and when to involve the kitchen. If the information is uncertain, the useful answer is that the team needs to check—not that a filter has already settled the question.
Make the path work for guests who do not use a phone as well. A server can consult the same current information rather than relying on a separate, outdated printed list. Decide how a guest reaches staff from a table and what the team does if the responsible person is busy. This decision concerns browsing and confirmation; do not assume a filter also sends an allergy request to the kitchen.
Put updates into the routine for recipe and supplier changes. Before a substitution reaches the menu, the responsible person should check affected labels, update the ingredient record and inspect the guest-facing result. If a supplier changes without enough information to verify a component, treat the relevant status as unknown until it is checked. Establish a backup owner for days when the usual menu editor is away.
Ask each vendor these questions before signing:
- Can staff define filter labels and place an ingredient-only explanation where guests select them?
- How are unknown ingredient statuses, conflicting tags and unpublished changes handled?
- Who can edit and publish menu data, and can managers review what changed?
- How are changes reflected across locations, devices and any connected menu views?
- Can staff remove a filter or item quickly while they investigate a mistake?
Consider those answers alongside the rest of your restaurant management workflow. The best filter for your operation is one your team can explain and maintain, with a clear route to a person when a guest needs more information.
Next, take three of your own dishes—including one with a supplier-made component—to a vendor demonstration. Ask to see the staff record, the filtered guest view and the correction process. Discuss your requirements with Fleksa and compare the workflow with your current service model.
Frequently asked questions
Does a dietary filter guarantee a dish is allergen-free?
No. A filter can describe the ingredients recorded for a dish, but it does not establish the absence of cross-contact or make a safety guarantee. Guests with concerns should speak with staff.
Should an item with an unknown ingredient appear in filtered results?
For an exclusion-based filter, keep it out until the relevant ingredient information is verified. An unknown status should not be treated as confirmation that an ingredient is absent.
Does a QR menu need ordering and payment features to offer filters?
Not necessarily. A QR menu can serve as a browsing tool. If you also want table ordering and payment, evaluate those workflows separately from dietary filtering.
