By Artem Korsakov ·
In short: A restaurant website that takes orders must separate submission from confirmation: “order received” and “order confirmed” mean different things. Pickup needs a location and a realistic ready time; delivery needs the address, delivery cost and minimum order checked before payment. Payment, cancellation and unprocessed orders are designed separately and tested with a trial order during working hours.
A restaurant website with delivery and ordering must pass the contents, timing and fulfilment method to the kitchen and the operator, and explain to the guest how confirmation works. The cart collects a selection, but on its own it does not confirm that the order can be fulfilled. To launch, you need to connect the visitor’s expectations with what the kitchen and the operator actually do.
Pickup and delivery can share one menu, but their fulfilment conditions differ. So first describe the path for each option, including situations where the order cannot be accepted. This helps avoid promises that the interface makes before the restaurant does.
Separate submission from confirmation
The phrase “order received” means the details have arrived. The phrase “order confirmed” means the restaurant has decided to fulfil it on certain terms. If a staff member needs to review the order, the screen after submission must not create the impression that it has been finally accepted.
In a hypothetical café, the operator checks how busy the kitchen is and calls the guest. After checkout, the screen should make this process and the expected next step clear. If the restaurant wants automatic confirmation, it needs agreed rules for availability, timing and accepting orders without an operator. A similar choice between a request and automatic confirmation exists for table bookings.
Statuses should correspond to actions. “Being prepared” makes sense after the order has been passed to the kitchen, and “ready for pickup” after it is actually ready. Extra intermediate labels do not help if staff cannot keep them updated during normal work.
Pickup needs a location and a time
With several locations, it is important to determine right away where the selected order will be prepared and handed over. Being able to change the location after filling the cart can affect dish availability, price and timing. These dependencies need to be explained before confirmation.
The time-slot picker must not allow ordering for a time the restaurant can no longer meet. It takes into account opening hours and the agreed preparation time. If staff manually confirm a specific time, the interface should talk about the preferred time. In that case, a guaranteed pickup slot cannot be promised.
Test orders placed just before closing and for the next day. Dining-room hours and kitchen order-acceptance hours may differ. A single general note about opening hours does not replace a rule that actually limits checkout.
Delivery starts with a serviceable address
Before paying, the visitor needs to understand whether their address is served, how much delivery costs and which conditions depend on the order total. For a small area, a clear zone selection may be enough. More complex coverage will require a different way of checking, which is assessed separately.
The address includes the details the courier needs, but the form should not force people to fill in fields that do not apply. For example, an apartment number is not needed for handover at an office entrance. Notes about the entrance and preferred contact method are passed along with the order so that the operator does not have to reconstruct them from separate messages.
In a hypothetical delivery service, two zones have different minimum order amounts. When the address changes, the conditions must be recalculated and the change shown to the guest. Keeping the old free delivery after a more distant zone is selected creates a conflict that is hard to resolve in conversation.
Payment and cancellation need their own scenario
A successful payment and an accepted order are related, but they are different events. Think through a delayed response from the payment system, the page being closed and the guest returning later. Staff should see the reliable state and not ask for the payment to be repeated without checking.
The cancellation and refund procedure is agreed with the restaurant and the chosen service providers. The website reflects the current terms, and disputed questions are checked with the responsible specialists. You cannot promise automatic refunds just because a payment button has been connected.
After launch, decide how unprocessed orders will be monitored. It is useful to see orders without confirmation and the reason for the delay: an overall sales counter will not show this. The responsible staff member should understand what action is needed if a kitchen message did not get through or the guest does not respond.
Test the process during real working hours
Run a trial order through a staff member, the kitchen and the handover. Add:
- an unserviceable address;
- a dish on the unavailable items list;
- a change to the order contents;
- a delayed notification.
How to set up a unavailable items list is covered in the article about the digital menu.
Note where a phone call is needed and what information gets lost.
To start, a simple process with operator confirmation is acceptable if the visitor sees it in advance. Complexity is added after the load and rules have been tested. With trike_dev you can discuss a restaurant scenario based on your menu and examples of real conditions, without confusing an interface demo with a ready-made delivery service.
Частые вопросы ### Does a successful payment mean the order has been accepted?
No. Payment and order acceptance are related, but they are different events. Staff should see a reliable state for both, and the guest should understand when the restaurant has confirmed the order.