Restaurant online ordering: a checklist for running the service

1. Decide what service you can reliably offer

Start with a clear service model: collection, local delivery, orders placed in advance or a combination. Each creates different work for the kitchen and front of house. A venue that handles occasional telephone collections may need a different setup when orders arrive continuously online. Do not choose software on the assumption that an existing informal process will scale without changing responsibilities.

Identify the menu available through each channel. You may choose a smaller ordering menu than the menu for customers eating at the restaurant because some dishes travel poorly or require more preparation. Explain the decision to customers through a clear menu rather than leaving staff to apologise after payment. Include drinks, extras and packaging requirements in the planning, because they affect both the order and the handover.

State when the service is available. Trading hours, ordering hours, deadlines for starting preparation and collection times are related but different. A restaurant can remain open while no longer accepting new orders. Define the last order time and the latest fulfilment promise separately. Include bank holidays, private events and planned closures in the ownership process.

If you are looking for an online ordering system in Northern Ireland, start with the needs of your restaurant. A supplier’s location or a familiar platform name does not tell you whether its system can handle your order limits, menu options or kitchen routine. Ask for a demonstration using your own service rules, including a complicated meal and a busy collection window, rather than relying on a simple sample takeaway.

Choose a controlled initial scope. One collection service on selected evenings may be easier to test than launching delivery, orders placed in advance and multiple menus at once. Choose that smaller start only if it gives your team a manageable way to practise and check the service. The right sequence depends on staffing, demand and the amount of change your team can manage.

Our online ordering and ecommerce service connects the customer purchase with the team receiving the order. Use the service brief to define both sides of that handover.

• Define collection, delivery and services for orders placed in advance separately.
• List the menu and operating window for each.
• Identify the shift manager who can change availability.
• Agree a realistic first release and the conditions for expanding it.

2. Prepare a menu that produces an unambiguous kitchen order

Create a structured menu list with dish names, descriptions, prices, options and availability. Check that the kitchen and the customer use the same meaning for each item. A short internal code may be useful on a ticket but confusing on the website. Decide how the system connects the name customers see to the name staff recognise during service.

List modifiers precisely. A required choice of size is different from an optional extra. A meal deal may require one main, one side and one drink; it should not accidentally permit two mains because the options were grouped loosely. Record which choices change the price and which combinations should not be available. Test the most complicated meal, not just the simplest dish.

Think about quantities inside a basket. If a customer orders two burgers with different toppings, can each be identified clearly? Does removing an ingredient affect one item or both? The kitchen ticket should preserve those distinctions. A visually tidy basket is not enough if it combines details that staff need to prepare separately.

Assign responsibility for editing the menu. Name who can add a dish, change a price, remove an unavailable option and publish a seasonal menu. Decide whether someone checks significant changes before they go live. A website menu that depends on a person who is absent during service is difficult to keep accurate.

Use images and descriptions that reflect the actual product without creating unnecessary expectations. If accompaniments vary, explain that clearly. Check the same information on the phone screen customers will use, including the expanded options and final basket. Long descriptions can be useful, but important choices must remain easy to identify.

3. Give food information a named approval process

Food information must come from the people responsible for the menu and preparation process. A website designer should not infer ingredients or dietary suitability from a dish name or photograph. Provide approved information, explain where it is maintained and identify the person who can confirm a change. This article is an operational checklist and does not replace food safety or legal advice.

The Food Standards Agency’s guidance for food delivery and takeaway says allergen information must be available before purchase is completed and when food is delivered. Its guidance also stresses keeping ingredient information up to date when recipes change. Use the official guidance linked below to check your arrangements with the people responsible for food safety.

In the website brief, explain how a customer finds approved information and how a query reaches someone who can answer. Avoid relying on a box for written requests as the whole process. A message may be overlooked, misunderstood or arrive after preparation has started. Decide which situations need a conversation before an order is accepted and make that route clear.

Rehearse how information reaches the kitchen and the handover team. The website can display wording, but the business must connect that wording to its actual preparation and communication process. Ask staff to explain the route in their own words. Any uncertainty is a reason to clarify the operation before opening the channel.

