The Workflow

FolioFlow explores an end-to-end restaurant-to-room-billing workflow: a ticket is sent from POS to a kitchen queue, a room-service charge appears on an occupied guest's folio, mock payments change the outstanding balance, and a shift report distinguishes billed from collected amounts. It is an independent portfolio experiment, not a customer deployment or a replica of a third-party product. The cover is an original workflow diagram; it does not represent a customer system.

Try the Interactive Demo

Open FolioFlow →

Choose an item in Restaurant POS and charge an in-house room or a table. Serve the ticket in Kitchen & orders. A room ticket posts to the guest folio; a table ticket can record a mock payment after service. In Room folios, record a mock payment before checkout, then reset the room after housekeeping. Explore stock depletion, sample reservations and recalculated reports. Refresh or press Reset demo to restore the original state.

Scope and Safeguards

Six fictional rooms, sample guest names, ingredient units and illustrative AUD values are seeded in browser memory. The model validates dates, overlapping stays, room readiness, ticket quantities, stock availability, service status and folio balance. Pure-model tests exercise room-to-folio and table-payment flows. No payment gateway, bank details, tax calculation, account, backend, database, supplier integration, AI model or persistent state exists. Do not enter real guest information.

How It Differs from StayOS

StayOS emphasises availability, reservations, room readiness and a compact restaurant POS. FolioFlow focuses on the linked operational ledger: ticket fulfilment, mock settlement, ingredient consumption and the distinction between charges, outstanding amounts and receipts. Neither prototype is production hospitality software. Real deployments require permissions, audit logs, reconciled accounting and taxes, security and privacy controls, payment integration and operational testing.