Online restaurant orders: menus, kitchen acceptance and time slots

A guest has paid for dinner on the website, but the administrator has not seen the request and the kitchen has already closed its hot-food section. Online restaurant orders cannot be considered accepted in this situation simply because the payment button worked. Before launching a direct channel, agree on three things: which menu items are actually available, who confirms preparation, and how many orders the restaurant can fulfil at the chosen time.

Start with the rules behind your promise to the guest, not the choice between a website and an app. Below is a plan for restaurant owners and operations managers: how to prepare the menu, acceptance process and time slots, test failures, and define the scope of the first launch. This is neither a courier-routing guide nor an overview of every order management system.

First agree on when an order is accepted

Separate receipt of the request, payment confirmation and the kitchen's agreement to fulfil it. Each event needs an owner, a system record and a clear message to the guest. “Order accepted” should mean that the restaurant has checked the items, timing and ability to prepare them, not merely saved a basket.

Agree on whether an administrator confirms each order or the system does so automatically under defined conditions. The first approach needs staff coverage and monitoring for missed requests. The second needs checks on dish availability, kitchen capacity and the current schedule before confirmation. Automation without these limits only issues impossible promises faster.

Assign an owner to each decision

The back-office system might maintain the menu and prices, a designated shift employee the unavailable-items list, and the ordering module the available slots. This is a possible allocation, not a universal architecture. Document exactly where data changes, how it reaches the website, and who can pause acceptance. Otherwise, the website and kitchen will have two different versions of the truth.

Turn the menu into selling rules

A photograph and dish name do not describe availability. For every item, define the variant, portion, price, permitted extras, selling hours and preparation location. Kitchen staff must receive an unambiguous item breakdown: “no onion” must not get lost in a general address comment.

Restaurant menu synchronisation needs separate rules for price changes and temporary unavailability. Establish whether the back-office system supplies prepared portions, ingredients, or only a manually maintained unavailable-items list. Having an ingredient in stock does not itself prove that a dish can be sold: the required employee, equipment or packaging may be unavailable.

Recheck the basket before confirmation

A dish can become unavailable while the guest enters their contact details. Check availability and the final total on the server before creating a confirmed order. If the contents have changed, explain why and invite the guest to review the basket. Do not substitute another item without the guest's agreement.

For meal bundles and modifiers, check combinations, not just the base dish. An unavailable sauce may block a particular bundle but not the entire menu. A responsible restaurant employee must approve ingredient and allergen information; a guest's free-text comment must not become an automatic guarantee of safe preparation.

Slots must reflect kitchen operations

A time slot is an available window for receiving an order, not a decorative list of times. Its boundaries depend on preparation, kitchen-section workload, packing and collection method. Pickup and delivery may use the same kitchen, so do not treat them as two independent, unlimited queues.

Pickup time slots can initially be limited by a clear capacity rule approved by the shift manager. With a more complex menu, one request is not equivalent to another: a large bundle and a drink place different demands on the kitchen. Do not start with sophisticated forecasting before you have verified preparation data.

Separate kitchen status from payment status

The guest interface can use simple states: “awaiting confirmation”, “preparing”, “ready for pickup”, “handed over” and “cancelled”. Internally, the system also needs a reason for any stoppage and a responsible person. A paid order may still be awaiting kitchen acceptance, while an order approved for preparation may be payable on collection if that method is allowed.

Square's official documentation separately describes the initial PROPOSED fulfilment state and restrictions on displaying orders in its products. This is a useful illustration of why a created record is not the same as a task visible to staff. However, Square's rules are not a standard for all point-of-sale systems and do not establish that a particular solution is available in your country.

Before choosing an integration, ask for your point-of-sale system, or POS, and kitchen display system, or KDS, to be tested in a test environment. Is an unpaid request visible? Are modifiers passed through? Does a kitchen rejection reach the website? Are changes after acceptance supported? The existence of an API—a software interface for exchanging data—does not answer these questions.

Cancellation must also resolve the financial action