Include recipe and supplier changes in the update process. Who checks the information, who edits the ordering menu and how do staff know the change is live? Keep a record of approval that is easy for the responsible team to find. Avoid copying old menu descriptions into a new system without checking that they remain accurate.

4. Set promises using kitchen capacity, not just a clock

Discuss what limits output during a busy service. It may be the oven, the fryer, packing space, a single preparation station or the person handing over collections. A fixed order count can be a rough control, but five large family orders may require more work than five small ones. Ask how the proposed system represents the limit that matters to your kitchen.

Define preparation time, slot capacity and what happens when the deadline for ordering passes. If the website offers a collection time, staff need to know whether it is a customer request or a confirmed promise. Explain what happens when the next slot fills while someone is still choosing dishes. A basket started twenty minutes ago should not quietly retain a promise the kitchen can no longer meet.

Include orders from diners and telephone customers in the discussion. Online orders may be only one part of the kitchen’s workload. Decide who can reduce available slots or pause ordering when other channels become busy. The control must be practical for the person working the shift, not available only through an administrator who is elsewhere.

Hypothetical capacity example: a restaurant initially considers accepting six orders per collection slot. A rehearsal shows that several meal deals create a different packing load from individual dishes. The team changes the proposed rule and tests again. This is an invented planning scenario, not a recommended limit or an observed client result. Your own staff should establish suitable rules.

Ask what happens to paid orders when capacity is unexpectedly lost, such as equipment failure. Who contacts customers, who can issue refunds within the agreed process and what message appears to new visitors? Pausing future orders does not resolve the orders already accepted, so include both sides of the response.

5. Make collection and delivery boundaries explicit

For collection, show the location, arrival instructions and the meaning of the collection time. A customer should know whether to enter the restaurant, use a separate counter or wait for a ready message. Check that the instructions are useful to someone visiting for the first time rather than written only for regular customers.

Decide how staff match an arriving customer to an order without creating unnecessary confusion at a crowded counter. Order numbers, names and a consistent handover process can help. Consider duplicate names and someone collecting on another person’s behalf. Keep the process proportionate and avoid publicly displaying more customer information than staff need.

For delivery, define the service boundary and test it with real addresses. A radius measured in a straight line may not reflect the route a driver can use. Postcode areas can also include addresses the business cannot reliably reach within its intended promise. The ordering system should explain unavailable destinations before the customer spends time assembling a basket where practical.

List delivery charges, minimum order rules and timing expectations in the brief, then confirm how they appear in the basket. Decide whether delivery time is estimated or scheduled and how changes are communicated. Avoid a generic “ready” message that could mean either awaiting a driver or arriving at the customer’s address.

If drivers or an external service are involved, identify the handover point and the information they require. Who knows the order has left? Who responds if the address is unclear or a delivery cannot be completed? Include the contact route for the customer and the driver. A tracking link, where available, is useful only if its status corresponds to the actual workflow.

• Test a standard address, a boundary address and an unavailable address.
• Check collection instructions on the final confirmation.
• Confirm which staff member records readiness and dispatch.
• Explain how delays and unsuccessful handovers are handled.

6. Separate payment, acceptance and preparation

Agree the meaning of each order state. A payment attempt, a successful payment, a restaurant acceptance and a message saying an order is ready for collection are different events. Customers and staff need wording that reflects the actual state. If acceptance depends on a staff action, explain that before payment and decide how quickly someone must respond.

Ask the supplier what happens when a customer pays but loses their connection before seeing the confirmation screen. Stripe’s Checkout documentation describes this exact kind of interruption and uses server notifications for automated fulfilment. The operational requirement is that staff can identify the paid order without depending on the customer returning to the website.

Check repeated events and repeat clicks. A customer may refresh the page or try again because a screen seems stuck. The kitchen should not receive two preparation instructions for one payment event. Equally, staff need a way to recognise two genuine separate orders rather than assuming anything similar is a duplicate. Ask for a demonstration of both situations.

