Table of Contents

Special Use Cases

This section outlines how UEAT handles special order types such as Hub Orders, Kiosk Orders and other use cases. These use cases are identified through specific fields in the order model and may require unique handling by the POS.


Hub Orders

Hub orders are routed through a centralized delivery or marketplace system. They are identified by the Service.Channel field in the order payload.

Identification

"Service": {
  "Channel": "skip-the-dishes" | "uber-eats" | "doordash" // Indicates a hub or marketplace order.
}

The channel name determines how certain fields are populated and processed in the order payload.

Key Considerations

  • These orders originate from third-party platforms.
  • Delivery details are often managed outside the restaurant.
  • The Tip for delivery is managed outside the restaurant.
  • Payment type includes a specific PaymentType enum for hub transactions.
  • It's possible that UEAT will add new values in this enum in the future.

Kiosk Orders

Kiosk orders are placed directly by customers using in-store kiosks. They are identified by the presence of a Service.Channel indicating kiosk.

Identification

"Service": {
  "Channel": "KIOSK",
  "KioskId": "string" // Identifier for the kiosk device
}

Key Considerations

  • KioskId is an alphanumeric identifier, not a name such as Lobby.
  • Customer information may be partially or fully missing (e.g., no email or name).
  • Orders are always for ASAP preparation.
    • See PreparationType
  • POS should distinguish kiosk orders for routing and reporting.
  • Tip handling and simplified menu navigation may differ.
  • Kiosk orders should not include delivery info.
  • Kiosk Order may be for take-out or dine-in.
    • See OrderType

Ghost Kitchen

The Ghost Kitchen concept can be applied to different business model.

  1. The first concept is having 2 different brands using the same location and the same POS to receive orders. In UEAT, these 2 brands will have a separate BackOffice but it is primordial that the POS can accept 2 separate POS configurations to receive orders.

  2. The second concept is mostly applied to restaurant with a catering offer. This location is using the same UEAT BackOffice but will have 2 different offers on the online ordering and usually 2 different menus. This concept will also have 2 different POS configuration to receive orders.

Identification

The way to differentiate from which POS configuration the order is coming from is the Location ID.

Key Considerations

Important : Considering the orders are coming from 2 different online orders, it is highly possible that the OrderId is the same for the 2 different locations on the same day. Your POS must be able to accept this use case or distinguish the Location ID to fully support ghost kitchen and catering business models.


Summary

Use Case Identifier Fields Notes Restrictions
Hub Order ExternalOrderId, ExternalDeliveryId External delivery, marketplace integration DeliveryInfo : will be null if the order is a Hub delivery order
PaymentType : is always Hub
Kiosk Order Service.Channel = KIOSK May lack customer info, ASAP prep, in-store flow Customer : All fields can be empty here depending on what is configured on the kiosk.
Ghost Kitchen Location ID OrderId is the same for the 2 different locations on the same day

These identifiers should be used by POS systems to apply appropriate logic for processing, routing, and reporting.