Dine-In to Digital Playbook

This playbook is for the owner of a restaurant or cafe with tables, anywhere from six to sixty of them, who still takes most orders on a notepad and most payments at a counter. You may have been told to "go digital", or you may already have a QR code on each table that opens a PDF nobody scans twice. By the end you will have a working QR code ordering system: a code on every table that carries the table number, an order status flow that ends in served, a KOT that prints in the kitchen without anyone re-typing it, staff roles with alerts nobody can miss, a pickup channel running from the same kitchen, and a menu that changes by daypart on its own. Each chapter ends with a checklist, and the last chapter lays the whole thing out as a 90-day plan. The belief it will change: most owners think going digital means a contactless menu or a new POS. The change that matters is smaller and deeper. The order enters your system once, typed by the guest, and nobody re-writes it by hand after that. Every saving in this playbook comes from that one change.

Chapter 1: What a QR code ordering system changes, and what it costs

A QR menu and a QR ordering system are different products

Most restaurants that "went contactless" in the last few years put a code on the table that opens a menu. The guest reads it, then waits for a server, explains the order, the server writes it down, walks to the kitchen or keys it into a billing machine, and the kitchen reads the handwriting. The code replaced the laminated menu and nothing else. Four handoffs remain, and each one is where a wrong order, a forgotten second round or a ten-minute wait comes from.

A QR code ordering system replaces the order-taking. The guest taps items, enters a table number, confirms, and the order is in the kitchen with the table number on it before the server has noticed the guest looked up. The difference between the two is the difference between a menu and an ordering channel, and the step-by-step of how table ordering works walks through the scan-to-served loop in detail. This playbook assumes you want the second thing.

The one-entry rule

Write this on the kitchen wall: an order is typed once, by the guest, and never re-written. Not on a notepad, not into a billing machine, not shouted across the pass. The KOT is printed from what the guest typed. The bill is generated from the same record. The sales report at midnight is the sum of the same records. When you hold to this rule, three things stop happening. Orders stop going wrong between the table and the kitchen. Second rounds of drinks and desserts stop being missed because no server was nearby. And the day's sales stop depending on whether the cashier remembered every table.

The rule also tells you what to keep on paper. A guest who prefers to order from a person can still do so; the server types it into the dashboard or staff app on their behalf, once. The guest's preference is respected and the rule is intact.

What it costs a 12-table restaurant

Illustrative figures for a 12-table restaurant in a tier-2 city, using ranges commonly quoted at the time of writing. Get local quotes for hardware.

For most small restaurants the one-time spend lands between ₹10,000 and ₹25,000 and the monthly cost between ₹2,000 and ₹6,000 including per-order fees at a few hundred dine-in orders a month. Compare that with the cost of a single wrong order a day: a ₹320 dish re-made is around ₹120 of food cost and a table that waits twenty minutes longer. The fee model matters more than the subscription. A flat rupee charge per order stays flat as you grow; a percentage of the bill grows with you. Whether you need a full POS underneath any of this is a separate question, answered in table ordering system: POS or just WhatsApp.

Readiness checklist

• Your menu is written down with every item, variant (half and full, size), add-on and price, and it is current.
• You know which items are not available every day, and when.
• Tables are numbered, physically, in a way a guest can read from their seat.
• There is a phone signal or guest Wi-Fi at every table. A basement with no signal needs Wi-Fi and the password on the card.
• One person will own the dashboard and one person will own the kitchen phone during every service.
• You have decided whether guests pay when ordering, at the end, or at the counter. Chapter 3 covers this.

Chapter 2: Tables, QR codes and table numbers

Decide how table numbers work

The table number is the piece of information that turns a web order into a dine-in order. The guest reads it from the card on the table and enters it when ordering, so the card and the number have to be impossible to confuse. Then settle one policy: is a table number required or optional?

For a restaurant with numbered tables and more than a handful of them, make it required. An order with no table number is a plate at the pass with nowhere to go. For a four-table cafe where the counter can see every seat, optional is fine, and the counter asks "which table?" when it matters. On Tezzu this is a store setting: enable dine-in, choose whether the table number is required, and the QR menu asks for it accordingly.

Dine-in prices

Dine-in has no packaging and no rider, so many restaurants price it a little below delivery, or keep the same price and simply skip delivery charges. Decide before you print anything, because the code opens the menu at dine-in prices. Each item can carry a dine-in price alongside its regular price; leave it blank and the regular price applies. Variants can have their own dine-in prices too. If your delivery menu is already live, this is a one-hour job of going through the list with the food cost sheet open.

