# Branch-Specific Menus and Online Ordering Restaurants | MT BYTES solution study Branch-specific menus combine local prices, availability and service times with shared catalogue rules, keeping accepted orders accurate through the kitchen handoff. 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. ## Solution design ### Local menus that hold up at checkout 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 ![Solution study artwork](../../images/solution-studies/selected/05-hero.webp) ## Scope - Master menu and location configuration - Modifier, price and service-window rules - Accessible basket and checkout interactions - Point-of-sale and payment integration - Branch controls for availability and temporary pauses ## 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. ## Operational flow 1. **Choose branch and service.** The customer selects a location, fulfilment method and valid time. 2. **Build a valid basket.** Menu rules guide quantities, modifiers and the complete price. 3. **Recheck the commitment.** Checkout confirms current availability, configuration and capacity. 4. **Route the order.** The restaurant receives mapped items under a stable order reference. 5. **Confirm the accepted state.** The customer sees restaurant acceptance or the specific action still pending. ## Key decisions ### Choose the location early Apply local service rules before the customer builds a basket. Customers should not discover branch restrictions only at payment. ### Version the menu Recheck active baskets against the current configuration. Price and availability changes need an explicit, recoverable response. ### Separate payment from acceptance Retain both states and show the current stage accurately. A payment response cannot confirm that the restaurant has received a usable order. ## Evaluation measures These measures define the evaluation criteria for the workflow, its controls and the quality of completed tasks. ### Orders requiring clarification **Measure:** Record missing or ambiguous instructions at the restaurant. **Success criteria:** Menu rules produce tickets staff can prepare without reconstructing customer choices. ### Acceptance failures by location **Measure:** Separate payment, routing, availability and configuration causes. **Success criteria:** Each recurring failure reaches the owner able to correct it. ### Branch configuration accuracy **Measure:** Compare live menus, service windows and prices with approved settings. **Success criteria:** Local changes appear correctly and do not create unexplained central overrides. ## In practice The shared ordering service depends on a precise account of what each branch can sell and when. A governed menu, deliberate local controls and a checked handoff to the restaurant keep those details consistent. Customers retain a familiar experience while staff receive an order that matches the kitchen's actual service.