Define refunds, cancellations and unavailable items before launch. Who can authorise a refund, how does the customer hear about it and how do staff know not to prepare the cancelled item? Do not rely on a colleague noticing that the financial record changed. The kitchen and customer service process need an appropriate notification too.

Choose payment methods with the service model in mind and ask the supplier to confirm their current behaviour. A restaurant preparing food immediately needs a clear rule for any method that remains pending. Do not infer payment completion from an email alone or from a familiar provider name. The agreed workflow should use the reliable payment status made available by the integration.

• Payment succeeds and the customer sees confirmation.
• Payment succeeds but the customer closes the browser.
• Payment fails and the customer tries again.
• The same notification arrives more than once.
• An accepted order is cancelled or partially refunded.

7. Prove the order reaches the right person

Choose how orders enter the kitchen workflow: a dedicated screen, printer, existing connection to the till or a controlled manual process. Each option has dependencies. A printer can run out of paper; a tablet can lose power; an inbox can be ignored during service. The brief should identify how staff notice an order and how someone confirms it has been seen.

Run a ticket readability check with the kitchen. Include multiple dishes, modifiers, quantities, collection or delivery details and the promised time. Ask staff to prepare a practice order using only the information the system supplies. Any explanation given verbally during the test may reveal information missing from the ticket.

Assign responsibility on each shift. “The team will check it” is weaker than a named role with a backup. Decide who watches incoming orders, who checks readiness and who handles customer questions while the kitchen is busy. Explain how responsibility transfers during a break or a shift change.

Ask how unnoticed orders are escalated. A sound alone may be ineffective in a noisy kitchen, while a screen message may be missed when staff are moving around. Choose practical alerts and a fallback suited to the venue. Test them during an ordinary working environment rather than in a quiet office where every notification seems obvious.

If the system connects to a till or kitchen display, test the complete path with the actual hardware and network. Ask what happens when that connection fails and how staff identify orders that require manual action. Avoid entering an order twice simply because its transfer status is unclear. A reliable exception list is often more useful than an assumption that the connection will always work.

8. Rehearse a pause, an outage and a dish that has sold out

Before launch, practise the moments that make service difficult. Make a dish unavailable while it is already in a customer’s basket. Disconnect the kitchen device in a controlled test. Pause new orders, then check what customers see and what happens to orders already accepted. These exercises expose gaps that a normal successful order will not reveal.

Give the shift manager a simple pause process. They should know what it changes, how quickly it appears to customers and whether scheduled orders remain active. Decide who can restart ordering and what they check first. Restarting after an outage may require reviewing payments and order records before letting a fresh queue build up.

Prepare customer messages in advance. A short, clear explanation of a temporary pause is easier to use than improvised wording during a busy service. Include a route for customers who have already paid. Do not invite everyone to telephone unless the team can handle that extra load; the fallback should reflect actual capacity.

Keep an incident record focused on useful facts: when the problem started, which orders were affected, what staff did and what remains unresolved. Do not place payment credentials or unnecessary personal information in an ordinary incident note. The purpose is to support a consistent response and help the supplier investigate.

Hypothetical outage example: the kitchen screen disconnects while new orders can still be paid for. The shift manager pauses incoming orders, checks the main order list and assigns one person to reconcile accepted orders. The team follows its agreed process for contacting customers and only restarts once the queue is understood. This invented scenario illustrates responsibilities; it is not a universal recovery procedure.

Where the website already exists but the journey is unreliable, discuss the specific fault with our website support team.

9. Run a hypothetical rehearsal for a Friday service

Hypothetical example: a neighbourhood restaurant plans evening collections and a limited local delivery service. Its menu includes meal deals, optional extras and a dish that can sell out before closing. The venue and results in this example are invented. Use the structure to create a rehearsal with your own team and approved menu information.

The rehearsal starts before opening. A manager checks hours, menu availability, collection slots and the delivery boundary. A kitchen colleague checks that the test ticket shows each modifier correctly. A colleague serving customers follows the customer journey on a phone, including the point at which collection or delivery is chosen. Nobody assumes the other person has checked it.