Printing and placing the codes

Generate the QR code for your store from the dashboard. Print one card per table with the table number written large beside the code, and print three spares. Then place them where a seated guest's eyes land: standing upright at the wall side of the table, or on a small acrylic stand, never flat under a plate.

• Laminate or use acrylic stands. Paper cards survive about two weeks of wiping.
• One card per table, never one per two tables. Guests on a shared card order against the wrong number.
• Keep the printed menu on hand for the guest who asks for one; the code is an option, never a rule.
• Test every card by scanning it with two different phones before the first service. A code printed too small fails on older cameras.
• Put one large code at the entrance for walk-ins who want to order before sitting, and one at the counter for pickup customers.

What the card should say

A bare code gets ignored. The card needs one sentence that tells the guest what will happen: "Scan to see the menu and order. Pay online or at the counter. Your food will come to this table." Add the table number in large type and, if you have guest Wi-Fi, the network name and password. Guests who have never ordered this way need to be told that nobody will come to take the order unless they want them to. Keep the sentence short enough to read in three seconds; a paragraph on a table card is a paragraph nobody reads.

Run a three-table pilot

Put codes on three tables for one service, with the rest of the room on paper. Tell those three tables what to do, watch what confuses them, and watch what confuses your staff. The usual findings: the card's instruction is too long, nobody noticed the first order for four minutes, and the kitchen did not know a QR ticket from a phone order. Fix those three before you print the other nine cards. A pilot costs one evening and saves a bad first week.

Chapter 3: The order status flow from pending to served

Five stages, one owner each

Every order passes through the same five stages. What differs between dine-in, pickup and delivery is the final stage and who closes it. A status is a promise with a timestamp: "preparing" at 7:42 tells the kitchen the clock is running, tells the counter the order was accepted, and tells the guest their food exists. The full three-way comparison is in the order status workflow from pending to served; the dine-in path looks like this.

Pending is the dangerous stage. An order sitting unseen for eight minutes on a Friday evening is how a guest flags a server and orders again on paper, and now you have the same biryani twice. Chapter 5 is about making sure pending never sits unseen.

Why served exists

A delivery order ends at delivered. A pickup order ends at collected. A dine-in order has to end somewhere too, and "ready" is the wrong place, because a plate at the pass is still an open order. On a full night the dish for table 9 sits at the pass while two servers each assume the other took it. The served status, tapped by the server who carried the plate, closes that gap.

It also makes your numbers honest. Revenue, the earnings view and customer history count a served order as complete, the same way a delivered order is complete. Without it, dine-in orders would sit at ready forever and the day's sales would be wrong. The gap between ready and served, per table, is the single best measure of floor staffing you will ever have; a restaurant that sees it climb past five minutes on Saturdays knows it needs one more runner on Saturdays, and nothing else. The family-restaurant version of this, with separate servers and runners, is in dine-in served status and table numbers for family restaurants.

Payment runs beside the status

Payment is a separate track from the kitchen status, and you choose where it happens.

• Pay when ordering. The guest pays by UPI or card on their phone before the order reaches the kitchen, and the order arrives marked paid. Best for cafes, food courts and counters where tabs are not expected.
• Pay at the end. Orders accumulate against the table and the guest pays the total from the same page, or at the counter, when leaving. Best for family restaurants where several rounds are normal.
• Cash or card at the counter. The ordering is digital and the payment is not. The order arrives marked unpaid, exactly as a cash on delivery order does, and the cashier marks it paid when the table settles.

Whichever you pick, the bill is a GST invoice generated from the order, never a handwritten total. Make "unpaid" loud on the counter screen so nobody lets a table leave without settling. A mixed policy works well: pay-at-counter by default, with the online option visible for guests who prefer it, which quietly moves a share of your payments to UPI with no change at the counter.

Rejected and cancelled are different exits

Rejected means you declined the order before accepting it, usually because an item ran out; refund it if it was paid. Cancelled means it was accepted and then stopped, by you or the guest. Keep them separate on purpose. A high rejection rate is a menu availability problem, solved in Chapter 7. A high cancellation rate is a speed or communication problem, solved in Chapters 4 and 5.

Status checklist

