Branch-Specific Menus and Online Ordering

Solution design

Local menus that hold up at checkout

The ordering service combines a shared restaurant catalogue with branch-specific prices, opening hours, availability and collection rules. Basket validation checks the selected location again when the customer commits. Accepted orders carry item choices, modifiers and payment context into the correct kitchen workflow. Local managers retain the controls needed to pause an unavailable item or service.

Each branch uses a shared menu structure with controlled local settings. Customers see relevant choices before building a basket, while restaurant teams receive orders that match their service windows, item mappings and preparation rules.

• Accurate choices for the selected branch
• Fewer ambiguous modifiers on kitchen tickets
• Clear separation of payment and order acceptance

Business context

A restaurant group with multiple locations, shared menu items and branch-specific service conditions.

Core capability

Software Development

A familiar menu does not mean identical service

One branch offers breakfast, another closes earlier, and a third has temporarily run out of a popular ingredient. Separate ordering sites make these differences expensive to maintain. A single menu applied everywhere creates another problem: customers discover the local restriction only after they have chosen their food.

The service identifies the location and fulfilment method early. Menu availability, opening hours, lead times and delivery boundaries follow that choice. The customer can change branches, but the basket is checked again against the new location. Items or options that no longer apply are explained clearly instead of disappearing without context.

A modifier changes more than the price

A choice such as bread, size or side may be required, optional, mutually exclusive or limited in quantity. Those rules affect the customer interface, total price and kitchen ticket. The menu model records them explicitly, including which options depend on another choice. Free-text instructions remain separate from structured options that the kitchen must reliably recognise.

Each sellable configuration maps to the identifiers expected by the point-of-sale system. Approved dietary and allergen information has a defined source and review process; the interface does not infer it from an item name. Central menu owners control the shared catalogue, while branch managers receive specific authority over local availability and temporary service changes.

Shared items, deliberate local differences

The master catalogue provides stable item and option identities. Location settings define approved price overrides, service windows, availability and routing. A branch does not need its own copy of every menu item to stop selling one dish for the evening. Local differences remain visible, so a central update can show which locations inherit the change and which retain an override.

Menu versions also protect active baskets. Checkout revalidates the price and choices against the current version, but preserves the customer's selections long enough to explain any change. Server-side validation enforces the same rules as the interface. An outdated screen or altered request cannot submit an invalid combination simply because the browser once allowed it.

The basket is checked again at the point of commitment

Customers choose the branch, fulfilment method and available time before completing item choices. Required modifiers have clear labels and useful error messages, and the basket shows the full price before payment. At submission, the service checks the menu version, current availability and service capacity again. A changed condition returns a specific correction rather than a generic checkout failure.

Payment and restaurant acceptance are recorded separately. The sequence depends on the restaurant's payment and point-of-sale integration, but the customer-facing status reflects the actual stage. A successful payment authorisation does not describe an order as accepted if the restaurant has not received it. Staff and support share the same reference when investigating an uncertain submission.

A sold-out item needs a clear recovery path

An item can sell out while it is in a basket, or a collection slot can fill before submission. The interface keeps unaffected choices and asks the customer to resolve the specific conflict. It never substitutes an ingredient or accepts a changed price silently. If the branch pauses ordering, the page explains the affected service and shows only the alternatives the operation can support.

Repeated taps, payment callbacks and delayed point-of-sale responses use a stable order reference. An uncertain result is reconciled before another charge or restaurant ticket is created. Menu editing, service pauses and financial actions have separate permissions. Staff can see whether an order is awaiting payment confirmation, restaurant acceptance or a technical recovery, rather than handling every failure as another customer cancellation.

The kitchen ticket is part of acceptance testing

The first branch exercises the whole menu, including unusual modifier combinations, scheduled service changes and the actual printed or displayed kitchen ticket. A basket that looks correct on a phone can still produce an unusable instruction at the point of sale. Staff check the resulting quantities, prices and preparation notes before the configuration is considered ready.

A second branch with different operating conditions tests whether the shared model accommodates genuine variation. Its launch checklist covers hours, local prices, item mappings, payment behaviour and the contact responsible for exceptions. Reusable configuration keeps these differences manageable; separate code for each restaurant makes later menu changes harder to verify and support.

Managers can pause service without editing the catalogue

Central owners manage the shared menu and approved content. Branch managers control the local actions required during service, such as marking an item unavailable or pausing a fulfilment method. Finance owns cancellation and payment procedures, while technical operations maintains mappings and integration health. The administration screens reflect these distinct responsibilities.

Changes can be previewed against affected branches and active service windows. A version history helps support explain why a customer saw a particular price or choice. Operational reports separate menu configuration errors from capacity pauses and payment problems. That distinction directs the correction to the right owner instead of treating every rejected order as a checkout design issue.

An order is successful when the branch can act on it

The review follows orders through restaurant acceptance, including any clarification staff need before preparation. Rejected baskets are grouped by rule, location and cause. Point-of-sale mismatches receive different treatment from a legitimate sold-out item. This makes it possible to correct a broken mapping without weakening a useful availability check.

Mobile, keyboard and interrupted-session checks cover the decisions customers actually make: selecting a required option, changing branches and recovering after a slot becomes unavailable. During service, the team also checks whether managers can make a timely local change and whether existing customers receive an understandable response. The shared menu is useful only when both sides can operate it under pressure.

The choices behind the solution

How the solution is evaluated

These measures define the evaluation criteria for the workflow, its controls and the quality of completed tasks.