Complete feature map

One operational chain, designed from table to stock room.

Explore how WizyFNB combines touch-first service, local durability, menu structure, inventory control and secure workspace context—plus the planned MCP layer for approved AI operations.

POS

Touch + local-first

Kitchen

Station fulfillment

Inventory

Items + components

MCP

Planned + permissioned

The operating spine

A check travels through service without losing its identity.

WizyFNB treats the table check as one continuous operational record. Staff do not recreate the same order context for the floor, kitchen and cashier.

Choose a table

Start from the live floor. The route resolves a real workspace resource before staff can act.

Build the check

Add variants, modifiers and kitchen notes through touch controls backed by local durable state.

Send by station

Kitchen items become tickets and move through sent, preparing, ready and served states.

Settle and release

Checkout preserves the check, records tender intent and releases the table through a recoverable flow.

Available

Local-first POS

Fast feedback without pretending the network is perfect.

The POS separates immediate device interaction from backend reconciliation. That keeps staff moving while preserving an honest distinction between local, queued, synced and failed work.

Built for iPad-style service

Large table and menu targets
Minimal typing during service
Persistent table and check context
Square, dense POS visual language

Device-first acceptance

Menu taps, quantity changes, notes and checkout intent update local state before related REST work begins.

Durable outbox

Kitchen sends and payment intents survive reloads through transactional IndexedDB records owned by the active check.

Foreground reconcile

A shared POS scheduler converges active orders and tables without giving every screen its own polling loop.

Honest sync states

Staff can distinguish synced, syncing, waiting, offline and needs-review states instead of trusting a silent spinner.

Available

Inventory management

A practical stock room for restaurant operators.

Review the current stock picture, organize reference data and record movement without reconstructing the inventory overview from a maze of disconnected screens.

Complete item records

Manage ingredients, supplies and retail products with SKU, base unit, category, vendor, location, cost and expiry.

Units and categories

Create and maintain units, nested groups and operator-controlled category ordering without flattening stock structure.

Movement history

Record purchase receipts, manual adjustments and waste, then review the ledger for each inventory item.

Operational alerts

Surface low stock, out of stock and approaching expiry, with quick filters that take operators to affected items.

Vendor details

Keep vendor code, address, tax number, contact and ordering notes next to the items they supply.

Menu component mapping

Link each sellable menu variant to inventory components and quantities so depletion follows what was actually ordered.

The differentiator

Inventory can follow the exact menu variant sold.

Component mapping keeps a small, medium and large variant from sharing one vague recipe when their ingredient quantities differ.

Menu variant

Named, priced and sellable

Component recipe

Item + quantity + unit

Stock movement

Depleted with order flow

Available

Menu management

Sellable variants stay distinct from catalog to checkout.

Menu structure is preserved all the way through order snapshots. Two sizes do not collapse into one line simply because they belong to the same item.

Categories and items

Organize the menu for fast staff discovery while keeping descriptions and kitchen station intent under owner control.

Named variants

Small, medium, large or any restaurant-specific format remains a distinct sellable variant with its own identity.

Variant-level prices

Every variant can carry its own active one-time price, default state, availability and visibility.

History-safe controls

Hide or deactivate menu records instead of erasing the catalog references preserved on historical order lines.

Available

Checkout and recovery

Payment state designed for the awkward moments.

The happy path is easy. WizyFNB also plans for reloads, delayed terminal events, multiple tabs and ambiguous network outcomes so a cashier does not accidentally tender the same check twice.

Tender safety model

Cash + configured card readers

Checkout hydrates from the local bill before waiting for the backend.
Cash acceptance persists a durable settlement action before releasing the table.
Card Terminal recovery matches exact persisted sale and payment identities.
Ambiguous card outcomes block a second tender until staff reviews the existing attempt.
Void and cancel require an operational reason and preserve audit context.

Planned

Model Context Protocol

AI access shaped like restaurant tools—not an open API tunnel.

The planned remote MCP server gives approved AI clients a curated, audited toolset. Every grant is bound to one Wizy user, client and workspace.

Availability note

Production MCP depends on the planned OAuth, delegated authorization and audit contracts. This page describes the approved roadmap, not a generally available endpoint.

Step 1

Read restaurant context

Menu, tables, active orders and inventory

Step 2

Prepare catalog and stock work

Create menu records, inventory items and movement previews

Step 3

Prepare dine-in kitchen orders

Resolve live table, menu, prices and availability

Step 4

Commit through policy

Workspace scope, human confirmation and idempotency

Available

Wizy workspace foundation

Restaurant context follows the authenticated location.

The shell reads live platform context instead of inventing a parallel restaurant identity model. That keeps product modules, access and staff ownership aligned.

Workspace access

Authentication, location membership and role context come from the shared Wizy account rather than a separate POS login island.

Module-aware product

Enabled modules, package rules and workspace settings determine which operational surfaces are available.

Location context

Locale, language, timezone and currency follow the active restaurant workspace.

People in context

Owners manage staff and customers while POS orders retain the staff identity responsible for the check.

Product clarity

What is available, planned and intentionally deferred.

The product stays credible by separating live capabilities from roadmap work and from service channels that are not in the current phase.

Touch-first dine-in POS

Available

Table selection, order entry, kitchen send and checkout

Menu and variant management

Available

Categories, items, named variants, prices and availability

Inventory management

Available

Items, units, categories, vendors, movement and alerts

Cash and card-terminal checkout

Available

Durable intent, reader discovery and recovery

Remote MCP server

Planned

OAuth-gated AI tools for one authorized workspace

Takeaway, delivery and QR ordering

Deferred

Outside the current dine-in product phase

Your service flow, mapped

See how WizyFNB fits your floor, menu and stock room.

Bring the way your team takes orders today. We will map the first rollout around the workflows that matter during service.

Talk to WizyFNB Sign in