• Every transition has one named role that owns it, and that role is physically present when it happens.
• Dine-in orders cannot be marked out for delivery, and delivery orders cannot be marked served.
• Served is tapped by the person who carried the plate, within three minutes of ready.
• Pay-now, pay-later and pay-at-counter are decided, and the counter screen shows paid or unpaid clearly.
• Rejected and cancelled are counted separately in your weekly review.

Chapter 4: KOT printing and the kitchen flow

What a KOT must show

A kitchen order ticket is the kitchen's only view of the order, so it has to carry everything and nothing extra. Table number at the top in the largest type on the ticket. Order type, so a dine-in ticket and a pickup ticket cannot be confused. Time of order. Each item on its own line with its variant, and every add-on as a separate line, including the ₹0 ones such as "less spicy" or "no onion", because those are the lines the guest remembers. Quantity before the item name. A guest note, if any, at the bottom. The ticket does not need prices; the kitchen does not cook prices. For a kitchen that has never run on tickets, the complete KOT system guide covers how to organise the pass around them.

Where the printer goes

Connect a thermal printer to the device that runs the dashboard in the kitchen, and the KOT prints for each new order the moment it is accepted. Two decisions here. First, paper width: 58mm is cheaper and fine for KOTs with a handful of lines; 80mm is easier to read for bills with many lines and for tickets from large tables. The trade-offs are in 58mm vs 80mm thermal printers. Second, one printer or two: if the kitchen and counter are in the same room, one printer does KOTs and bills; if they are far apart, put a KOT printer in the kitchen and a bill printer at the counter.

Mount the printer at the pass, at eye level, with the paper coming out toward the cook. A printer on a shelf behind the fridge produces tickets nobody reads.

The pass: tickets in, plates out

The pass needs a ticket rail or clips, a rule for order, and a rule for completion. Tickets go on the rail in the order they printed, left to right. The cook works left to right, starting the longest item on each ticket first. When every item on a ticket is plated, the ticket moves to a "ready" clip and the order is marked ready on the phone or dashboard. When a server takes the plates, the ticket comes off the rail and goes on a spike, and the server marks served from the staff app. The rail is the kitchen's queue, the spike is the kitchen's history, and the phone is what tells the rest of the building what the kitchen is doing.

During service, the kitchen touches the phone once per order: ready. Accept happens at the counter, served happens on the floor. One tap is a habit a cook will keep; five taps is one they will drop by the second hour.

A Saturday evening, worked through

Illustrative example, built from typical numbers rather than a named restaurant. A 20-table restaurant does 80 covers between 7 and 10 pm on a Saturday, roughly 45 orders including second rounds, with an average ticket of ₹620, so about ₹28,000 for the evening. Before QR ordering, two servers each spent perhaps 90 seconds per order taking it, walking it and explaining it, which is around 70 minutes of server time across the evening, plus two or three wrong orders a night at ₹120 to ₹150 of food cost each.

After the switch, those 70 minutes go to running food and clearing tables, which is what lets the same two servers handle 20 tables without a third. Wrong orders drop to the ones the guest typed wrongly, which the ready message catches before the plate leaves the pass. Second rounds rise, because dessert is three taps away rather than a hand in the air; even four extra ₹180 desserts an evening is ₹720, or around ₹2,900 a month from Saturdays alone. The per-order fee on 45 orders at ₹10 is ₹450 for the evening. None of these numbers is a promise; they show where the money sits so you can measure your own.

Kitchen checklist

• Printer at the pass, at eye level, test ticket printed before every service.
• Two spare paper rolls within arm's reach.
• Ticket rail or clips, left to right, with a separate ready clip.
• The kitchen phone's only job during service is the ready tap.
• Every add-on prints as its own line, including ₹0 add-ons.
• If the printer fails, the dashboard screen is the fallback and someone is assigned to call out tickets from it.

Chapter 5: Staff roles and alerts

Five roles for a restaurant with tables

Every person gets their own login with a role, and the role decides what they see and what they can tap. Shared logins mean you can never tell who cancelled table 7's order at 9 pm, and you cannot remove one person's access when they leave. The split that works for most small restaurants:

The principle: each person sees what they need for their next action. A runner does not need revenue; the kitchen does not need addresses. The single-outlet reasoning behind each row is in restaurant staff management: roles, permissions and who sees what.

The alert chain

