PRD: QR Self-order
| Module | Sale (CORE-07) | PRD ID | PRD-SLF-001 |
| Status | Planned | Owner | Hải Cao · Khoa Nguyễn · Phát Nguyễn |
| Date | 2026-06-11 | Version | v0.1 (draft) |
| Packages | @nx/sale · @nx/commerce · apps/sale-renderer · guest web | URD | SLF |
| Epic | BANA-1325 | Window | spec/design July · build + pilot August (By Month) |
TL;DR
A guest scans the QR on their table and orders from their own phone - no app. The menu they see is the merchant's policy-based Menu (right menu for the time/channel). The order lands in the POS tied to that table, staff confirm, and it flows to the kitchen like any staff order.
1. Context & Problem
Peak-hour table service bottlenecks on waiters taking orders. The Menu/MenuPolicy backend is already being built (menu entities, policy-based serving); what's missing is the guest-facing surface and the POS side that receives, confirms and routes guest orders. No guest ordering exists today.
2. Goals & Non-Goals
Goals - table QR → phone menu, no app (URD-SLF-001) · policy-based menu (002) · guest cart + submit per table (003) · POS receive + confirm/reject (004) · confirmed order → kitchen (005) · status updates (006) · sold-out hidden (007).
Non-Goals - online payment in v1 (guest pays at counter/table as usual) · loyalty integration · offline.
3. Success Metrics
| Metric | Target |
|---|---|
| Pilot venues live | 1-2 real F&B venues (August) |
| Guest order → kitchen | Flows end-to-end with staff confirmation |
4. Personas & Use Cases
Guest (no app, any phone browser) · Waiter (confirms/rejects, keeps control) · Kitchen (receives tickets identically).
5. User Stories
- As a guest, I scan the table QR, browse the menu, order 2 dishes - and see when they're confirmed.
- As a waiter, guest orders appear on my POS under the right table; I confirm with one tap.
6. Functional Requirements
Delivers URD SLF URD-SLF-001…008 (Musts 001-005).
7. Non-Functional Requirements
- Guest page loads fast on weak phone connections; QR token is per-table and non-guessable; sessions expire.
8. UX & Flows
- Scan QR → menu (merchant branding, policy-selected) → cart → submit.
- POS: badge on the table + pending list → confirm/reject → kitchen ticket created.
- Guest sees status (submitted → confirmed → served).
9. Data & Domain
- Consumes Menu / MenuPolicy / get-active-menu (being built under this epic - BANA-902…907).
- New: per-table QR session/token; guest order intake tied to allocation (table).
10. Dependencies & Assumptions
| Dependency | Why |
|---|---|
| Menu backend (902-907) | The menu the guest sees |
| Table flow stability (June work) | Orders attach to tables |
| Design (July) | Guest UI + POS confirmation UX |
11. Risks & Open Questions
- Abuse/garbage orders → staff confirmation step is the guard in v1.
- Multi-guest same table simultaneously - merge behaviour to define.
12. Release Plan & Launch Criteria
July: business spec + design + menu backend ready. August: build + pilot 1-2 venues. Launch: AC-SLF-01 passes at a pilot venue.
13. FAQ
- Does the guest pay online? Not in v1 - ordering only; payment stays with staff.
References
URD SLF · Phase 2 - By Month · Epic BANA-1325