๐Ÿ“Walid Kitchen WORKFLOWS

Workflow visualization

Every workflow behind Walid Kitchen at a glance โ€” from the moment a customer walks in or orders online, to the dish leaving the kitchen. Review each flow, then click into the mocks.

User action System state Success In progress Alert / attention Terminal

1 ยท Roles & screens

Three roles, three surfaces, one shared order store. Every screen talks to the same data, so a cashier and the kitchen never see different orders.

๐Ÿ”Sign inPick a role
โ†’
๐ŸงพCashierOrder entry ยท payments
โ†’
๐ŸณKitchenKitchen display
โ†’
๐Ÿ“ŠAdminReports ยท stock ยท menu
๐Ÿ—„๏ธShared order storelocalStorage โ†’ cloud
โ†
all roles read / write the same orders

2 ยท Order lifecycle

The happy path end-to-end. A fast-food order should go from customer to served in well under 15 minutes.

๐Ÿ†•Start orderTakeaway ยท Dine-in ยท Delivery
โ†’
๐ŸงบAdd items & modifierstap product ยท no onions?
โ†’
๐ŸณSend to kitchenappears on KDS instantly
โ†’
๐Ÿ’ฐPaymentCash ยท M-Pesa ยท Card
โ†’
โณKitchen preparesNEW โ†’ PREPARING
โ†’
๐Ÿ›Ž๏ธReadycall the number
โ†’
๐Ÿฝ๏ธServeticket cleared ยท stock drops

3 ยท Kitchen display status flow

The KDS replaces paper tickets. Kitchen staff "bump" each order forward; overdue orders flash so nothing burns.

๐Ÿ†•NEWtap Accept
โ†’
โณPREPARINGtap Mark Ready
โ†’
๐Ÿ›Ž๏ธREADYtap Serve
โ†’
โœ…SERVEDdone for the day
โฐOrder idle 3+ mincard flashes red
โ†’
cooks see it and prioritize โ€” no paper, no shouting

4 ยท Payment flows

Three ways to pay, each ending with a PAID order and a receipt. M-Pesa is the most common in Kenya, so it gets a dedicated STK push flow.

๐Ÿ’ต Cash
1Enter amount tendered
โ†“
2Change calculated
โ†“
3Complete โ†’ PAID
โ†“
4Print / send receipt
๐Ÿ“ฑ M-Pesa
1Enter phone number
โ†“
2STK Push sent
โ†“
3Customer enters PIN
โ†“
4Confirmation โ†’ PAID
โ†“
5Receipt generated
๐Ÿ’ณ Card
1Insert / tap card
โ†“
2Terminal approves
โ†“
3Approved โ†’ PAID
โ†“
4Receipt generated

5 ยท Offline-first sync (works without internet)

The killer requirement for a Kenyan restaurant: it must keep selling even when the network drops. Every write is saved locally first, then pushed when internet returns.

โœ๏ธSale / status changewritten locally, always
โ†’
๐Ÿ“ฅQueued "pending-sync"offline badge shows count
โ†’
๐Ÿ“ถInternet returnsBackground Sync wakes up
โ†’
๐Ÿ”„Push queue + pull updatesorders up ยท menu changes down
โ†’
conflicts resolve by newest timestamp (UUID + updated_at)
โ†’
โœ…Cloud in sync
โš ๏ธOffline?No blocked screens โ€” only a badge
โ†’
try the sync badge in the top bar of any screen to simulate it

6 ยท Inventory via recipes

Menu items are linked to ingredients through recipes, so stock depletes automatically with every sale.

๐Ÿ”Sale completese.g. Chicken Burger
โ†’
๐Ÿ“–Recipe lookup1 bun ยท 1 fillet ยท 1 cheese ยท sauce
โ†’
โž–Decrement ingredientsstock recorded locally
โ†’
๐Ÿ”ปBelow reorder level?checked per ingredient
โ†’
๐Ÿ“ขLow-stock alertto admin dashboard

7 ยท Website โ†’ POS integration

Online orders land in the exact same order store as counter orders, so the kitchen sees everything on one display.

๐ŸŒCustomer orders onlinepickup or delivery
โ†’
๐Ÿ—„๏ธOrder enters shared storesame queue as the counter
โ†’
๐ŸณAppears on kitchen displaynew-order sound + toast
โ†’
๐Ÿ’ฐPay at pickupM-Pesa ยท cash ยท card
โ†’
๐Ÿฝ๏ธServed โ€” customer tracks live status