A shared dish should appear once on the correct table check, with a clear way for staff to see who is responsible for it before anyone settles. Depending on your service style, that may mean assigning the whole dish to one guest, dividing its price between guests, or keeping it on the table check until a server confirms the allocation.
The right choice is the one your staff can explain and correct during service. A system that lets two people order from the same table does not necessarily let them identify or divide a shared item. Ask to see that specific workflow before you buy.
Choose who resolves the shared item
Start with the person who owns the table check. In a full-service dining room, that may be the server. In a counter-service restaurant, it may be the cashier who handles payment questions. A manager can handle unusual disputes, but routine allocation should not depend on finding a manager during a rush.
That person needs to answer three questions: Is the dish on the right table? Has it been recorded only once? Who will pay for it? The person who placed the order and the person who pays do not have to be the same guest.
Your service conditions affect the choice. If guests usually pay together, leaving a shared dish on the table check until checkout may be practical. If guests often leave at different times, staff need an earlier decision. Large parties, frequent seat changes and a busy dining room make a workflow that relies on remembering who ordered what harder to manage.
Also decide what happens when one guest does not use a phone. A server should have a clear way to add or communicate that guest's order and reconcile it with the same table. Ask the vendor to demonstrate how this works with your ordering and payment setup.
Map two guests and one appetizer
Use the following hypothetical example as a worksheet. Two guests, Ana and Ben, sit at one physical table. Ana orders an $18 main dish. Ben orders a $16 main dish. They agree to share one $12 appetizer equally. The food total is $46 before tax, tip or other charges.
- Table identification: Both guests scan the code for their table. The operator's requirement is that their orders reach the same table check. The server confirms the table identity.
- Individual items: Ana's main is associated with Ana and Ben's main with Ben. Each guest checks their own selection; the server handles a correction if an item appears under the wrong person.
- Shared item: One guest submits the appetizer once. The order placer checks that it has not been submitted twice. The server confirms that it is a shared item and records the agreed allocation using the available workflow.
- Before settlement: The server checks the allocation. An even division would put $6 of the appetizer with each guest: Ana's food share is $24 and Ben's is $22. Together, those shares equal the $46 food total.
- At settlement: The person handling payment confirms how tax, tip and any other charges are handled in the actual system. The example does not allocate those amounts.
The important distinction is between recording the dish and assigning responsibility for its price. A table check can show the appetizer correctly while still leaving staff unsure which guest should pay. Conversely, a note saying “share” may communicate intent without actually allocating anything for payment.
Ask the vendor to show what each guest sees, what staff see and what changes when the allocation is corrected. If a system cannot divide an individual item, ask whether staff can assign the whole item to one guest and agree on another arrangement with the party. Do not assume a note or a split-payment button performs item allocation.
Compare allocation approaches
Use this matrix to compare workflows, not product promises. The three approaches may require different screens, staff steps or configurations. Ask each vendor which steps are available in your quoted setup.
| Approach | Staff effort | Guest impact | Questions and cost dependencies |
|---|---|---|---|
| Assign the whole dish to one guest | Confirm who accepts it and correct the assignment if needed. | One guest pays the full item; the party must agree on any arrangement between them. | Can staff move an item between guest checks before payment? Ask about setup and support charges. |
| Allocate portions of the item | Enter or verify each share and check the total. | Each guest can see an agreed share if the checkout supports it. | Can one item be divided by amount or percentage? Ask whether the required payment workflow costs extra. |
| Keep the item on the table check until confirmed | Identify the unassigned item and resolve it before settlement. | Guests can decide later, but an early departure may require staff attention. | Can staff find unassigned items and prevent or correct an incomplete allocation? Ask about device and training costs. |
For the hypothetical two-person meal, equal allocation is the cleanest fit if the system lets staff record and verify both $6 shares. If it cannot, assigning the $12 appetizer to one guest is a workable fallback only if that guest agrees. Keeping it unassigned is acceptable temporarily, but the server must resolve it before settlement; otherwise, the check has an open question at the moment guests want to leave.
Compare the full operational quote, not just a processing rate. List fixed costs such as subscriptions and equipment, variable costs such as processing, and exception costs such as extra support or configuration when quoted. Ask what each quote includes and excludes. A payment-processing fee alone is not the cost of running the workflow.
For context, Fleksa QR ordering lets guests scan, order and pay at the table in a browser without downloading an app. Fleksa says it charges no commission on table QR orders; payment processing and applicable tax still apply. Check the Fleksa plans page and request a quote for your setup; pricing was checked in November 2026. Ask for a demonstration of shared-item allocation rather than assuming a particular method is available.
Run the unassigned-item test
Before selection, walk through the same scenario with each vendor in a simulation. Use a demo or test environment and sample orders. The simulation must not take a real card payment, send a message to a guest or dispatch a courier. If those effects cannot be disabled, stop before the action that would trigger them.
Ask a staff member who would normally own the table check to follow these steps while the vendor demonstrates:
- Open one table for Ana and Ben. Enter the two mains and one shared appetizer, leaving the appetizer unassigned.
- Find the item from the staff view without relying on the person who entered it to remember where it is.
- Record the agreed responsibility using the available method. For the equal-allocation requirement, verify whether the appetizer can be divided into two $6 shares.
- Review both guest views and the table view before settlement. Confirm that the appetizer appears once and that the two food shares add to $46.
- Change the agreement: Ana will take the whole appetizer. Ask staff to make the correction and show the resulting allocation before any payment action.
Pass: The responsible staff member can identify the unassigned appetizer and resolve it before settlement, with the resulting amounts visible and the item counted once. If equal item allocation is a requirement, the system must also show the two $6 shares correctly. Fail: Staff cannot find or resolve the item, the amount is duplicated or missing, or the required shares cannot be recorded. A whole-item assignment can pass a separate fallback test, but it does not pass the equal-allocation requirement.
Record the screens and steps involved, who must have permission to make the change, and whether the correction remains visible to the next staff member. Screenshots from the test environment and a short step count give you something concrete to compare. Also ask what happens if one guest wants to leave before the other has finished ordering.
If the system fails your requirement, decide whether the fallback is manageable. For example, the server could confirm one guest will take the entire appetizer and record that assignment through an available staff workflow. If even that cannot be done reliably, keep the allocation in your existing staff process and select a system only if the handoff is clear. Train the team on who checks the item and when; do not leave it to an informal note nobody owns.
After a successful simulation, a live service pilot is a separate decision. Brief the staff, choose a limited service period and use your normal procedures for real guest orders and payments. Review corrections with the team afterward. A simulation shows what a workflow can do under the chosen conditions; a pilot shows what staff encounter during service.
Check the table handoff before buying
The allocation test depends on orders reaching the right place first. Review how you create and manage table QR codes, especially when tables are moved or combined. Ask how staff distinguish one physical table from the guest parties using it, and how an order is corrected if a guest scans the wrong code.
Then follow the order through the staff tools. If you use a restaurant POS system, ask the vendor to demonstrate the handoff between the QR order and the check your staff actually use. Confirm which screen shows an unassigned item and whether a correction is visible wherever staff need it. A QR menu by itself does not establish that ordering, payment or shared-item allocation is available.
Give each vendor the same two-guest worksheet and write down its result. Compare the steps, the fallback and the quote against your busiest realistic service, not just a quiet demonstration. Then ask Fleksa to demonstrate QR ordering for your table workflow and show how staff would handle the unassigned appetizer.
Frequently asked questions
Is splitting a bill the same as allocating a shared dish?
No. Splitting a payment determines how a balance is settled. Allocating the dish identifies who is responsible for that item or each part of it. Ask to see both steps.
What if guests change their minds about who pays?
Have the responsible staff member update the allocation before settlement and check the revised table and guest views. Ask the vendor what corrections are possible after payment has started.
Can guests share a dish if the system cannot divide an item?
Possibly. With the guests' agreement, staff may be able to assign the whole item to one guest. Test that workflow and make sure the person responsible for the check knows how to apply it.