A QR order fails silently if nobody notices it. The guest orders, nothing happens, and four minutes later they flag a server anyway, which is worse than paper. The fix is an alert that cannot be missed and that stops the moment someone acts. On the Tezzu staff app, a new order rings and, with a new-order alert switched on for your store, a recorded voice says a new order has arrived, in Hindi or English, at alarm volume, repeating until any staff member on any phone accepts it. When the counter accepts, the kitchen phone goes quiet too, so one order never has three people shouting about it. Orders from a table code, WhatsApp, the store page or a campaign link all trigger the same alert; the kitchen does not care where an order came from.

Assign the pending step to the kitchen role or to named people in your order flow settings. If pending is assigned to nobody, nobody is alerted, and that single setting is the most common reason a kitchen reports that "the app never rings". The setup and the silent-phone fixes are in the Tezzu staff app guide.

The phone that never goes silent

• One cheap phone in the kitchen, plugged in, dedicated to the staff app, logged in as the kitchen role.
• Alarm volume at maximum; the announcement plays on the alarm channel, so ringer and media volume do not matter.
• Do not disturb off, or alarms allowed through it.
• Battery optimisation switched off for the staff app and auto-start allowed; the setting names vary by phone brand.
• App updated to the current build; older builds ring once and stop.
• A test order from your own phone before every service: listen for the alert, accept at the counter, confirm the kitchen phone goes quiet.

Training in one service

Staff training for QR ordering takes one service if you give each role exactly one job. Tell the counter: accept within two minutes and mark paid when the table settles. Tell the kitchen: ready when it is plated. Tell the floor: served when it is on the table. Tell the manager: watch the pending list and the ready-to-served gap. Run the three-table pilot from Chapter 2 with this split, then go to all tables the next service. Do not hand out a manual; hand out one sentence each.

Chapter 6: Pickup and pre-orders from the same kitchen

Why pickup is the cheapest order you fulfil

Once the kitchen runs on tickets and statuses, adding takeaway is a setting rather than a project, and it is worth adding early because a pickup order carries almost no cost beyond the food. Illustrative comparison on a ₹400 order:

A pickup order uses no seat, which matters most on the nights your tables are full. The guide to adding takeaway pre-orders to a restaurant goes deeper on the economics; the operational part follows.

Pickup points and collection slots

A pickup point is a named place with an address, hours and one sentence of instructions written for someone who has never visited: "Collect from the side window on the service lane, not the main door." Most restaurants have one; a restaurant that also runs a Sunday stall has two. Then set collection slots that match the kitchen. Thirty-minute windows for orders placed earlier in the day, and "ready in 25 to 30 minutes" for immediate orders at lunch, are honest for most small kitchens. Set the earliest slot to real prep time plus a buffer, and widen the windows at peak rather than promising slots you will miss. On Tezzu, self-pickup points carry the address, hours, instructions and collection slots, and the customer picks a slot at checkout; setup is in self-pickup points in Tezzu.

Pre-orders and the lunch rush

A pre-order is a pickup order with a date and time on it, and it is the only way to make a lunch rush predictable. Offices near you will order at 10:30 for a 1:15 collection if you let them, and three thalis due at 1:15 go into the kitchen at 12:50 with a ticket that says so. Take payment at the time of ordering for pre-orders above a threshold you are comfortable with, say ₹300; a prepaid order removes the no-show risk entirely and speeds up the counter, because the customer says a name or an order number and leaves with the bag. Allow pay-at-counter for small orders from regulars if you want, and make the unpaid status loud on the counter screen.

The counter in a rush

• A ready shelf with order numbers or names, sorted by collection time.
• One tap per order when the bag goes on the shelf: ready. That tap sends the customer the message and ends the "is mine ready" question.
• A separate pickup queue with a small sign, so dine-in guests and pickup customers are not in the same line.
• Four messages that run themselves: confirmed with the slot and the instructions, ready with the order number, a reminder if uncollected after fifteen minutes, and a thank-you with a link to order again.

Chapter 7: Menu scheduling by daypart

Map the dayparts first

A restaurant with tables almost always has a menu that changes through the day, even if the printed one does not admit it. Breakfast ends when the batter runs out, the lunch thali is cooked in one batch, the fryer runs only in the evening, and the late-night menu is whatever one cook can manage. A QR code ordering system that shows the whole menu at every hour produces orders you have to refuse, which is the thing you are trying to stop. Ten minutes with a pen before you touch any setting:

Only schedule where there is a reason. Every window is one more thing to remember when your hours change, and a category that sells all day needs no window at all.

Category windows, item windows and snooze

