Restaurant Automation: Where to Start and What to Leave Alone

01Automation starts with the order path, not the till

When an owner says "let's automate", they usually mean a till program. The till goes in, the cashier is trained, a receipt prints, and that is the end of it. The guest still raises a hand, the waiter still writes in a notebook, the kitchen still runs on shouting.

The order path has five links: the guest sees the menu, chooses, orders, the kitchen cooks, the guest pays. The till only closes the last link. If the other four stay on paper, nothing gets faster.

So the order should be reversed: the guest side first (menu and ordering), then the kitchen, and reporting last. The guest side is the cheapest part and the fastest to pay back: a 12-table cafe on Start at 600 000 UZS a month, live in a day.

02Four channels, one menu: hall, QR, own site, aggregator

An order reaches a restaurant through four doors today. In the hall: a waiter or a tablet on the table. On the table: a QR and the guest's own phone. Outside: your own delivery site. And the aggregators: Yandex Eats, Uzum Tezkor.

The problem is not the channels, it is the duplicated menu. A price goes up: you change it on the till, on the site, in the aggregator. One of the three gets forgotten and a guest sees the old price. The plov runs out and it has to be removed in three places.

In a properly built system the menu lives in one place and flows out to every channel. On top of that, each dish gets per-channel visibility: the business lunch only in the hall, the large sets only for delivery. You never keep one dish in two price lists.

• Hall: a laTable tablet or a laQR table QR, both unlimited in the package
• Own site: laGuest on your own domain, included from Start
• Aggregator: Yandex Eats and Uzum Tezkor, with menu, availability and status both ways
• Telegram: unlimited catalog bots; an AI agent takes orders from the Standart package up

03If you already run iiko or r_keeper: don't replace, build on top

Replacing a working POS is the most expensive decision you can make. Accounting, stock, tech cards, staff habits: all of it hangs off that system. A replacement stops the business for a week and leaves two months of confusion.

The right path is to add a guest layer on top. laCafe is fully two-way with iiko: the plugin lives inside iikoFront, an order from a QR or a tablet opens in iiko exactly as if a waiter had entered it, and the receipt and kitchen ticket print on the same printers. Catalogs, prices and the stop-list come from iiko.

r_keeper is live too: over the RK7 XML API the stop-list syncs in 30 seconds and orders in 10. Modifiers are not there yet; they are planned. If you have no POS at all, a laBoard tablet becomes the till, included in the package at no extra cost.

04The numbers: what a 12-table cafe pays per month

laCafe sells monthly packages priced by branches and orders: Start 600 000 UZS (1 branch, 500 orders), Light 1 200 000 (3 branches, 1 200), Standart 2 400 000 (5 branches, 3 000). Tablets, QR codes, kiosks and waiter phones are unlimited in every package. Go over the limit and nothing stops; extra orders are billed separately.

A 12-table cafe with ~450 orders a month: Start, 600 000 UZS. That price covers QR only or a full hall set alike: 12 laTable tablets, a laBoard till, 2 laWaiter phones. If orders climb to 700: 600 000 + 200 × 1 200 = 840 000 UZS, still cheaper than Light (1 200 000).

Compare that with one waiter's salary. Then ask the second question: how many "waiting for the waiter" minutes the QR removes per day, and how many extra desserts get sold in place of those minutes. The average check rises 6–12%, for a simple reason: the photo, the description and the modifiers are always in view.

05A 30-day rollout plan

Turning everything on in one day is the classic mistake. Staff can't absorb it, guests get confused, and the owner concludes "it didn't work". A staged order is far safer.

• Days 1–3: laBox goes on the till PC and installs the iiko plugin itself, the menu arrives from the POS
• Days 4–7: photos, descriptions and three languages go onto the dishes — the slowest part, which you can speed up by dropping a menu photo into the AI
• Days 8–10: a QR goes on 2–3 tables only, tested there, with the waiters watching
• Days 11–20: QR on every table, laWaiter on the waiters' phones, Telegram notifications routed per hall
• Days 21–30: your own delivery site and the aggregators; the first reports: the hourly heat map and menu engineering

06Three typical mistakes

First mistake: a menu with no photos. A QR menu without pictures is just a worse copy of the paper one. The guest can't choose, calls the waiter, and it looks like the system failed. At least the top 20 dishes need proper photos.

Second: not winning over the waiters. If a waiter sees the QR as a rival, they will tell the guest "it doesn't work, just tell me". The truth is the opposite: the QR frees them from writing orders so they can do service and upselling. Call and bill statistics show who is actually doing it well.

Third: never opening the reports. In the first month the hourly heat map redraws your shifts and menu engineering tells you to drop 5–7 dishes. The data is there, but if nobody looks at it, automation stays a pure cost.