A restaurant that opened with its accounting already working: implementing iiko for Eden Taste in Osh

The problem: the restaurant is opening and the accounting does not exist yet

This case study differs from most automation stories. Usually a system goes in once the record-keeping has already broken: discrepancies have piled up, food cost has drifted, and the owner has stopped understanding where the money goes. Here the situation was different — the restaurant was only just opening.

Eden Taste is a premium venue serving European and national cuisine in Osh, with a large menu and its own in-house prep. The team was hired, the space was ready, the chef had developed the menu. Only one thing did not exist: a system to connect a dish sold with the produce in the store room, and to show what the restaurant actually earns on that dish.

• Food cost was unknown. Menu prices were set from the market and a sense of margin, but the real cost of produce on the plate was never calculated. The restaurant did not know which items made money and which ran at a loss.
• Recipe cards did not exist. Recipes lived in the chef's head and in a cook's notes. The same salad could be assembled slightly differently each time, and there was no consumption standard at all.
• Stocktaking was never done. Checking whether physical stock matched the calculated figure was impossible — there was no calculated figure.
• Shortages surfaced in the middle of service. The classic scene: a guest orders a dish, the waiter goes to the kitchen and comes back apologising. Purchasing ran on instinct and memory.
• Write-offs were not counted. Spoilage, waste, staff meals, comps — all of it vanished into the unknown and never reached the venue's economics.

It is important to understand this is not negligence. Most venues open exactly this way. While the launch is under way — the fit-out, hiring, buying equipment, developing the menu — accounting looks like something you can sort out later. The problem is that later means several months of the restaurant flying blind, after which the system has to be implemented on top of habits that have already set, which is always more expensive and more painful.

The deciding factor was fiscal reporting requirements in Kyrgyzstan. Restaurant sales have to be reflected correctly in fiscal documents, and for that the till, the menu and the accounting have to be one connected system rather than three separate things.

The second motive was the owner's demand for transparency. A premium restaurant with a large menu and a floor team is a business you cannot control by eye. The owner wanted a picture of sales available not by questioning the manager but in an app on a phone.

Where we started: the system first, the data second

We did not try to launch everything at once. The implementation ran in two beats, and that was deliberate.

Beat one — a working till. At the start there was a single job: the restaurant has to open and sell. We installed and configured the system, connected the till hardware and made sure receipts were fiscalised correctly. The venue could trade legally and take guests.

Beat two — the accounting layer. With the restaurant already running, we worked with the chef and the manager to enter recipe cards and configure stores, deliveries, write-off on sale and stocktaking. That part needs people on the client's side, and stretching it across several weeks turned out to be better than trying to close it before opening.

That sequence removes the main launch risk: the restaurant does not wait for perfect accounting, and the accounting does not get deferred to someday. The whole project took four to five weeks.

The solution: what exactly was configured

What we deliberately left out of scope

We implemented exactly what a restaurant needs at launch. The system can do noticeably more, and those capabilities are worth knowing about — they connect later, once the basic accounting is working and data has accumulated in it.

• Sales forecasting. From accumulated statistics the system can predict demand and help plan purchasing and shift staffing. It needs sales history over a meaningful period, so at the opening stage it is inapplicable in principle.
• A QR menu for guests. The guest opens the menu on their phone from a code on the table. Items and prices come from the same system as the till, so the menu never drifts from reality.
• Stocktaking from a smartphone. Counting is done in the room or the store from a phone, with no paper sheets and no re-keying afterwards.
• Loyalty programmes and guest management. Accumulated discounts, bonuses, visit history.

We deliberately did not connect these on this project. A restaurant that has just opened first has to learn to work with recipe cards, stores and the till. Functionality added before the staff have mastered the basics usually goes unused.

The main technical knot: sales through Yandex Eats

The most interesting part of the project was neither the recipe cards nor the till, but accounting correctly for orders arriving through the delivery service.

The pitfalls we worked through

Honest about the limits

We set out the limits before a project starts rather than after. Here is what matters for any restaurant planning automation.

• The system is useless without current data. This is the main limitation and it is organisational, not technical. If deliveries are not filed on time and write-offs are not made, the reports will be beautiful and wrong.
• You need somebody accountable. On this project the manager and the head chef run the accounting. Somebody has to keep an eye on deliveries, write-offs and stocktaking continuously rather than by mood. Automating a restaurant without such a person is pointless.
• Entering delivery orders by hand takes attention. Without a direct Yandex Eats integration a staff member transfers the order manually. A separate menu protects against pricing errors but does not remove the action itself.
• The mobile app depends on network quality. Stable Wi-Fi across the whole room is a condition of operation, not a nice-to-have.
• Recipe cards need maintaining. Menus change, seasonal items come and go, suppliers change pack sizes. If the recipes in the system are not updated, the food cost calculation gradually drifts from reality.
• Automation does not replace management decisions. The system will show that a dish is unprofitable. Raising the price, changing the recipe or removing the item is a decision a person makes.

Results

What this means for the restaurant:

• The venue knows its economics from day one. Not after six months of trading blind, but immediately — which items earn and which need rethinking.
• Purchasing stopped being guesswork. Stock is visible and a shortage is predicted before a guest hears "we don't have that today".
• Delivery became a measurable channel rather than a source of discrepancies in the reports.
• The owner sees the restaurant from a phone. Control stopped depending on being in the room and on staff being ready to report.
• Staff work faster. The order reaches the kitchen without the delay of carrying and retelling it.

Who this implementation fits

iWeb sets up accounting and automation for venues where:

• A restaurant is opening and the accounting needs putting in now rather than being redone in six months.
• Food cost is unknown and prices are set against market reference points rather than calculation.
• There is in-house production — prep, sauces, baking, semi-finished items that go into other dishes.
• Sales run through several channels — dine-in, delivery, takeaway, functions — at different prices.
• Stocktaking is not done, or is done manually and always with discrepancies.
• The owner cannot see the metrics and learns how things stand from what staff say.
• Correct fiscal reporting is required, with the till linked to the accounting system.
• Staff spend time on paper orders and walks to a fixed terminal.

Formats where the scheme works: full-service restaurants, coffee shops, bars, pizzerias, bakeries with in-house production, delivery operations, canteens and hotel venues, and multi-site groups.

Why iWeb

iWeb is a web studio and business automation team from Osh, Kyrgyzstan.

• We work from the process, not from checkboxes in the settings. The separate delivery menu did not come out of documentation — it came from asking what happens to the reporting when the first marked-up order arrives.
• We do not spend the client's budget where it need not be spent. Running the waiter app on personal phones instead of buying tablets is a small detail, but the cost of a launch is made of exactly such details.
• We take it to a working result, not to a delivered configuration. Recipe cards, stores, stocktaking and training are several weeks of joint work with the kitchen and the manager, and we walk that road with the client.
• We flag the difficulties in advance. Network requirements, the need for somebody accountable for the accounting, the volume of work on recipe cards — we say it before the start, not after launch.
• We work locally. We are based in Osh and understand fiscal reporting requirements in Kyrgyzstan and how venues here actually operate.
• We work in three languages — Kyrgyz, Russian and English.