Cafe POS & KDS · F&B / POS System · 2025
Omnichannel Cafe POS & KDS
Synchronizing counter ordering, KDS ticket queues, and digital pagers.
- #F&BRetail
- #BPMN2.0
- #StateDiagram
- #APISpec
ExpandDuring morning rush hours, specialty cafes lose minutes and margin to manual bank-transfer screenshots, misread cup stickers, and verbal status checks between cashiers and baristas. I specified an end-to-end POS & Kitchen Display System (KDS) that unifies ordering, VietQR payment verification, prep queues, and recipe inventory.
View CV- Role
- Business Analyst
- Team size
- BA Case Study
- Timeline
- 2025
- Deliverables
- URD/SRS, BPMN 2.0, UML Sequence & State Diagrams, POS/KDS Wireframes
Context
When observing cafe counter operations, two failure modes stood out: first, cashiers had to visually inspect customers' phones to confirm bank transfers before pushing orders to the bar; second, when a customer modified an order ('less ice, oat milk'), verbal handoffs often got lost during peak noise.
Business Goals & Objectives
- Automate dynamic VietQR payment verification via webhook so paid orders route to KDS in under 2 seconds.
- Enforce a single source of truth for order states across Cashier POS, Barista KDS, and Customer Pickup Display.
- Automate raw ingredient inventory deduction using a modifier-aware Recipe Bill of Materials (BOM).
My Role & BA Responsibilities
- Authored the Business & System Requirements Specification (BRD / SRS).
- Modeled BPMN 2.0 swimlane processes, UML Sequence diagrams, and the 7-state Order State Machine.
- Designed touch-first POS and Barista KDS wireframes and wrote Given/When/Then Acceptance Criteria.
Approach
“A barista with wet hands during a 9 AM rush cannot click a dropdown menu: every KDS action had to be a single large tap target with unambiguous state feedback.”
ExpandProcess & Workflows
From dynamic QR payment to KDS ticket in under two seconds.
We modeled the order lifecycle using BPMN 2.0 swimlanes across four actors: Customer, Cashier POS, Payment Gateway, and Barista KDS.
When the cashier selects 'VietQR', the system generates a dynamic QR payload containing the exact order amount and unique reference code. As soon as the bank webhook fires, the order transitions to `PAID_QUEUED` and materializes on the Barista KDS without manual cashier intervention.
BPMN 2.0 Swimlanes & Integration Flows
Both counter-assisted orders and table QR self-orders converge into the same normalized KDS queue, prioritized by payment timestamp and station type.
Expand diagram
Expand diagramIdempotency, Timeouts & Void Compensations
The specification defines exact behavior for edge cases: duplicate webhook retries (idempotency key check), customer switching from QR to Cash mid-checkout, and voiding an order after the barista has already started preparation (triggering waste logging).
Data Model & Business Rules
State machine rigor meets recipe-level inventory math.
Instead of treating modifiers as free-text notes, every modifier ('Oat Milk', '+1 Espresso Shot', 'Size L') is modeled as a structured entity linked to raw inventory SKUs.
State Machine & Recipe BOM Architecture
- 7-state Order State Machine with strict guard conditions preventing unpaid orders from entering `IN_PREP`.
- Modifier-aware Recipe BOM: substituting Oat Milk automatically skips Fresh Milk deduction and deducts 200ml Oat Milk.
- Idempotent `PaymentTransaction` log keyed by gateway reference ID to prevent double ticket printing.
- SLA timer attributes (`queuedAt`, `prepStartedAt`, `readyAt`) powering real-time barista performance analytics.
Expand ERD diagramKey Business Rules (BR)
- BR-01 (Webhook Idempotency): Duplicate payment webhooks with the same `gatewayTxnId` must return HTTP 200 without creating a second KDS ticket.
- BR-02 (SLA Color Escalation): KDS tickets transition from Neutral (0–3m) to Amber (3–5m) and Red (>5m elapsed since `PAID_QUEUED`).
- BR-03 (Waste vs. Restock on Void): Voiding an order in `PAID_QUEUED` restores allocated stock; voiding in `IN_PREP` logs ingredients as 'Bar Waste'.
Wireframes & Acceptance Criteria
Built for speed, glanceability, and zero missed modifiers.
The POS interface places category tabs, item cards, and modifier pills on a single non-scrolling viewport so cashiers can punch in a customized 3-drink order in under 15 seconds.
Sample Acceptance Criteria (Given / When / Then)
- GIVEN an order is in 'PENDING_PAYMENT' with a dynamic VietQR displayed, WHEN the payment webhook confirms settlement, THEN the POS modal auto-closes, receipt prints, and the ticket appears on Barista KDS within 2 seconds.
- GIVEN a ticket has been in 'PAID_QUEUED' on the KDS for 3 minutes, WHEN the SLA timer ticks past 180 seconds, THEN the ticket header border turns Amber and sorts to the top of the active queue.
- GIVEN a barista taps 'Mark Ready' on the last item of Order #104, WHEN the state updates to 'READY_FOR_PICKUP', THEN #104 moves to the 'Ready' column on the customer pickup screen and triggers an audio chime.
Expand
Expand
Expand
Expand