Skip to article
← Back to Blog
Operations

Keep Dietary Preferences With the Right Guest in QR Table Orders

By Fleksa8 min read•QR ordering, Table service, Restaurant operations

A table number alone may not tell the kitchen or runner which guest requested a change. Use this four-guest example to evaluate item notes, ticket details, seat changes, and the handoff before choosing QR ordering software.

To keep a dietary preference with the right dish, give staff a way to identify both the guest and the item, then carry the note with that item from the cart to the kitchen ticket and the runner handoff. A table number identifies where food goes; it does not identify who gets each plate.

Before buying, ask a vendor to show the complete path for a shared order. Look for the guest or seat reference, the dish, and its preference together at every handoff. If any part disappears, decide whether staff have a reliable manual step to recover it. Route allergy requests through a separate, staff-confirmed process rather than treating a preference note as confirmation that a dish is safe.

Identify guests within a shared table order

Start with a simple table map. Give each guest a reference that can travel with the order, such as a seat number or a short label agreed on by staff. The reference should distinguish people at the same physical table, not just identify the table itself.

For the following hypothetical example, four guests sit at table 12. Their preferences are ordinary preparation requests, not allergy declarations:

  • Seat 1 orders a grain bowl with no onions.
  • Seat 2 orders the same grain bowl with dressing on the side.
  • Seat 3 orders a vegetable wrap with no cheese.
  • Seat 4 orders a vegetable wrap with extra sauce.

Two pairs have the same base dish. That makes a table-level note such as “no onions, dressing on side” too ambiguous: the kitchen and runner cannot tell which bowl gets which request. Even if a cook prepares both correctly, the runner still needs enough information to place each dish in front of the intended guest.

Agree on how seats are numbered. For example, the host or server can choose a fixed starting point and number clockwise. The exact convention matters less than using it consistently and making it visible to the people who enter, prepare, and deliver the order. If guests choose their own labels, ask how staff can match those labels to people without calling out personal information across the table.

Seat references are not permanent identities. People move, swap chairs, or order before everyone has arrived. Decide whether the label follows the person or the physical seat, and tell staff how to handle a change. A practical approach is to let the original order reference follow the guest while the server tells the runner where that guest is now sitting. Do not silently renumber an order already being prepared.

Also decide what happens when a guest cannot or does not want to use a phone. A server needs a way to take that order and preserve the same guest and dish references. Otherwise, the digital part may be organized while the staff-entered item becomes the one that is difficult to deliver.

Attach each note to the correct dish

The useful unit is not just the table or the guest. It is the combination of guest reference, specific dish, and specific note. Ask to see that combination in the cart before the order is submitted. Then follow it onto whatever the kitchen actually uses: a printed ticket, a kitchen display, or another production view.

In a shared cart, check whether a guest reference can be associated with each item rather than entered once for the whole order. Also check whether a note belongs to one item or appears as a general order comment. A general comment can be useful for a table-wide request, but it is a poor substitute for an item-specific preference when similar dishes are being prepared.

Individual guest carts can make ownership clearer at the start, but they create a different question: when orders reach the kitchen, can staff still see that they belong to the same table, and can a runner identify each item? Separate carts do not by themselves guarantee a useful ticket or a clear handoff.

Ask the vendor to demonstrate these situations in the actual workflow you are considering:

  1. Two guests choose the same dish with different notes.
  2. One guest orders two of the same dish, with a note on only one.
  3. A guest edits or removes an item before submitting the cart.
  4. A server adds an item for a guest who did not order by phone.

For the second situation, “seat 1, two bowls, no onions” may still leave a question: do both bowls get the change? The cart and ticket need to make the quantity and scope of the note clear. If they cannot, staff should split the items or confirm the intended preparation before sending the order onward, using whatever steps the system supports.

Pay attention to truncation and placement. A note that is visible in the cart but cut off on the ticket has not completed the journey. A note printed far from the item may be easy to miss during a busy service. Ask whether staff can open the full text and whether the runner sees the same meaningful distinction.

Fleksa's QR ordering lets guests scan, order, and pay at the table in a browser without downloading an app. Ask Fleksa to show how your preferred guest labels and item notes appear in the specific setup you would use; do not assume that a QR menu alone includes ordering, payment, or item-level note handling.

Check the kitchen and runner handoffs

