Skip to article
← Back to Blog
Operations

How to verify allergy requests in QR orders

By Fleksa7 min read•QR ordering, Restaurant operations, Allergy requests

A guest's allergy note needs more than a field on the ordering screen. Use this practical worksheet to trace the request to the right person, test acknowledgment, and set a staff-led fallback before preparation begins.

Before relying on QR ordering for allergy requests, test the entire handoff: where the guest enters the request, how it stays attached to the right item and table, who sees it, and who confirms it before preparation. A note appearing on a screen is not enough if nobody is responsible for reading and acting on it.

Use a simulated order to check each step without taking a real payment or sending a guest message. Then decide which requests your team can handle through the system and which must move to a staff-led conversation. The goal is a reliable process for communicating a guest-specific request, not a promise that any dish is free of an allergen.

Trace one request from phone to kitchen

Hypothetical example: A party at table 7 orders two bowls. One guest adds “peanut allergy” to the first bowl; the other bowl has no allergy request. The restaurant uses a QR ordering system and routes orders to a kitchen screen or printer.

Start on the guest's phone. Can the guest attach the request to the first bowl, or is there only one note for the whole order? If it is an order-level note, the kitchen needs a way to establish which meal it concerns. Do not assume that the person assembling the bowls will infer the answer from the order sequence.

Next, follow the order through every handoff your restaurant actually uses: the order view, the POS if applicable, and the screen or printed ticket used at the preparation station. Check the exact wording at each point. The request should remain readable and tied to the right item, order and table. Also check whether a correction creates a new visible instruction or leaves an older ticket in circulation.

Finally, identify the person who acts on the note. That might be the expediter, a kitchen lead or another designated employee. A useful acceptance test ends with that person confirming the request and deciding whether preparation can begin. If the software cannot record acknowledgment, establish a staff procedure that does.

A restaurant POS system and a kitchen display system may be part of this route. Ask the vendor to demonstrate the actual configuration you would buy, including any printer or station routing you plan to use. A feature shown on one screen does not establish what appears at the next station.

Compare structured choices and free-text notes

A structured choice can make a request easier to spot and sort. Free text lets a guest explain something that is not covered by a menu of choices. Either approach can leave gaps. A checkbox may be too broad; a note can be ambiguous, abbreviated or attached to the wrong item.

Ask what choices guests see, whether they can select more than one, and whether an item-specific note is available. Then ask how those choices appear to staff. A prominent guest-facing option is of little use if it becomes a hard-to-read note at the preparation station.

Use the worksheet below to compare the paths in your own setup. The acceptance checks are operational standards to agree on with staff, not claims that a particular product provides these features.

Request pathWhat to simulateAcceptance checkIf it fails
Item-specific free textAdd “peanut allergy” to one of two bowls.The exact note reaches the responsible person with the correct bowl and table.Use a staff-led order until the association is reliable.
Structured selectionSelect an allergy option, if offered, for one item.Staff can see the selection and identify the affected item before preparation.Ask whether the display or routing can be changed; otherwise use the fallback.
Order-level noteAdd a request without identifying the affected bowl.Staff hold preparation and ask the guest which item is affected.Do not guess; clarify through a designated staff member.
Changed requestSimulate a correction after the order first appears.The responsible person sees and acknowledges the correction; obsolete instructions are identified.Stop the affected item and resolve the discrepancy with staff.

The table separates a message being delivered from a message being usable. In the first two rows, the item association matters. In the last two, a safe handoff depends on staff recognizing that they need more information or that an earlier instruction is no longer current.

Try the same checks with a longer note and with multiple items sent to different stations. If the display truncates text, prints the note only on a summary ticket, or sends it to a station that does not prepare the item, ask whether the setup can be changed. If not, choose a process that puts the request directly in front of the person responsible.

Test acknowledgment, not just delivery

Make the test specific enough that a manager can call it a pass or a fail. Write down the test order, the expected recipient, what that person must see and what they must do before preparation. Have a second staff member follow the order as they would during service. Record the result at each handoff rather than relying on a final ticket alone.

For the two-bowl example, a pass requires the designated person to identify table 7, the first bowl and the peanut request, then acknowledge it before that bowl is prepared. A visible note without acknowledgment is a failed handoff. So is an acknowledgment by someone who cannot identify which bowl is affected.

Include cases that force a decision instead of a routine read:

  • Unclear wording: Enter “no nuts” without specifying which item. The expected action is to hold the affected order and clarify with the guest, not interpret the note as a complete instruction.
  • Conflicting instructions: Simulate a request that conflicts with an item or an earlier note. The responsible person should stop and resolve the conflict before preparation.
  • Correction after routing: Change the request in the simulation. Check which screens or tickets retain the old wording and how staff identify the current instruction.
  • Split preparation: Route parts of an order to separate stations, if that is how your restaurant operates. Check that each person who needs the instruction receives it, or that the designated lead relays it under a defined procedure.

Run these checks in a sandbox, training mode or other isolated setup agreed with the vendor. Disable real payment, guest messaging and courier dispatch; use staff acting as guests. If the production configuration cannot be simulated safely, ask the vendor how to demonstrate the routing without triggering those actions.

A simulated check is different from a live service pilot. After the simulation passes, a manager can observe the normal staff handoff during service, with the restaurant's fallback available. Do not create a real allergy request or send a test message to an unsuspecting guest. If the live workflow differs from the simulation, pause its use for allergy requests until the team resolves the difference.

Set a staffed fallback before launch

Decide in advance what happens when the note is missing, unclear, changed or not visible at the preparation station. Name a role responsible for stopping the affected item, speaking with the guest and relaying the confirmed instruction. Give that person a way to reach the kitchen lead without depending on the same failed handoff.

The fallback should also cover guests who cannot or do not want to use their phone. A staff member can take the request directly and use the restaurant's established communication procedure. For a broader look at how this fits table service, see the guide to choosing where QR ordering fits.

Train staff not to promise that a meal is allergen-free simply because a request was entered. They need to be able to explain the restaurant's process honestly, ask for clarification and involve the appropriate kitchen lead when they cannot answer. If the restaurant cannot accommodate a request, tell the guest before preparation rather than making an assumption.

Fleksa's QR ordering lets guests scan, order and pay at the table in a browser. Before choosing a setup, ask to see how its available workflow handles item notes, changes, kitchen routing and acknowledgment for your service model. Compare your requirements with the workflows available from Fleksa, then run the worksheet with the staff who will use them.

Frequently asked questions

Is an allergy note on the order enough?

No. The note must reach the person responsible for the affected item, remain readable and be acknowledged before preparation. Unclear requests need a staff conversation.

Should a restaurant use checkboxes or free text?

Compare both against your menu and handoff. Structured choices can be easier to spot; free text can add detail. Test item association and staff visibility for whichever options you offer.

What if the kitchen never sees a correction?

Stop the affected item and use the staffed fallback to establish the current request. Ask the vendor how changes reach each station, and repeat the simulation before relying on that route.

Ready to grow your restaurant?

Explore how Fleksa can support ordering and operations in your restaurant.