Skip to main content
A menu is what customers browse — categories, products, prices, photos, and what is available right now. In Fire spark, menus are rooted in your POS or RMS and composed for each selling context: channel, store, fulfillment type, or schedule.

​
Why menus are central

For marketing and commercial teams, the menu is the main commercial asset online: what you sell, at what price, with what story. The old problem is not only menu drift between Uber Eats and your app — it is maintaining separate menu stacks when strategy actually calls for different offers per surface. Fire spark starts from one operational source and lets you shape what each audience sees:
  1. Your team updates items, prices, or 86s something in the POS — the master data stays accurate.
  2. Fire spark syncs that foundation and applies the menu rules you configured.
  3. Customers see the right catalog for their channel, store, fulfillment mode, and time — not a blind copy-paste everywhere, and not a disconnected spreadsheet per partner.

​
What you can vary

DimensionCommercial use
ChannelFull menu on your app; a focused subset on an aggregator; kiosk-only combos
StoreRegional items, local pricing, or locations that do not list delivery-only SKUs
FulfillmentDelivery menu vs pickup-only items vs dine-in exclusives
ScheduleBreakfast vs lunch vs late-night without maintaining parallel integrations
You choose when surfaces should match and when they should diverge. Operations still update the POS once; Fire spark decides how that flows into each composed menu.
PieceRole
CategoriesGroup products (mains, drinks, combos)
ProductsIndividual items, modifier groups, and modifiers
AvailabilityWhat is orderable now, per store and context
Presentation can differ too — title, image, or placement per channel — without duplicate item masters in your operation.

Channels

Surfaces where each menu version appears

Categories

Structure inside the menu

Products

Items customers add to cart

Stores

Where availability and local menus apply