Restaurant software fails in a specific place: between the order being taken and the food arriving. Everything else - the reports, the dashboards, the loyalty programme - is decoration on top of that one flow. If the kitchen ticket is late, wrong or silently lost, nothing else the software does will save the evening.
This guide covers what to test in that flow, how to think about table state, and the two integrations that quietly decide whether your figures ever reconcile: online orders and payments.
The kitchen ticket is the whole system
Order taken, ticket printed, food cooked, bill raised. Every restaurant system does this. The differences appear at the edges: a customer changing their mind after the ticket has gone, an item that needs to come after the mains, a table splitting into two bills, or a printer running out of paper mid-service.
Test the modification path specifically. When an item is removed from a fired order, does the kitchen get a cancellation slip, or does the waiter have to walk over and say so? When a ticket fails to print, does anybody find out? A system that treats the kitchen printer as fire-and-forget will lose orders on the busiest night of the year and show you nothing in the reports.
- Course timing so starters and mains do not arrive together
- Modifications and cancellations that reach the kitchen as their own slip
- Separate tickets to separate stations - kitchen, grill, bar
- A visible alert when a ticket fails to print rather than silence
- Item notes that survive to the kitchen slip legibly
Table state is more than a floor picture
Most demos show a pretty floor plan. What matters is whether the state behind it is reliable when three people are touching it at once. Two waiters opening the same table, a table merged with its neighbour for a large party, a customer moving from the bar to a table mid-meal - each of these will happen in your first week.
Ask how the system prevents two devices from billing the same table simultaneously. The answer should involve the table being locked or the order being reconciled, not "that does not happen". It does happen, and when it does you either lose an order or charge a customer twice.
- Merge and split tables without losing fired items
- Move an order between tables with the kitchen informed
- Two devices on one table handled without double billing
- Takeaway, delivery and dine-in tracked distinctly for reporting
Wastage and consumption are where the margin hides
Food cost is the difference between what you bought and what you sold, and it is almost never what a recipe card says. Software that only tracks sales tells you revenue but not whether you are being robbed. Software that tracks consumption against sales tells you that eight kilos of paneer left the store and six kilos worth was billed.
This does not require full recipe costing on day one, which is a project most restaurants abandon. It requires that the store issues stock to the kitchen as a recorded movement, that wastage is entered rather than absorbed, and that somebody sees the variance weekly. Start there and add recipes later if the numbers justify it.
- Store issues to kitchen recorded as movements, not adjustments
- Wastage entered with a reason and visible in a report
- Purchase rates tracked so cost changes are noticed
- Variance between consumption and sales available weekly
Online orders and payments must land in the same books
The moment you accept orders from an aggregator, you have two sets of numbers. If the aggregator orders do not flow into the same sales register as your dine-in bills, your daily total is a manual addition, your GST filing is a reconciliation exercise, and your stock never reflects what actually left the kitchen.
The same applies to payments. Card and UPI settlements arrive net of charges and a day or two late. Software that records the gross bill and lets you reconcile settlements against it will save your accountant days a month. Software that only records "paid" will not.
- Aggregator orders in the same sales register as dine-in
- Commission and discount recorded so net revenue is visible
- Settlement reconciliation against gross bills
- One day-close covering every channel
The shortlist checklist
Take this to any vendor, ours included. If a question cannot be answered with a straight demonstration rather than a promise, treat it as unanswered.
- Fire an order, modify it, and confirm the kitchen learns about the change.
- Unplug the kitchen printer mid-demo and see whether anyone is told.
- Split one table into three bills with different payment modes.
- Open the same table on two devices at once.
- Enter wastage and find it in a report without help.
- Check that an aggregator order appears in the same day-close as dine-in.
- Run a day-close and compare it to the sum of the bills.
- Ask who can delete a fired item and where that is recorded.
Restaurant software built around the pass
Our restaurant solution covers table and floor view, kitchen tickets, menu and kitchen stock, wastage and reservations - with day-close that includes every channel.