Scanning a menu is only the first step.

Name the journey before comparing features

A QR code can open a menu for reading without creating an order. A guest-ordering page adds a basket and a submission step. A payment code serves another purpose: paying an amount does not, by itself, identify every dish or tell the kitchen what to prepare. Ask the supplier to demonstrate each promised step instead of treating the word QR as a complete feature description.

Captain ordering is a staff workflow. The captain chooses or confirms the table, enters the guest’s request and sends it through the restaurant system. A guest-facing page needs its own checks for table identification, current availability, order acknowledgement and help when something is unclear.

Run a two-table test with different dishes

Use training tables A and B. At A, request one idli plate at Rs.70 and one coffee at Rs.30: a sample subtotal of Rs.100. At B, request one dosa at Rs.120. These are fictional menu values before taxes or other charges. Record each saved order reference and inspect its table, items and quantities at the counter.

Now open the table-A code on a second phone. Ask the demonstrator to explain whether it identifies a table, asks the guest to select one or follows another supported identification process. Do not assume that a table tent, browser tab or remembered address proves which table the next submitted order will use.

Have the kitchen read back the A and B instructions independently. The correct food appearing under the wrong table is a failed test even if the totals are right. If your restaurant uses shared tables or takeaway, repeat with that actual service pattern rather than inventing a table for a parcel guest.

Check the printed card at its physical table

Before printing a full batch, place two sample cards at training tables A and B. Scan the card while standing at the table where it will be used. If the ordering route identifies a table, compare that visible identity with the physical label before submitting. If the route instead asks the guest to choose a table, check the selection step. If it is menu-only, record that no table assignment or order submission is expected. A successfully opened page is only the first check.

If cards identify different tables, deliberately swap the two cards in a supervised training session. Ask a colleague who did not move them to perform the same scan-and-check procedure. The test should reveal the mismatch before an order is submitted. This tests your placement and staff procedure; it does not assert that the software can detect where a printed card is physically located. Restore the cards, repeat the check and record the physical table alongside the destination actually observed.

After replacing a damaged card or rearranging tables, repeat this check at the affected seats. Keep the approved print file and its intended destination together so that staff do not reprint an outdated card from an unrelated message. Where a card opens only a general menu, make that purpose clear on the card rather than implying that scanning it assigns an order to the guest’s seat.

Check acceptance before preparing or retrying

Ask when a submitted guest request becomes an accepted restaurant order and which person or screen acknowledges it. Some proposed workflows may include a staff review; others may send an accepted order onward immediately. Demonstrate the installed behavior and agree who watches for new requests.

If the phone shows an uncertain result, inspect the existing order record before submitting again. Record the reference, approximate time and requested items for staff to check. Do not rehearse this with real payment or live kitchen preparation. A refreshed page, basket disappearing or a sound alone is not enough evidence that the intended order was saved exactly once.

Test an unavailable dish in a controlled demo. Compare the readable menu, selectable ordering items and final acceptance response. A dish can remain on an informational menu while being unavailable to order; confirm how your selected setup communicates that distinction to guests.

Keep ordering and payment checks separate

First show that the intended order reached the restaurant. Then demonstrate the agreed payment route using the provider’s supported test procedure where available. Ask staff to show how the bill reference and amount are matched, how an unresolved payment is handled and where the final result is checked.

Do not promise automatic payment confirmation merely because a code can be scanned. A payment receipt, a pending order and an accepted kitchen ticket answer different questions. Include cash-at-counter service if that is part of your restaurant’s actual process, and let the cashier demonstrate the normal recorded payment method.

Choose the route your staff can operate

A restaurant that only needs a readable menu should not assume it also needs guest self-ordering. If you want guests to submit orders, nominate the person who handles unclear selections, unavailable items and requests for help. Keep a staff-assisted route for guests who cannot use their phones.

For your DeccanPro demonstration, ask to see the public menu and guest order-submission steps separately from captain ordering. Confirm which channels will be activated for your restaurant, how guests reach them and whether a payment provider is part of the proposed setup. Check the installed version and configuration you will receive.

Bring two phones, your proposed table labels and a short menu to a Chennai demonstration. Record which steps passed and which need configuration or another service. Keep the Rs.6,000 annual software offer separate from any quoted equipment, connectivity or payment-provider costs; confirm the required channel setup before printing table materials.