QR table ordering · Built for Indian restaurants
Every table takes its own order.
They point a camera at the code on the table, read your whole menu, order and pay. It is on your kitchen screen before the phone goes back on the table.
- No app to install
- No diner login
- UPI or pay at the counter
- Built to load on 3G
A phone showing the Spice Garden menu at Table 4: Paneer Tikka, vegetarian, ₹280.00; Butter Chicken, non-vegetarian, ₹380.00; Paneer Butter Masala, vegetarian, ₹300.00; Kadai Paneer, vegetarian, ₹300.00, unavailable today. A cart bar totals 3 items at ₹1,008.00.
Example: a table card, and the menu it opens.
What that means in practice
0
apps to install
It opens in the browser the diner already has. No account, no OTP, no password.
1
scan
The table, the session and the whole menu arrive in a single response.
8
order states
One state machine the server enforces. No order sits in a state nobody owns.
12 h
table session
The table stays theirs for the sitting, with nothing to log in to.
These are facts about how the product works, not customer numbers.
Why restaurants put it on the table
Four things stop happening on your floor.
Every one of them is a thing your staff currently do by hand, in the middle of service.
Nobody waits to be noticed
The wait for a waiter to come over stops existing. A table that sits down can order in the same minute, and a second round does not need anyone flagged down.
Your staff stop being order-takers
The order arrives at the kitchen already written down and already priced. The people on your floor go back to carrying food and looking after tables.
No more misheard orders
The diner picks the dish from your own menu and reads their own cart back before confirming. Nothing is repeated across a noisy room, so nothing is repeated wrong.
Nothing to download, nothing to buy
It opens in the browser already on their phone — no app, no account, no OTP. On your side there is no terminal and no POS box to integrate with.
How it works
Four things happen, in this order.
Start to finish, about ninety seconds. No hardware to buy and nothing for the diner to download.
01
They scan.
They point a phone camera at the card on the table. No app, no account, no typing.
02
They choose.
Your whole menu opens with veg and non-veg marked, and they add what they want to a cart.
03
They order.
They pay by UPI or choose to settle at the counter, and the order is placed.
04
Your kitchen accepts.
It lands on your board with the table, the items and the total — and the diner watches it move from Accepted to Ready without asking anyone.
Reliability
An order that cannot be lost.
The one failure this product cannot have is a diner who paid for an order the kitchen never saw. So placing an order is a single transaction, and the lifecycle is a table the server enforces — not a convention the apps agree to follow.
One transaction.
The idempotency check, cart validation, server-side pricing, the day’s order number under a row lock, the items and the first status event. All of it, or none of it. A double-tapped “Place order” on a stalled connection returns the original — it cannot send the kitchen a second one.
Eight states, one table.
Six forward, two ways out. The server tells each screen which moves are legal, so two staff phones tapping Accept in the same second cannot both win.
Live, with a real fallback.
The socket carries a hint; the client refetches the truth. A dropped frame is harmless, and polling is a complete substitute rather than a degraded mode.
Numbers stay integers.
Money is integer paise end to end and tax is basis points. No float ever touches a bill, and an order line keeps its own snapshot of the name, price and food type — so editing your menu never rewrites yesterday’s receipt.
The staff order board for Spice Garden, accepting orders. Order A-014 for Table 4, placed two minutes ago, preparing, two Paneer Tikka and one Dal Makhani, ₹820.00. Order A-015 for Table 9, just now, new, one Butter Chicken, ₹380.00. Order A-013 for Patio 1, fourteen minutes ago, ready, one Chicken Tikka and two Butter Naan, ₹1,020.00.
Payments
Take payment the way your counter already does.
Pay by UPI from the seat, or settle at the counter. Both place the order the same way — the difference is only when the money moves.
Said plainly.
A static UPI QR cannot confirm that money arrived. The diner sees a payment reference and “awaiting confirmation”, and a staff member taps Mark as paid once the credit lands — the same trust step as cash, which is how your counter already works. tableX is never in the middle and takes no cut of the transfer. If you want automatic reconciliation, a gateway drops into the same slot without changing anything the diner sees.
A payment screen: a UPI QR code for ₹1,008.00 at Spice Garden, Table 4, awaiting confirmation. Below it, the pay-at-counter option, order placed, which staff mark as paid at the counter.
For your staff
Your floor, on one screen.
Staff open one board at the start of a shift and leave it open. New orders arrive with the table, the items, the total and how the diner is paying — and announce themselves with a sound.
The staff order board for Spice Garden, accepting orders. Order A-014 for Table 4, placed two minutes ago, preparing, two Paneer Tikka and one Dal Makhani, ₹820.00. Order A-015 for Table 9, just now, new, one Butter Chicken, ₹380.00. Order A-013 for Patio 1, fourteen minutes ago, ready, one Chicken Tikka and two Butter Naan, ₹1,020.00.
The admin order board. It runs as a separate app at admin.tabley.in.
Accept, prepare, ready, served.
Every transition checked server-side, with a reason required on a reject or a cancel — and the diner sees the reason.
Accepting orders is one switch.
Turn the floor off at the end of service without editing the menu. The menu stays readable; the Add buttons go, and the diner is told at the top rather than at checkout.
Ratings that name a shift.
Food and service reported separately, never blended. “Food 4.6, service 3.2” names two different fixes; “3.9” names none.
Pricing
Free while we onboard our first restaurants.
We are early, and we would rather have a handful of restaurants using this properly than a price list. You get it set up and running at no cost. In exchange you tell us what is wrong with it, honestly, while we are still small enough to fix it quickly.
No contract, no card, and no lock-in. Your menu and your order history are yours; if you stop using it, you take the QR cards off the tables and that is the whole exit.
Book a demoWhat the pilot includes
- Your menu, entered and checked with you
- A printed QR card for every table
- The kitchen board, on any screen you already own
- UPI payments to the account you already use
- Owner and staff logins
What you do not need to buy
- A terminal
- A card scanner
- A POS to integrate with
- A setup fee
You need a menu, a printer for the table cards, and a phone or tablet at the counter for the kitchen board. Everything else is already in your diners’ pockets.
Questions
The things owners ask first.
Do diners need to install anything, or make an account?
No, and no. The QR opens a normal web page in whatever browser is already on their phone. There is no app, no sign-up, no OTP and no password anywhere in the diner flow — scanning the code is the sign-in, and the session lasts the sitting.
What do we need to buy?
Nothing beyond a printer and something to mount the codes on. tableX is a website on both sides: the diner uses their own phone, and you run the floor from a phone, a tablet or the laptop at your counter. No terminal, no scanner, no POS box.
Our restaurant wifi is unreliable. Does it break?
It degrades rather than breaks. The whole menu arrives in one request, so browsing is not chatty, and the board falls back to polling every few seconds on its own. Nothing important is delivered only over the live channel, so a dropped frame cannot leave the diner and the kitchen disagreeing.
Can a diner change or cancel an order?
Cancel, yes — while the kitchen has not accepted it. After that the control is replaced with “ask staff”, because the food may already be on. Editing a placed order is deliberately not supported: a second order is instant, and your staff can strike a single line off a ticket with the total re-priced.
Can someone order onto our table without being here?
The code is a random 32-character token, not “table 7” — there is nothing to guess and nothing that reveals how many tables you have. If a sticker gets photographed and posted somewhere, you regenerate that one table’s code and reprint one card, not the floor.
What if a table’s QR sticker gets peeled off?
A restaurant-level code taped to the counter still works — the diner picks their table from a list. It is the recovery path that keeps you taking orders on a bad night.
What happens if nobody accepts an order?
It stays on the board as New and keeps announcing itself. The diner’s screen tells them it is taking longer than usual after a few minutes, and after twenty that the fastest thing is to speak to someone. Your dashboard reports the day’s average time to accept, so a slow shift is visible rather than anecdotal.
Do I need a payment gateway?
No. Start with the UPI ID you already use. Add a gateway when you want automatic reconciliation; the diner’s flow does not change.
Book a demo. We set it up with you.
Tell us where you are and we will walk your floor through it — the menu, the table cards and the kitchen board — then hand it over running.
Free while we onboard our first restaurants. No card, no contract.