A restaurant POS demo that follows a whole service

Prepare a tiny version of your restaurant

Choose two tables and five menu items. Include a long dish name, an item ordered in multiple quantities and a request that the kitchen must understand. Keep the expected prices and quantities on a separate sheet so you can compare them with the bill.

Use sample orders and avoid real customer details. Assign a cashier and someone to read the kitchen ticket. The observer’s job is to write down what happened, including anything that needs a second demonstration. A blank line on the worksheet is still untested.

Run the order from table to kitchen

1. Open the first table and enter two dishes and a drink.
2. Send the order through the intended kitchen workflow.
3. Read the table reference, quantities and notes at the printer or screen.
4. Open another table with a different order.
5. Return to the first table and add a later round.
6. Check that the kitchen can identify the additional work.

Posnic’s documented restaurant workflow includes KOT and open table orders. Bill Pondy’s demo should show the actual installed restaurant module. If you need captain ordering, a kitchen screen or multiple preparation stations, list each as a separate requirement and see it demonstrated.

Include the changes that happen during service

Cancel an item using the intended staff permission. Explain how the kitchen learns about that change. Request a copy of a kitchen ticket and check that it is distinguishable from new work. Then discuss moving a party, merging bills and item-level split requests if your restaurant needs them.

Do not label those exception paths as supported merely because there is a table view. Record the exact behaviour and the installed build. Where a task is not available, agree on a workable alternative before deciding that the setup fits.

Collect payment and check the paper

Review the full bill after the later round. Apply one approved discount and confirm the total. Demonstrate each payment method the cashier will record and any part-payment workflow you intend to use. Check the printed receipt for readable menu names and totals.

A recorded digital-payment method is not proof of bank settlement. Ask how staff verify payment with the relevant provider and how they handle a failed or uncertain transaction. Keep that routine distinct from the software demonstration.

Close the sample service

Find the completed orders in sales history and compare the report with your separate sample sheet. Review item quantities, discounts, payments and any open table. Ask the second staff member to explain what remains outstanding using the information on screen.

Try the cash-drawer closing calculator and worked example to compare a physical count with the cash movements in your sample service.

For a café or quick-service counter, repeat the exercise using the takeaway or counter-sale arrangement you need. A dine-in demonstration should not be the only evidence for a different service style.

Rehearse an interruption and write down the handover

Run out of paper in a controlled test or disconnect a test printer. Check how staff notice the failure and recover without sending an uncertain order twice. Separately, discuss the approved local-billing workflow when external internet is unavailable and test it with disposable data.

Finish by finding a backup and agreeing on a restore exercise in a separate environment. Record who owns setup, training and support. The downloadable worksheet is a blank aid for your observation; it is not a Bill Pondy certification or a claim that every listed control already passes.

Explore KOT billing, table management and offline billing and backups before arranging your demo.

Keep takeaway orders distinct during dine-in service

A café or restaurant may prepare the same dish for a table and for two people collecting parcels. Use this original sample in your demo: table T1 orders two dosas; takeaway A orders two dosas; takeaway B orders one dosa. These are illustrative references, not real customer orders. Ask staff to show the actual identifiers used by your installation.

The Posnic order-start manual documents separate dine-in and takeaway contexts. Saving a KOT records preparation work; payment is a later step. Confirm this on the Bill Pondy build and printers being demonstrated.

Swipe the table, or focus it and use arrow keys, to read all columns.

Preparation, payment and collection answer different questions. Do not infer collection from a paid receipt or payment from a kitchen ticket. If you require a token display, collection status or delivery integration, request that exact workflow; this example does not claim those controls are included. Agree how staff will record the handoff when it is handled outside the POS.

Add your observations to steps 21–25 of the restaurant demo worksheet. For uncertain kitchen output, use the KOT retry and reprint guide before sending another instruction. Keep all rehearsal transactions separate from live turnover.

Test café customisations before the takeaway rush

Two drinks can have the same menu name but different preparation instructions. For a café in Puducherry or Karaikal, use this fictional training order: two filter coffees at ₹40 each, one regular and one without sugar. These are sample prices, not Bill Pondy customer or market data.

Ask the demonstrator to enter the two choices using the configured modifier or note workflow. Read the saved order and the actual kitchen output: the instruction must apply to the intended cup, without changing the other cup. If the setup combines identical items into one line, demonstrate how staff preserve the distinction.

1. Check the first order: two coffees total ₹80 before tax or discounts. Identify which cup has the changed preparation instruction.
2. Test a priced addition separately: add one sample snack at ₹30 to this order. The expected subtotal is ₹110. Compare the saved lines and kitchen instruction; do not assume a preparation note changes the selling price.
3. Rehearse a later correction: after the first ticket, change one instruction in the training order. Ask how the kitchen learns which earlier instruction it replaces, and what staff do if preparation already started.
4. Hand over the parcel: have another staff member match the cups and snack to the order reference. Check payment evidence separately and explain how collection is recorded.

Posnic's order-start manual describes reviewing quantities and modifier choices before saving. This exercise asks you to validate the exact item-level behaviour, printing and later corrections in your installed setup; it does not promise automatic price adjustments or collection tracking.

Record the result in steps 26–29 of the restaurant demo worksheet. Keep the exercise in training data. For uncertain amendment printing, follow the KOT retry guide before sending another instruction.