A kitchen ticket should answer three separate questions: what to make, what change applies, and which guest reference belongs to it. The runner then needs to connect the finished dish to that reference. A correct kitchen note is not enough if the plate leaves the pass with no reliable distinction between two similar bowls.

Use the four-guest order as a walkthrough. The kitchen should be able to distinguish the onion-free bowl for seat 1 from the bowl with dressing on the side for seat 2. At the pass, staff need a clear method to retain that distinction until delivery. Depending on the operation, that may involve a ticket, an expediter's verbal confirmation, or a separate plate-identification convention. Choose a method staff can follow without guessing from the appearance of the food.

Now change the situation: the guests originally identified as seats 1 and 2 swap chairs after ordering. The order references stay with the guests, but their physical positions have changed. The server tells the runner about the swap, and the runner confirms the intended recipient before placing the bowls. If the team instead uses labels tied to physical seats, establish an explicit update and confirmation procedure so the ticket and the runner do not use conflicting references.

Run this as a simulation first, with clearly marked practice data. Do not send a real guest message, take a real card payment, or dispatch a courier. Walk the practice order through each available screen and handoff with the people who would use them. Record where a reference or note is missing, hard to read, or requires a manual explanation. If the system cannot safely isolate practice orders from live operations, ask the vendor for a demonstration environment.

A live service pilot is different. Once the practice workflow is understood, use a limited live pilot only with trained staff and normal oversight. Observe whether staff can maintain the references during actual service, and correct the procedure when a handoff is unclear. A simulated pass is a useful preparation step, not proof of performance under service conditions.

If a guest raises an allergy or another request requiring a safety confirmation, stop treating it as an ordinary preference exercise. Have a staff member discuss the request and follow the restaurant's allergy-handling process, including checking preparation and cross-contact concerns as appropriate. A note on a ticket does not establish that a dish is safe.

Use a trace table to evaluate the workflow

The table below combines ticket and runner details in one column so the full path is easy to review. It describes the intended handling of the hypothetical order, not a demonstrated product capability. During a vendor walkthrough, compare each row with what staff can actually see and do.

GuestDishPreference noteTicket and runner handoff
Seat 1Grain bowlNo onionsTicket identifies seat 1 and this bowl's note; runner confirms the bowl goes to that guest.
Seat 2Grain bowlDressing on the sideTicket identifies seat 2 and this bowl's note; runner distinguishes it from seat 1's bowl.
Seat 3Vegetable wrapNo cheeseTicket ties the note to seat 3's wrap; runner keeps that distinction through delivery.
Seat 4Vegetable wrapExtra sauceTicket ties the note to seat 4's wrap; runner distinguishes it from seat 3's wrap.

Review the rows with a server, a cook, and a runner. If the kitchen sees seat references but the runner does not, identify who transfers that information and how. If a runner must ask the table which plate is which, decide whether that is acceptable for an ordinary preference and what happens when the guest has moved. If a note cannot be tied to one item, ask whether a different entry method can make the distinction clear before the order is sent.

Include corrections in the demonstration. What happens if a guest changes a preference after submission? Who tells the kitchen, and how does the runner know which instruction is current? Ask what the software supports and write down any staff steps needed alongside it. For an allergy request, use the staff-confirmed process rather than relying on an edited note alone.

Finally, check the wider service fit. Ask how table identity is assigned, how staff see payment status, and how a non-phone order joins the workflow. If you use a restaurant POS system, ask how the relevant ticket and item information moves between the ordering and production tools in your intended setup. The guide to where QR ordering fits in table service can help you decide which steps should stay with staff.

Next step: Bring the four-guest trace table to a Fleksa discussion and compare it with your own service flow. Ask for a walkthrough of guest references, item notes, kitchen views, and runner handoff, and confirm feature availability for your setup.

Frequently asked questions

Is a table number enough for a shared QR order?

No. It shows the destination but may not distinguish guests or similar dishes. Add a consistent guest reference and keep each preference attached to its specific item.

What if guests change seats after ordering?

Use a clear convention for whether the reference follows the person or the chair. Communicate changes to the runner and confirm the recipient instead of silently changing an order already in preparation.

Can an item note replace an allergy conversation?

No. An item note can carry information, but staff should confirm allergy requests through the restaurant's established process and address preparation concerns before accepting the order.

Ready to grow your restaurant?

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