A restaurant POS that connects the counter, floor and kitchen.

Four parts of a practical restaurant system

The counter is where staff review orders and complete bills. Captain phones let staff enter table orders on the dining floor. A KOT printer provides a paper instruction for preparation. A kitchen display gives the team a shared view of open tickets. DeccanPro brings these workflows together, with optional arrival sounds and spoken order details.

Not every restaurant needs every device on day one. A small counter can start its evaluation with ordering, kitchen tickets and billing. A larger dining room should test the captain route and screen placement as well.

• Selected table: the blue 02 tile on the left matches Table 02 on the right. Ask your captain and cashier to identify the same table before checking its items.
• Kitchen ticket: the selected table shows 1 Active KOT. In your demo, add another round and inspect what changes; a still image cannot show how a new instruction reaches the kitchen.
• Sample total: one Chole Masala at Rs.160 and one Chicken Biryani at Rs.260 add to the displayed Rs.420. These are demo menu prices, not your restaurant menu or the software subscription price.
• Next actions: Modify, Cancel, Discount, Sale Print and Settle are visible. Ask the demonstrator to perform the actions you need with the intended staff account and explain the resulting order, kitchen and payment records. A visible button alone does not establish permissions or completed payment.

One table can have more than one open kitchen order

In a working DeccanPro demonstration on 22 September 2026, we created Table4 for two guests and saved one idli plate at Rs.70 and one masala dosa at Rs.120. The counter KOT page showed one active order totalling Rs.190. Reloading the page retained both items and their quantities. These are sample menu prices in an isolated training setup, not a customer restaurant or a live bill.

We then used the table’s new-order action to save one masala tea at Rs.30. Table4 showed two active KOTs: the original Rs.190 order and a separate Rs.30 tea order. That distinction matters at a busy Chennai tiffin restaurant: selecting the right table does not, by itself, identify which open order you intend to change.

For your demo, ask staff to distinguish adding an item to an existing order from opening another order on the same table. Read the items and current total before saving. Our observed new-order result does not establish that separate orders automatically merge into a single bill; demonstrate the intended billing and kitchen handoff separately.

• This check used the counter’s table/KOT management page. It was not a separate captain-phone or kitchen-display test.
• Printer output, payment settlement and changes to an existing KOT require their own demonstrations on your intended equipment.

Choose a demonstration that matches your service

Start with the work your team repeats most often. A parcel counter, a cafe with a few tables and a table-service dining room can use the same software features while needing different demonstrations. Pick one service pattern below and let the people who will do that work run the sample order. If you combine formats, test the handoff between them as well.

Use your menu names and intended equipment, with agreed training data outside live service. Record where each order is entered, where the kitchen receives it and who checks the bill or collection. The comparison helps choose a test; it does not prescribe a device count or make extra hardware part of the annual software price.

Draw the connections before buying hardware

Mark the counter, kitchen, tables, router and available power points on a simple floor sketch. Note walls or separate floors between the captain and the restaurant server. Ask which devices connect by cable and which rely on Wi-Fi. The kitchen screen must be readable from the place where people actually work.

For a local setup, the core application and database can run on a shop computer or local server. Captain devices still need a working connection to that server. A cloud-server connection and online services need internet. Local operation does not remove the need for power, backups or a functioning restaurant network.

Decide what to reuse and what to test first

Start with your existing equipment. Record its model, operating system and connection type in the site-survey worksheet, then use these checks to decide what can be reused. Compatibility needs a test with your actual devices.

Decide what to buy from the test results

For each device, mark the outcome as reuse verified, needs a further test, purchase quoted or not needed for this setup. An untested item stays unverified even when a similar model worked in another restaurant. If the demonstration uses the vendor’s printer or phone, record that difference and arrange a test with your intended device before treating compatibility as established.

For example, a counter computer may pass the menu test while a captain phone fails to reach the server from an upstairs table. That result calls for investigating the connection at that location; it does not by itself prove that either device must be replaced. Keep the failed step and retest result together. Use a supervised practice order outside live service and agree before any network or equipment changes.

Keep hardware and supplier quotations separate from the software price. Bring the completed survey and floor sketch to your Chennai demo so each purchasing question has a test result behind it.

• Identify the actual device and its intended location.
• Write down the tested task, order reference and observed result.
• Name the unresolved question and the person who will answer it.
• Record a retest before changing an unverified item to verified.

Follow one order through three people

Try this practice order with your captain, kitchen operator and cashier: Table 4 orders two plain dosas and one coffee. Send the first kitchen instruction. Then add one coffee as a second round. Before preparation, agree to remove one dosa and demonstrate how that change reaches the kitchen. The expected final order is one dosa and two coffees. These are training quantities, not live cooking instructions.

Ask each person to identify the same table and current order. A second-round ticket may show only additions, so reconcile the complete order and its updates instead of treating the newest slip as the entire bill. Finish when the kitchen understands the agreed change and the cashier sees the correct final quantities on the tested devices.

Record what passed, what failed and who will fix it

Write down the device, order reference, step and observed result whenever a test fails. For example: the counter shows the added coffee, but the kitchen printer produces no update. Check the current kitchen record before retrying so staff do not prepare the same addition twice. Keep unresolved issues on the demo scorecard and repeat the same scenario after a correction.

Finish with the staff member who will own the opening check and backup routine. Identify where backup copies go and arrange a restore demonstration using a safe test copy. Agree on a manual service fallback for a power or network interruption. Do not assume that installing a POS automatically provides a recovery plan or that an internet-independent setup works without its local network.