October 9, 2026 · 8 min read
QR Table Ordering Without a POS: A Restaurant Guide
Run QR table ordering without POS integration: assign staff, receive orders and additions, handle bill requests, and reconcile payment with your usual till.
iMango Team
QR table ordering can work without a POS connection if someone owns the incoming order queue and staff carry each order through to the kitchen and payment. Guests send their choices from a table QR; the restaurant receives them in iMango's Orders workspace. Staff still manage preparation, service, the bill and the restaurant's usual cash or card process.
The useful starting point is one table and one complete service rehearsal. This guide shows that workflow, including a second round and closing the table correctly. For a broader service-model decision, read the QR menu vs QR ordering comparison.
Check whether your team can run a separate order queue
A small cafe or restaurant can use standalone table ordering when a staff member can watch incoming orders, pass them to the kitchen, and keep the till record aligned with what was served. It becomes difficult when everyone assumes someone else is watching the screen.
Before enabling it, answer three questions:
- Who checks Orders during service, and who takes over during their break?
- How does that person send each new order or addition to the kitchen?
- Who checks the combined table total and records payment at the till?
If those responsibilities are unresolved, keep a view-only digital menu while you work them out. A readable menu with staff taking orders is still useful.
The iMango QR ordering system receives table orders, additions and bill requests. It does not synchronize with a POS, print kitchen tickets, run a kitchen display workflow, split bills or process guest payments. Your existing kitchen and cashier routine supplies those parts of service.
Decide who does what
One person may cover several roles in a small venue. Assign the duties explicitly even when the owner is also the server and cashier.
| Guest action | Staff responsibility |
|---|---|
| Scan the QR at their table and choose items | Confirm the card belongs to that table and help guests who prefer to order verbally. |
| Send the first cart | Check the new order, review notes, pass it to the kitchen and set service to In progress. |
| Send another round | Open the added batch, send only the new items to preparation and check the updated total. |
| Request the bill | Check the full table order and prepare the bill using the restaurant's normal process. |
| Pay the restaurant | Verify receipt of payment, record it at the till, mark Paid, then mark service Completed when finished. |
This is a staff procedure. Changing an iMango status does not send a kitchen instruction or update a cash register.
Set up one table before a wider rollout
- Check the active menu. Review current prices, availability, required options and guest languages. Confirm the kitchen can fulfil the items shown.
- Create the floor and table in Tables. Use the same name staff use on the floor, such as “Table 4”. Check your plan's remaining table capacity before adding the rest of the venue.
- Download that table's QR. Place it on the matching table and scan the actual printed card. In the cart, check the table identification before sending anything.
- Review Settings. Enable table ordering and configure each weekday's opening hours. iMango currently uses Bangkok time for this schedule. Outside the configured hours, new orders and additions are blocked; guests can still browse the menu.
- Prepare the staff device. Sign in, open the restaurant's Orders workspace and assign its watcher. In Settings, choose browser notifications and sound on that device if useful. Browser permission and audio restrictions affect those alerts, so keep the order list under regular observation.
- Rehearse the full service cycle. Send a first cart, an addition and a bill request; check the kitchen handoff and till entry. Treat these as rehearsal orders, settle or cancel them appropriately, and confirm the table is ready before seating guests.
Use the table QR, rather than the main restaurant QR, for ordering. The main QR opens a browse-only menu. An enabled, available table QR adds the cart and submission controls during opening hours. Updating the main QR's appearance does not style the separate table QR.
Worked example: Table 4 orders, adds coffee and pays
This is an illustrative service rehearsal, not a customer result or a live test. Prices are example menu prices in baht. The example has no discounts, service charge or extra cashier items.
First cart: ฿270
One guest scans Table 4's QR, checks the table name in the cart and sends:
| Items | Calculation |
|---|---|
| Two chicken basil rice dishes | 2 × ฿90 = ฿180 |
| Two lime sodas | 2 × ฿45 = ฿90 |
| First batch | ฿270 |
The first successful submit creates a Pending service order. The watcher opens its composition, checks quantities and notes, tells the kitchen what to prepare, and changes the order to In progress. The order number is the reference for subsequent handoffs.
The guest's submitted-items drawer shows the items accepted from that browser. That confirms what was sent; staff still need to check and serve the order.
Another guest adds coffee: ฿330 in total
A second guest scans the same table QR on another phone and sends one iced coffee at ฿60. While the table's order is Pending or In progress, this becomes an additional batch on the same service order.
Staff see the new batch as Added HH:MM, with the same order number. They send one coffee to preparation, rather than sending the first four items again. The combined table total is now ฿270 + ฿60 = ฿330.
The phones do not share a live cart. Each guest builds their own cart and sees the submitted batches accepted from their own browser. Staff see the combined order for the table. Agree who is ordering each item so two guests do not independently send the same round.
The first guest requests the bill
On the browser that submitted the first batch, the guest opens Orders and chooses Ready to pay. The action is available when that order is In progress or Completed, remains unpaid, and ordering is enabled. A phone that only opened the QR, without successfully submitting to that order, cannot make this request.
Staff receive the signal and see Ready to pay in the Payment column. This asks for the bill; it does not charge the guest or confirm money received. Closing hours block new items but still allow an eligible existing order to request the bill from its submitting device.
The cashier checks the full Table 4 order, including the coffee, and prepares the ฿330 bill. If another addition is accepted before settlement, check the total again: an addition changes the bill and clears or supersedes the earlier ready-to-pay signal.
Staff record payment and finish service
The guest pays through the restaurant's usual method. Staff verify that payment was received and record the sale in the existing till, POS or cash book. Then they set Payment to Paid and service to Completed when the table's service is finished.
These are separate controls. Paid clears the bill-request signal but leaves the service status unchanged. Completed closes the active service order but can leave it Not paid. In this rehearsal, finishing with Completed + Paid records both outcomes before the next seating.
After service is completed or cancelled, a later submission from the same table QR can create a new order. The printed table QR stays the same.
Keep the kitchen record and till in agreement
Choose one handoff routine and use it for every batch. For example, the watcher writes the table and iMango order number on the kitchen slip, adds only newly submitted items, and checks them against Orders before sending the slip.
At settlement, the cashier should:
- compare the complete order composition with the kitchen slips and anything taken verbally;
- check the latest total, rather than an earlier screenshot or one guest's submitted-items drawer;
- account for any discounts, charges or manually ordered items using the restaurant's existing billing procedure;
- enter the sale once in the till and verify payment before marking Paid;
- close the service order when finished, so the next seating starts a new order.
In the Table 4 example, the records agree at ฿330 because everything was submitted through QR and no adjustments were needed. When staff take an extra item verbally, keep it in the normal restaurant record and explain any difference from iMango's total. This guide does not assume an admin button for adding manual items or an automatic POS transfer.
At the end of the shift, review unresolved unpaid orders and incomplete service orders separately. A payment check and a table reset solve different problems.
Keep staff-assisted service available
Offer a simple introduction:
“You can send your order from this table QR, or I can take it for you. We'll bring the bill and take payment as usual.”
If a guest cannot scan, loses connectivity or prefers a paper menu, take the order through your usual process. If the QR submission fails, check whether the order arrived before taking it again. This avoids preparing the same items twice.
Pause table ordering in Settings if the team needs to stop taking digital submissions. The menu remains available to browse, while staff take orders manually. Tell seated guests how to ask for help and the bill; the bill-request action depends on ordering being enabled.
Frequently asked questions
Can QR table ordering work without a POS?
Yes. In iMango, table QR submissions arrive in the restaurant's Orders workspace. Staff pass orders to the kitchen and enter sales in their existing cashier system manually. This requires someone responsible for the order queue and reconciliation.
Can guests order from the main restaurant QR?
No. The main restaurant QR is browse-only. Ordering uses a valid, available table QR with restaurant ordering enabled and the submission made within configured opening hours.
Does Ready to pay collect payment?
No. It tells staff that the table is asking for the bill. The restaurant takes payment through its usual process and marks the order Paid after verifying receipt.
Do guests at one table see the same cart or bill?
No. Each browser has its own cart and submitted-items history. Successful submissions join the same active table service order, which staff can view together. The guest drawer is not a personal or split bill.
What happens when guests order another round?
While the table order is Pending or In progress, a successful later submit adds a batch to the same order number and updates its total. Staff check that batch and pass only the new items to preparation.
Is marking an order Paid enough to reset the table?
No. Paid changes payment status. Staff must also finish service with Completed, or cancel the service order where appropriate. Completed and Cancelled close the active service order, allowing a later submission to start a new one.
Try the workflow on one table
Review iMango's table ordering workflow, then sign in and set up one table. Rehearse the first order, an addition, the bill request and both closing controls with your staff. Expand only when the kitchen handoff and till record work together.