Define the sequence for payment, capture or reservation of funds according to the capabilities of the chosen payment service. If the kitchen rejects an order after payment, you need a guest notification, someone responsible for the refund, and monitoring of its outcome. Do not call a refund complete simply because a request has been sent.

A repeated payment-service notification must not trigger preparation twice. Stripe's documentation on handling webhook events explicitly addresses duplicates and arrival order. Design protection against repeated actions and state reconciliation for your provider, rather than assuming every notification arrives once and on time.

Hypothetical example: the last portion and an occupied window

Imagine a restaurant with one pickup location. This is a learning scenario, not a GL.ua case study. One available portion of lasagne remains on the website, and the shift manager has allowed one more order in the nearest window. Two guests open baskets containing that dish at the same time.

At confirmation, the first basket reserves the portion and a place in the window as one coordinated operation. The second receives a message that conditions have changed: the dish can no longer be ordered and the available time must be selected again. Disabling the button after a page refresh is not enough—the decision must be checked in the system accepting orders.

The administrator then accepts the first request, but the response to the website is lost. A repeated request with the same identifier must return the existing result rather than create another kitchen ticket. If the guest abandons payment, the temporary reservation is released according to an agreed rule. The specific reservation period is defined during design, not taken from an arbitrary template.

Test before opening the channel to guests

For the pilot, choose one location, a limited menu and an agreed collection method. This reduces dependencies but does not remove the need to test failures. The administrator and a kitchen representative should run through the scenarios together, not merely receive a video of a successful purchase.

1. Change a price and the unavailable-items list while a basket is open. Check the final contents and the explanation shown to the guest before payment or confirmation.
2. Submit simultaneous requests for the last portion and the last place in a slot. Make sure the system has not confirmed both.
3. Disconnect the receiving device or POS exchange. Check the alert to the responsible person, the guest message and the ability to pause the channel.
4. Repeat the payment notification and order-creation request. There should be one kitchen task, with no repeat charge caused by the website's own logic.
5. Cancel a request before acceptance and after preparation has started. Check permitted actions, refunds and the decision log without assuming the same rules apply at both stages.
6. Test preordering, shift closing and changing the available time on a phone. Check all messages and the actual appearance of the task in the kitchen.

Waiting and error messages should be agreed as early as the interface-state specification. The acceptance record should contain not “everything works”, but the expected and actual result of each test, an owner, and a decision on any discrepancy found.

What constrains launch, timing and budget

The main risks here are operational: an outdated unavailable-items list, an unnoticed request, overestimated slot capacity and an unclear cancellation process. Add technical dependencies: POS unavailability, notification delays and different dish identifiers. Each risk needs a detection method and an action the shift is authorised to take. A manual fallback process must be documented rather than depend on the administrator's memory.

Timing depends on menu readiness, access to a test back-office system, supported integration operations and staff availability for testing. Plan separate deliverables: an agreed process, a prototype, test data exchange, exception testing, training and a limited launch. If POS documentation is insufficient, a technical proof of concept is needed first—not a calendar promise for the whole project.

Costs include analysis and data preparation, the menu and basket interface, slot rules, exchange with the POS and kitchen, payment flow, notifications, testing and training. Separately account for hosting, service fees, monitoring, updates and support. Fiscal and legal requirements must be checked for the specific operating model with the relevant specialists; connecting a payment module does not itself satisfy them.

Add delivery only after assigning responsibility for readiness and handover. Transport planning is a different operational domain; the article on integrating a website with a TMS explains its boundaries. A separate transport system may be unnecessary for an initial pickup service.

Start with a promise the restaurant can keep

A direct channel is ready for a pilot when the menu reflects real availability, the kitchen sees and accepts tasks, and the slot does not sell more capacity than the restaurant has approved. Without that, a new design or app will not close the gap. First test one complete journey and the shift's authority to stop acceptance, then expand the menu and audience.

To prepare this channel, contact GL.ua (Glyanec) about online store development with integrations. Provide a sample menu, an acceptance-process description, POS details and failure scenarios: these form the basis for a feasibility check and estimate, not a reason to order every possible feature immediately.