Restaurant portal: what breaks as load grows
A restaurant portal lives in two states at once: the guest places an order in the browser, while the kitchen and POS see it only after the data reaches the accounting system.
That is exactly where the break happens: the order is accepted on the website, payment goes through, but the items never appear in the accounting system.
Until the end of the shift, no one knows whether to cook the dish, and the guest waits for a confirmation that will never come.
Peak load on the website exposes this first. Evening traffic, a promotion, a holiday evening — the number of simultaneous checkouts grows several times over, some requests to the accounting system fail to process in time and break off.
The portal retries the send, and duplicates appear in the accounting system, while the website shows order discrepancies: one total, another composition, a third status.
Then manual order reconciliation kicks in. During the busiest hour, a manager compares the list on the website with the list in the accounting system line by line, fishing out lost and duplicated items — instead of working with the dining floor.
Stuck reservations live their own life at the same time: the guest received a confirmation, but the table is not assigned to them, and they arrive in the dining area to find their place already taken.
The cost of failures at checkout is not just a lost check. It is refunds, damaged reviews, dealing with guest correspondence, and lost trust of regular guests who go where the order goes through the first time.
We break down how this is solved: exactly where data exchange with the accounting system breaks and what makes the portal resilient at peak.
What implementation delivers: an effect visible in metrics
Integration with a restaurant's accounting system is not "another button on the website" but a replacement for manual work by the operator and dispatcher.
Below are four points where the effect is measured by metrics: the share of automatically reconciled orders, menu change publication time, recovery time after a failure, and an eliminated class of errors.
Orders reconcile without an operator
Online orders and delivery go from the guest's account directly into iiko and R_Keeper: the order is created in the system with the same composition, modifiers, and address that the guest selected.
The share of automatically reconciled orders is 97–99%, and the rest goes into a separate exceptions list for manual review.
The menu updates in minutes
The stop-list and prices change in the accounting system and propagate to the website, app, and account within a minute. Menu update speed no longer depends on which administrator is on shift, and the guest does not order what the kitchen does not have.
A failure does not stop order intake
Orders are written to a local queue, so if the accounting system is unavailable, intake and payment continue. After recovery, the queue is loaded into the accounting environment: recovery time is minutes, with no lost orders.
Points and tables in one environment
The loyalty program awards points when the check is closed, and table reservations are immediately visible in the floor plan. Phone confirmations and double bookings disappear as a class of errors, and the share of repeat visits grows.
Restaurant portal formats: a ready-made solution or custom assembly
The choice of approach rests not on technology but on how non-standard the restaurant's processes are. As long as the menu, stop-lists, and reservations are described by a standard set of fields, a ready-made portal covers the task.
As soon as there is a network of locations with different menus, banquet deposits, combos, and custom loyalty rules, standard screens are not enough — and the exchange with iiko and R_Keeper has to be extended manually.
Below are four options that businesses actually choose between at the start. The difference between them shows up not in a demo but in the third month of operation: when the accounting system is updated, the menu changes, and new locations are connected.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made industry solution | Menu, delivery, and reservations are standard, and launch is needed quickly | Screen logic is defined by the vendor; non-standard scenarios and exchange with the accounting system are possible only within standard fields |
| In-house development | The portal is part of the business model: a network of locations, deposits, custom loyalty rules | Longer to launch; you handle support and enhancements for accounting system changes yourself |
| Enhancement of the current website | There is a working website with traffic, and orders and reservations are needed | The old framework limits it; core updates break enhancements, and part of the logic still has to be rewritten |
| Hybrid: standard framework and custom modules | Orders and reservations are needed quickly, but integration and loyalty are unique | The core depends on the platform vendor; a clear boundary between custom and standard code is important |
How we carry out implementation: stages of engineering work
We assemble a restaurant portal in a single order: first we capture how an order actually travels from guest to kitchen, then we build the exchange, and only after that do we turn on live traffic. Below are the steps we go through on every implementation.
-
Process discovery. We analyze order intake in the dining area, on delivery, and in aggregators, and verify reference data: stop-lists, modifiers, recipe cards, and floor assignments. The output is a process map with discrepancies between the accounting system and shift operations.
-
Data exchange scheme. We agree on what is transmitted and in which direction: menu and prices, stock, order statuses, check closure, cancellations. We establish the main data source in case of conflict and the rules for retries.
-
Integration setup. We bring up the exchange between the portal and iiko or R_Keeper on a test environment: we map the nomenclature, configure roles and access, and limit the frequency of requests to the POS so the exchange does not interfere with restaurant operations.
-
Testing on real orders. We run live scenarios: dine-in order, pickup, delivery, cancellation, payment, partial refund. We compare the check's composition and amount before and after exchange, and review the error log and portal behavior when the POS is unavailable.
-
Launch. We migrate locations one by one, starting with one shift, and monitor the exchange queue and response time — a failure is localized to a specific location rather than the entire network.
-
Handover to support. We provide the exchange scheme, instructions for shift staff and administrators, and procedures for typical failures and access. After that, we monitor the exchange and investigate incidents using logs.
What the customer receives: a documentation package
We deliver the documentation package together with the restaurant portal — not as an appendix to an acceptance act, but as a working environment.
With it, the on-duty engineer can bring the exchange back up after a failure, and a new floor administrator can log into the system without an email to support and without calling us.
We assemble the package so it can be used without knowing the portal's internals: each document answers the question "what to do if this has failed."
- Integration schemes — flows between the portal, POS, and accounting system (iiko, R_Keeper): exchange direction, polling frequency, behavior when the source is unavailable, and the manual reload procedure.
- Data exchange rules — mapping of nomenclature, modifiers, stop-lists, and order statuses, the procedure for discrepancies in reference data, and the point at which a human is involved.
- Access rights — a role matrix from guest to manager: which sections each role sees, who can access reports and exports, and where two-factor confirmation is required.
- Update procedure — rollout window, test environment run, rollback point, and the list of approvers if the exchange logic with the POS changes.
- Backup — frequency, retention depth, and mandatory recovery testing: we do not consider a copy that has never been restored to be a backup.
- Instructions for staff — scenarios for the waiter, operator, and administrator: how to place an order when communication is lost, close a shift, and clear a stuck status.
We version documents together with the code: a change in the exchange is an edit to the scheme and procedure, not a verbal agreement. After handover, the package remains alive, and the portal logic can be restored from documentation rather than logs.
Case study: eliminating discrepancies between the website and the accounting system
What it was before
A restaurant with two dining areas and delivery kept its menu and prices in the accounting system and duplicated them manually on the website.
The stop-list arrived to the manager via messenger, and before the website was updated, a guest could manage to order a dish the kitchen no longer had.
Each shift spent 30-40 manual reconciliations: orders from the website and from the POS were compared by eye, and discrepancies surfaced at day close — when fixing them is most expensive.
What we changed and what we achieved
We built a restaurant portal with direct integration into iiko and R_Keeper: the menu, prices, and stop-lists come from the accounting system, and an order from the website enters the same environment as an order from the POS.
Publication was moved to a separate layer with a cache: if the external system is unavailable, the portal serves the last valid version of the menu and continues accepting orders instead of showing an empty page.
Manual reconciliations dropped to 2-3 per shift instead of 30-40 — they are triggered only by non-standard cases such as a partial rejection of an item.
Menu change publication went from 3-4 hours to 5-10 minutes: the edit is made once in the accounting system, and it is immediately visible on the website.
At peak — Friday evening, holidays — the portal sustains a twofold increase in orders without stock discrepancies, whereas previously those were exactly the hours when urgent reconciliations began.
A separate effect is predictability: menu updates no longer depend on whether the person who knows how to edit the website is on shift.
The integration logic and error handling are covered by tests, so an abnormal response from the external system is visible in the log rather than in a guest complaint.
What to do if another website and accounting system are already in place
There is no need to break the existing environment: the portal connects to the current accounting system through its standard software interface, and the previous website continues accepting orders until the switchover.
Data about the menu, stop-lists, prices, and stock is read from the system — it is not duplicated manually in the portal. This is exactly what removes the discrepancy between the dining area and the online channel.
| Option | What we do | What remains unchanged |
|---|---|---|
| Supplement the current website | Add delivery and reservations to the portal | The structure, addresses, and design of the old website |
| Parallel launch | The portal runs alongside, and orders go to one accounting system | Accounting, inventory, and kitchen switch to the new environment later |
| Phased migration | Migrate sections one by one with the ability to roll back | Order history and guest data remain in place |
The migration order is always phased. First we bring up the portal at a separate address and compare menu and stop-list output with the accounting system on live traffic — discrepancies are visible immediately, but they do not affect guests.
Then we enable parallel launch: orders from both websites converge into the current accounting system — iiko or R_Keeper — in a single stream, and the kitchen works from its usual screen. We switch the main domain after reconciliation matches without manual corrections.
Data preservation is handled on the source side: orders, guests, and purchase history remain in the accounting system and reach the portal without exports or manual transfers. Switching back takes minutes — the addresses and settings of the previous website are not deleted.
Describe your current environment — we will come back with a migration plan and the sequence of stages.
Frequently asked questions: timelines, load, and data exchange
It is better to resolve technical doubts before the start. Below are answers to the questions most often raised by the customer's engineers: timelines, behavior during a POS failure, exchange scheme, and the scope of work after launch.
How long does implementation take?
The first phase is four to eight weeks: catalog and cards, exchange scheme, storefront, admin panel. Half the time is taken up by reconciling nomenclature and stop-lists with the accounting system — discrepancies here surface already in production.
What happens if the POS is unavailable?
The storefront runs on cache: the menu, prices, and stop-lists are served locally, orders are queued and go to the POS as soon as communication is restored. The customer sees no errors.
How is the exchange with the POS structured?
It is two-way: outward — nomenclature, prices, stop-lists; back — orders and statuses. Messages are idempotent, so a repeated send does not create a duplicate order.
Can we change the menu ourselves?
Yes, in the admin panel: categories, descriptions, composition, photos, prices, and stop-list — without code changes. Roles and change history are configured separately so that edits do not go to production blindly.
What is included in post-launch support?
Monitoring of exchange and availability, updates, incident investigation according to procedure, and enhancements. The failure log shows which nodes degrade first.
Let's discuss the task — we will come back with an estimate and work plan
To come back with an estimate and work plan rather than generalities, we need a minimum of inputs from you: they determine the team composition, stage timelines, and the order of integration with the venue's accounting system.
The more specific the initial data, the more accurate the estimate — and the fewer corrections at the acceptance stage.
- Composition of locations: how many locations, dining areas, and service formats — dine-in, delivery, pickup, banquets — and which one launches first.
- Access to the accounting system: a test environment for iiko or R_Keeper, rights to exchange reference data and orders, and the contact of your system administrator.
- Roles and scenarios: guest, shift manager, order intake operator, manager, franchisee — what each sees and what actions they perform.
- Kitchen business rules: stop-lists, modifiers and dish combinations, preparation time, delivery zones and delivery cost, and work with pre-orders.
- What already exists: the current website and engine, design materials and photos, existing integrations, payment provider, loyalty program, and guest database.
- Launch constraints: ties to a location opening, season, or promotion, requirements for peak-hour load and simultaneous orders.
- Responsible people on your side: who accepts the result by stage and in what mode they approve disputed points.
Describe the task in your own words — we will come back with a breakdown by stages, a team composition for your environment, and a work plan with timelines for each part.
