Use a restricted QR menu when the event has a set package, different prices, limited production capacity, or items that other restaurant guests can order but event guests should not. Use the normal menu when the same items, prices, payment rules, and service process genuinely apply to everyone.
The choice is not just about shortening a list. A guest needs to know what the host has already covered, what costs extra, and how an order reaches the right staff. Before choosing a setup, write those rules down and ask the vendor to demonstrate them.
Map what is included and what guests buy separately
Start with the event agreement and turn it into an item-by-item service list. For each food or drink, identify whether it is included, available for an additional guest payment, paid by the host later, or unavailable during the event. Then note any quantity or time limit.
Separate the guest-facing rule from the kitchen instruction. “One dessert included” is a guest rule. “Send the dessert to the pastry station with the event identifier” is a production instruction. Both need a workable path, whether that path is software or a staff handoff.
For example, if a host covers appetizers but guests pay for drinks, decide what happens when someone orders both together. Can the system distinguish the two charges and show the guest only the amount they owe? If not, a server may need to handle one part of the order. Do not assume a zero-dollar menu item proves that the host's package has been tracked correctly.
Also decide how staff will handle requests outside the package. A guest might want an unavailable dish, have an allergy question, or want to add a drink to a host-paid tab. Give staff a clear answer and a way to contact the host when approval is needed. Keep a non-phone ordering option for guests who cannot or prefer not to scan.
A hypothetical event decision
Suppose a restaurant hosts a two-hour reception. The host includes one flatbread per guest party, while guests may separately buy a $6 dessert. A guest party is a group ordering together; it is not necessarily the same thing as a physical table. The restaurant must decide how staff will recognize a party and prevent a second included flatbread from being treated as part of the package.
Three guest parties each buy one dessert. That produces $18 in dessert sales. This is sales revenue, not profit or an operating-cost estimate. Fixed costs, variable costs, exception costs, payment processing, applicable tax, and any host deposit are excluded. The host's included flatbreads are not guest-paid dessert sales.
In this example, a restricted menu is the better starting choice because the included-item limit and separate dessert payment differ from ordinary service. It is acceptable only if the vendor can demonstrate the necessary controls or the restaurant has a reliable staff procedure for them. Otherwise, use a staff-led process rather than asking guests to navigate an unclear menu.
Compare event and normal menu visibility
A restricted menu can make the package easier to understand and keep guests from ordering dishes the kitchen has not planned to serve. It also requires setup and a removal plan. Ask whether the event menu can be shown only to the intended guests, how it is activated, and whether changes affect the regular dining room.
The normal menu avoids maintaining a second list. It works best when event guests can buy the same items at the same prices, with the same payment and fulfillment process as other diners. Before using it, check whether a guest could order something the host did not authorize or the kitchen cannot make during the reception. A verbal warning from a server is a weak substitute for an accurate ordering screen.
Use the worksheet below to record the decision. The acceptance criteria are examples to adapt to your agreement, not assumptions about a particular product.
| Decision point | Evidence to request | Owner's acceptance criterion |
|---|---|---|
| Menu visibility | Show what an event guest and a regular diner each see. | Event guests see only the agreed items; regular service keeps its intended menu. |
| Included flatbread | Show how the order is identified and how the party limit is handled. | Staff can recognize the included order and stop or resolve a duplicate before production. |
| Paid dessert | Show the guest price, payment step, and staff-facing order status. | The guest can see the $6 charge and staff can distinguish a paid order from one awaiting payment. |
| End of event | Show who can deactivate access and what happens to open orders. | New event orders stop at the agreed time; staff can finish or resolve orders already received. |
Read the rows together: a menu that displays the right items still fails the decision if staff cannot enforce the included-item limit or recognize a paid extra. Add your own rows for host billing, dietary information, or kitchen timing when those affect the event.
Ask the vendor to show the actual guest and staff screens for your intended configuration. If a rule requires a workaround, write down who performs it and what they do when the restaurant is busy. A workaround that depends on one person remembering every party's order deserves particular scrutiny.
Check routing for an included item and a paid extra
Trace each order from the guest's choice to fulfillment and payment status. For the flatbread, identify where the order appears, who checks the party's allowance, and how the kitchen knows it is an included event item. Decide what happens if a party submits another flatbread request: hold it for staff review, decline it, or offer a separately priced item if the event agreement allows that. The vendor should show which of those paths the setup supports.
For the dessert, check that the guest sees the price before confirming and that staff can tell whether payment has been completed. Ask how a canceled or changed order is handled and who can resolve a payment question. If the host is paying for an extra instead, establish a separate host-approval and billing procedure rather than assuming the guest payment flow covers it.
Fleksa's QR ordering lets guests scan, order, and pay at the table in a browser without downloading an app. A QR menu by itself does not necessarily provide ordering or payment. Ask whether the event-specific visibility, included-item limits, and routing you need can be configured for your service model.
Consider the staff view as carefully as the guest view. Does the order carry enough context for the right person to act? If the event shares a kitchen with regular service, decide how staff will identify its orders and handle a backlog. Your restaurant POS system may be part of that handoff; ask the vendor to show the actual flow rather than relying on a feature list.
Run a safe simulation, then consider a service pilot
Before guests arrive, walk through both paths in a simulation with staff. Use a test environment or another vendor-approved method that does not create a real payment, guest message, or courier dispatch. Include a duplicate flatbread request, a dessert awaiting payment, an unavailable item, and a guest who needs a server. Record what staff see and whether they know the next action.
If you want evidence from an actual service pilot, plan it separately. Agree on its scope, staff coverage, guest instructions, and how real transactions and orders will be handled. Do not call a simulated check proof that the full service will run without problems.
Assign activation, guest instructions, and removal
Name one person responsible for turning the event menu on and another who can cover if that person is unavailable. Before opening, they should check the visible items and prices, confirm the kitchen is ready, and tell servers how included orders and paid extras are handled. Give the host a brief explanation so they can answer guest questions.
Guest instructions should be short and match the screen: what is included, what costs extra, how to order, and whom to ask for help. If the allowance applies per guest party, explain how the party is recognized. Do not leave guests to infer that a free-looking item has a limit.
Set an end time and decide who removes or disables event access. Ask what happens if someone has the menu open at that moment and how staff will find orders that are still awaiting fulfillment or payment. The closing owner should check those orders, tell the kitchen when no more are expected, and restore or confirm the normal menu as needed.
Finally, keep the decision with the event paperwork: the agreed menu, the owner of each handoff, the vendor demonstration results, and any unresolved exceptions. For a broader look at the role of scanning alongside servers, see the guide to QR ordering in table service.
Next step: Fill in the worksheet for your next event and use it to compare your requirements with Fleksa. Ask for a demonstration of the relevant workflow before buying.
Frequently asked questions
When is the normal restaurant menu enough for an event?
It can be enough when event guests have the same choices, prices, payment rules, and service process as regular diners. Confirm that no visible item conflicts with the host's agreement or the kitchen's event capacity.
Can an included item simply be listed at zero dollars?
A zero price may show that the guest owes nothing for that item, but it does not by itself establish who is entitled to it or enforce a quantity limit. Ask how the limit is tracked and what staff do with a duplicate request.
What if a guest cannot use the QR menu?
Give them a staff-led way to order under the same event rules. Make sure the server can identify included items, explain extra charges, and pass the order to the kitchen using the agreed process.