Set the schedule on a category and every item inside inherits it. Set it on a single item only when that dish needs its own hours, and keep item-level windows to two or three, because thirty of them is a maintenance problem. An item window narrows its category window and cannot widen it. Snooze is the third tool, and it is for the unplanned case: the dal makhani sold out at 8:30 and the next batch is tomorrow. Snooze hides it immediately regardless of the schedule and brings it back when the snooze ends. Schedule answers "never on Tuesdays"; snooze answers "sold out tonight". Mixing them up is how owners end up with a dish that never comes back. The setting-by-setting walkthrough is in menu scheduling in Tezzu.

The same windows apply everywhere a guest can order: the table code, the store page, the web menu and the WhatsApp bot. There is nothing to sync, and a guest at 11:05 sees the lunch menu without anyone touching a screen.

Dayparts and staffing

Dayparts are also a staffing tool. The afternoon window that shows only snacks is what lets you run 3:30 to 6:30 with one cook and no server, taking QR orders from the six tables that are occupied. The late-night short menu is what lets one cook keep up after 11 without wrong orders. When you set a window, ask who is in the kitchen during it, and cut the menu to what that person can make well.

Daypart checklist

• The daypart table above exists for your restaurant, on paper, agreed with the kitchen.
• Windows are set on categories; item windows are three or fewer.
• Someone on the kitchen role knows how to snooze an item from the staff app and has done it once.
• Pickup slots and pre-order windows sit inside the daypart that cooks them: lunch pre-orders only in lunch hours.
• Store open and close hours still govern whether any order is accepted; dayparts work inside them.

Your 90-day plan

The numbers to check every Monday

Five numbers tell you whether the system is working, and all five come from the order records the guests typed.

• Pending-to-accepted time, average and worst. Target under two minutes; a worst case over ten means the alert chain is broken.
• Ready-to-served time per table on Friday and Saturday. Climbing past five minutes means the floor is short a runner.
• Share of dine-in orders placed through the code versus typed by staff. Expect it to rise week on week; if it stalls below half, the card copy or the signal is the problem.
• Second-round orders per occupied table. Desserts and drinks ordered after the main order are the clearest sign the code is being used.
• Rejected orders. Each one is a menu availability gap; fix it with a window or a snooze.

The plan

Everything in this plan is standard Tezzu setup: QR tables with table numbers, dine-in prices, the served status, KOT and GST bill printing, staff roles, the staff app with new-order alerts, self-pickup points with collection times, scheduled orders and pre-orders, menu scheduling by weekday and time, and order reviews and ratings. Plans start at ₹999 a month with a flat ₹10 per order, no commission and a 7-day free trial. The dashboard-level walkthrough of the dine-in pieces is in dine-in with Tezzu, and the end-to-end setup order is in the Tezzu setup playbook.

Frequently asked questions

How does a QR code ordering system work in a restaurant?

Each table has a code that opens the menu in the guest's phone browser, and the guest enters the table number from the card. They add items, confirm, and pay now or at the end. The order lands on the restaurant's dashboard and staff app, prints as a KOT in the kitchen, moves through preparing and ready, and is marked served when it reaches the table. Second rounds go through the same code. No app is installed on either side.

Do customers need an app to order from a QR code?

No. A properly built system opens in the phone camera's browser with nothing to install or sign up for. At most the guest enters a phone number so they can receive order updates on WhatsApp. Any system that demands a download loses a large share of guests at the table, which is why the store page and the WhatsApp bot both matter.

What is the difference between ready and served?

Ready means the dish is plated at the pass. Served means a server has put it on the correct table. On a busy floor the gap between the two is where dishes go cold and tables wait, so tracking served separately tells you whether the kitchen or the floor is the bottleneck on a given night, and it closes the order so your sales figures are right.

Can I run dine-in, pickup and delivery from one menu?

Yes. The guest or customer picks the order type at the start, the same menu applies with dine-in prices for tables and delivery charges only on delivery, and each order carries its type to the dashboard and the KOT. The status path differs by type: served for dine-in, collected for pickup, delivered for delivery, so staff cannot tap the wrong final stage.

How much does a QR code ordering system cost in India?

For a small restaurant, table stands or laminated cards cost a few hundred to a few thousand rupees, a thermal printer ₹3,000 to ₹8,000, and the platform subscription is typically in the low thousands a month plus either a flat per-order fee or a percentage, depending on the provider. On Tezzu it is ₹999, ₹1,999 or ₹3,999 a month plus ₹10 per order, with no commission. Payment gateway charges apply to online payments only.