The test then introduces problems that staff could face during service. One customer selects an unavailable address. Another has two similar meals with different extras. A third loses the confirmation page after payment. The team checks what customers see, what reaches the kitchen and whether each order appears once in the appropriate list. Label test orders clearly so they cannot be confused with genuine service.

Next, the restaurant marks a dish unavailable and fills the next collection window. Staff check existing baskets, future availability and the messages shown to new visitors. They practise responding to a customer who asks to change an order. The goal is to find unclear responsibilities before those decisions must be made with food already cooking.

Finish with a short review involving kitchen, service and management. Record what worked, what confused people and which issues prevent a public launch. Separate a cosmetic improvement from a problem that could create a missed order or an unrealistic promise. Give every essential correction an owner and repeat the relevant scenario after it is fixed.

Add a rehearsal for a shift change. One colleague starts the test service and another takes responsibility halfway through it. The second person must be able to identify new, accepted and ready orders without a long verbal explanation. Ask them to find an order needing attention and explain the next action. If they rely on remembering a conversation, decide whether the system needs clearer status or the handover process needs a short written record. The aim is a practical transfer of responsibility during an ordinary working shift.

Rehearse an amendment request with the person handling customer queries. Use a change that arrives before preparation and another that arrives afterwards. Staff should know whom to ask, what they can promise and how the outcome reaches the kitchen. The software may support editing, but that does not establish whether the requested change is operationally possible. Record the decision route so someone working a busy counter does not feel obliged to accept an amendment simply because the customer has found a message box.

Check the end of service as carefully as the start. Confirm that new ordering closes at the intended time while staff can still view and complete accepted orders. Review any scheduled orders for the next service and identify who will see them when the venue opens again. Check the wording shown to a customer who visits after closing. If it invites a future order, that promise needs a corresponding operational owner rather than relying on someone remembering to inspect an old notification.

Keep a short record of the rehearsal: the approved scenario list, a record of pass or unresolved results and the person responsible for each correction. Keep screenshots free of unnecessary customer information and use labelled practice data wherever possible. When a correction is made, repeat the affected scenario and any directly connected step. For example, changing an option label may also need a check of the kitchen ticket. This gives the team a concrete reason to approve launch rather than relying on a general feeling that the demonstration looked fine. Keep the final approved checklist accessible to the shift manager, so a future menu or workflow change can be checked against it.

10. Launch with clear ownership and a review routine

Agree a launch checklist that covers the customer journey and the operation behind it. Confirm the live menu, contact details, ordering hours, capacity controls and customer messages. Check actual receiving devices and staff access. A successful rehearsal on a development site does not confirm every setting on the live service.

Give staff short instructions for common actions: pause orders, mark a dish unavailable, find a paid order, confirm readiness and raise a problem. Include the person to contact when the issue is outside their role. Staff should perform these actions during training rather than only watch someone demonstrate them. Keep recovery details in a place the responsible team can access during a shift.

Review the first services carefully. Useful measures include orders requiring manual correction, unclear modifiers, missed alerts and the difference between promised and actual readiness. These observations help improve the operation. They do not by themselves prove that the website has increased sales or profitability, especially over a short period.

Create a regular menu and operations review. Check whether hours have changed, delivery boundaries remain workable and staff are using unofficial workarounds. Ask the kitchen which order patterns cause difficulty. A small change to option wording or collection instructions may be more helpful than adding another promotional feature.

To discuss the ordering service your restaurant needs, start with Podium’s ecommerce service. Bring the menu, the busiest service pattern and the exceptions the team already handles manually. Describe how an order should move from the customer’s choice to collection or delivery, including who handles each step.

If collection is part of the offer, our click and collect planning guide covers availability, customer messages and the physical handover.

• Confirm menu and food information approval owners.
• Check live payment and order receipt using agreed procedures.
• Verify device access, alerts and the pause control.
• Publish accurate collection, delivery and support information.
• Record essential limitations and supplier escalation details.
• Book the first operations review with kitchen and staff serving customers.