OMS for Restaurant and Food Delivery Order Routing

Restaurant and prepared-food order management compresses the entire order lifecycle — placement, preparation, and delivery — into a window measured in minutes rather than days, which forces an OMS to route orders based on kitchen capacity and courier availability in near real time rather than static inventory availability.

Routing on Capacity, Not Stock

A traditional OMS asks "is this SKU in stock at this location." A food-order OMS asks "can this kitchen produce this order within an acceptable time window given its current queue." Kitchen capacity is a perishable, constantly resetting resource — a location with plenty of raw ingredients can still be effectively "out of stock" if its prep queue is backed up, and the OMS needs a live throughput signal from the kitchen system to route accurately.

Order-to-Prep-to-Courier Handoff

The order lifecycle has three tightly coupled stages that a generic OMS status model does not capture well: order accepted by kitchen, food preparation in progress with an estimated ready time, and courier assignment timed to arrive close to that ready time. Assigning a courier too early wastes their time waiting; assigning too late adds unnecessary delay. The OMS needs to expose the prep-time estimate as a live, updating field that the dispatch system consumes directly.

Order placed Kitchen accepts + ETA prep Courier assigned near ready time
Multi-Item Orders From Split Kitchens

Orders combining items from more than one kitchen or vendor (a marketplace model) need the OMS to coordinate two independent prep timelines into a single pickup, deciding whether the courier waits at the slower kitchen or the order is delivered in two trips. This mirrors split-shipment logic from physical retail but on a compressed timescale where a ten-minute delay is a service failure rather than a minor inconvenience.

Demand Surges and Dynamic Throttling

During peak periods, kitchens can become oversubscribed faster than any manual process can react. The OMS should support dynamic order throttling — temporarily hiding a menu or extending quoted prep times as the queue grows — driven by the same live capacity signal used for routing, rather than accepting orders indefinitely and letting service quality collapse across the board.

Cancellation and Refund Windows

Because food spoils and cannot be resold, the OMS's cancellation policy needs a hard cutoff tied to preparation start, not a generic time-based window. Once a kitchen has started preparing an order, cancellation should trigger a different refund policy (partial or none) than a cancellation requested before preparation began, and this distinction needs to be enforced automatically rather than left to case-by-case customer service judgment.