SaaSMX
Menu

Product

The product is the working path that follows the order.

SaaSMX uses separate operational surfaces for buyer entry, merchant review, kitchen work, pickup or delivery handoff, and completion. Each surface has a defined responsibility and boundary.

This page explains product structure. It does not display a live merchant environment, invent an interface, or promise compatibility with every outside system.

  • EntryThe buyer submits the supported order
  • ControlThe merchant decides what work can continue
  • ExecutionKitchen and fulfillment complete separate responsibilities

Operational surfaces

Six surfaces keep the order connected through the work.

The sequence names who uses each surface, what it makes visible, and what remains outside its responsibility.

  1. Buyer

    Defined responsibility

    Merchant-branded online ordering

    The buyer enters through an ordering experience led by the merchant's identity and approved configuration.

    • Supported menu and fulfillment choices
    • Buyer contact and order details
    • Checkout and payment entry

    Boundary: The ordering surface begins the order path. It is not presented as the merchant's complete operation or POS.

  2. Merchant

    Defined responsibility

    Merchant review and Order Control

    The merchant reviews the connected order, sees the current condition, and decides whether operational work can continue.

    • Order state and fulfillment path
    • Conditions requiring merchant review
    • The next supported merchant action

    Boundary: Order Control governs the SaaSMX workflow. It does not replace every function of a POS or outside merchant system.

  3. Kitchen

    Defined responsibility

    Kitchen preparation surface

    Accepted work moves into a kitchen-focused surface without exposing merchant administration or business settings.

    • Accepted orders ready for preparation
    • Preparation state and readiness
    • The next kitchen action

    Boundary: Kitchen responsibility begins after merchant acceptance. The kitchen surface does not authorize merchant decisions.

  4. Merchant

    Defined responsibility

    Pickup handoff

    A ready pickup order remains connected to the merchant-controlled handoff and completion path.

    • Ready state
    • Supported pickup handoff
    • Completion action

    Boundary: The merchant remains responsible for the supported pickup process and any identity or handoff checks it requires.

  5. Merchant and approved provider

    Defined responsibility

    Delivery handoff

    A supported delivery order can move from merchant readiness into the approved provider handoff.

    • Delivery-ready state
    • Approved handoff condition
    • Provider outcome returned to the order path

    Boundary: The delivery provider controls its own service availability, pricing, courier operation, and provider-specific outcomes.

  6. Merchant

    Defined responsibility

    Completion and operational record

    The final supported outcome closes active work and preserves the order's completed operational state in the SaaSMX workflow.

    • Final pickup or delivery outcome
    • Completed workflow state
    • Closed active responsibility

    Boundary: This operational record is not represented as an accounting ledger, tax record, or replacement for the merchant's POS records.

Buyer surface

Merchant identity leads the ordering entry point.

The ordering surface begins the connected path with the supported menu, fulfillment, buyer, checkout, and payment details. It does not represent the full merchant operation.

Merchant-branded ordering

Buyer ordering experience

Approved evidence
SaaSMX buyer ordering demo showing menu items, item configuration, cart totals, and buyer information.
Asset evidence.product.orderingPublication status: approved

Merchant-branded ordering shows menu selection, item configuration, scheduled delivery context, buyer details, and the order total before checkout.

Demo screenshot — presentation-cleaned identity data. Nonproduction demonstration data only; no live merchant, customer, staff, payment, or order information is represented.

Merchant surface

Order Control keeps state, responsibility, and next action together.

The merchant reviews the supported order path, resolves visible conditions, and decides when operational work may advance. Merchant decisions remain separate from kitchen work.

Order Control

Order workspace

Approved evidence
SaaSMX order workspace demo showing order details, operational state, handoff information, and history.
Asset evidence.product.order-controlPublication status: approved

The order workspace keeps order identity, payment and service state, dates, handoff information, KDS transition, and operational history together.

Demo screenshot — presentation-cleaned identity data. Nonproduction demonstration data only; no live merchant, customer, staff, payment, or order information is represented.

Kitchen surface

The kitchen receives accepted work, not merchant administration.

Kitchen responsibility begins after merchant review. The kitchen-focused surface keeps preparation and readiness visible without exposing account, billing, or business settings.

Kitchen preparation

Kitchen KDS

Approved evidence
SaaSMX Kitchen KDS demo showing kitchen tickets, preparation states, timing, and handoff lanes.
Asset evidence.product.kitchenPublication status: approved

Kitchen KDS shows accepted work, preparation state, handoff lanes, timing context, and stage progression without exposing merchant administration.

Demo screenshot — presentation-cleaned identity data. Nonproduction demonstration data only; no live merchant, customer, staff, payment, or order information is represented.

Fulfillment handoffs

Pickup and delivery remain distinct completion paths.

Both begin with accepted, prepared work. Responsibility changes at the final handoff, and delivery-provider controls remain outside the SaaSMX product boundary.

Pickup

Merchant

  1. Kitchen marks the accepted order ready
  2. Merchant controls the buyer handoff
  3. Merchant records the supported completion outcome

Pickup procedures remain subject to the merchant's approved operating policy.

Delivery

Merchant and approved provider

  1. Kitchen marks the accepted order ready
  2. Merchant transfers the supported handoff
  3. The provider outcome returns to the order path

Provider availability, pricing, courier conduct, and provider rules remain outside SaaSMX control.

Attention states

An order that cannot advance remains visible.

A visible condition, responsible role, and next action keep review work separate from normal preparation and completion.

Completion

Completion closes active operational work.

The supported pickup or delivery outcome becomes the final workflow state. SaaSMX does not present that state as an accounting ledger, tax record, or POS replacement.

Retained in the workflow

Operational completion state

The order no longer remains in an active preparation or handoff queue.

Not represented

Financial or statutory record

Accounting, tax, provider, and POS records remain governed by their own systems.

System boundary

The SaaSMX product boundary stays explicit

SaaSMX controls the supported order workflow while connected providers and merchant systems retain their own responsibilities.

Inside the boundary

SaaSMX operational surfaces

  • Merchant-branded ordering entry
  • Connected order state and merchant review
  • Kitchen preparation handoff
  • Supported pickup or delivery workflow
  • Operational completion state

Connected or separate

Separate or qualified systems

  • Complete POS replacement
  • Stripe settlement, disputes, and account controls
  • Delivery-provider pricing and courier operations
  • Automatic support for every existing order source
  • Accounting, tax, and legal records

See the sequence

Follow how responsibility moves from buyer to completion.

The How It Works page explains the controlled order sequence step by step.

View How It Works