🤖 IAN · AI Kiosk by iPOSnow
Ý tưởng — chưa triển khai code thật

IAN đi theo khách qua điện thoại của chính họ, ngay tại bàn — không chỉ đứng ở quầy. Mỗi bàn có 1 phiên IAN riêng, không chia sẻ ký ức hội thoại giữa các bàn/lượt khách khác nhau.

Cách khách bắt đầu 1 phiên

Khách quét QR dán tại bàn ──▶ GET /table/{tableId} │ Có phiên còn hiệu lực cho bàn này? ──có──▶ Mở lại phiên cũ (tiếp tục hội thoại) │không ▼ Tạo phiên mới, lưu trong Cloudflare KV │ Redirect ──▶ /session/{token} (giao diện IAN thu gọn: chỉ chat + mặt nhỏ)

2 mô hình đã cân nhắc

Mô hình A — QR động từ kiosk (đã cập nhật 2 lần)

Kiosk hiển thị mã QR ngay trên màn hình trong 15 giây để khách quét tại chỗ — không in giấy, không cần màn hình phụ ở bàn, hết 15 giây mã tự biến mất. Mã gắn với bàn. Phiên IAN sau khi quét có hiệu lực cơ bản 20 phút; sắp hết hạn thì hỏi khách có cần thêm thời gian — cần thì gia hạn thêm 5–15 phút/lần, tối đa 3 lần (tổng tối đa ~65 phút); khách không phản hồi thì tự đóng phiên.

Lưu ý: 15 giây là hạn hiển thị/quét mã tại kiosk — khác với 20 phút+ là thời lượng phiên IAN sau khi đã quét thành công.

Mô hình B — QR tĩnh dán bàn (đề xuất tinh chỉnh)

QR in 1 lần, dán cố định tại bàn. Server tự tạo/mở lại phiên mỗi lần quét. Thời hạn phiên tự gia hạn theo hoạt động thay vì 1 mốc cứng, đóng sớm nếu nhận được sự kiện "đã thanh toán" từ POS.

Bảng so sánh

Tiêu chíMô hình A (QR động 15s + phiên 20 phút gia hạn có hỏi)Mô hình B (QR tĩnh, tự gia hạn)
Vận hành hàng ngàyKhông cần in — chỉ hiện trên màn hình kiosk sẵn có, nhưng vẫn cần đúng thời điểm xếp bàn để hiện mãThắng nhẹ — dán 1 lần, không cần đồng bộ đúng thời điểm
Xác thực đúng bànPhụ thuộc khách quét kịp trong 15 giây ngay tại kioskThắng — gắn theo vị trí vật lý tại bàn, không cần thao tác đúng lúc
Thời lượng dùng thực tế20 phút + tối đa 3 lần gia hạn (5–15 phút/lần) = trần ~65 phút, có hỏi khách trước khi hết hạn — không còn bị cắt đột ngộtKhông trần, tự gia hạn theo hoạt động, khách không bị hỏi gì. Thắng nhẹ — chênh lệch đã thu hẹp nhiều so với bản đầu.
Chi phí thiết bị/hạ tầngKhông cần in QR — chỉ hiện trên màn hình kiosk có sẵn, nhưng cần thêm logic sinh mã + đếm giờ 15s + logic hỏi-gia hạnChỉ 1 ảnh QR tĩnh in sẵn — đơn giản hơn về code, tốn công in ban đầu
Rủi ro bảo mậtThắng — mã chỉ hiện 15 giây, gần như không có cơ hội bị chụp lại rồi dùng sauQR tĩnh dán cả ngày có thể bị chụp gửi người không có mặt tại quán (rủi ro thấp, dữ liệu không nhạy cảm)
Gắn dữ liệu đặt bàn trướcTự nhiên hơn vì mã hiện ngay lúc xác nhận đặt bàn tại kioskVẫn làm được — server tra POS theo tableId lúc quét
Độ phức tạp codeCần thêm: sinh mã theo sự kiện xếp bàn, đếm ngược 15s, logic hỏi-gia hạn (đếm số lần, chờ phản hồi, timeout)Thắng — chỉ logic redirect đơn giản, không cần đồng bộ theo sự kiện thời gian thực

Kết luận

Sau khi sửa mô hình A từ "15 phút cứng" sang "20 phút + tối đa 3 lần gia hạn có hỏi khách, mã chỉ hiện 15 giây tại kiosk", vấn đề nghiêm trọng nhất trước đây (cắt ngang bữa ăn đột ngột) đã được khắc phục — 2 mô hình giờ khá cân bằng, khác nhau chủ yếu ở triết lý:

Mô hình A: chủ động hỏi khách, có trần thời gian rõ ràng (dễ dự đoán tải hệ thống), bảo mật tốt hơn (mã chỉ sống 15 giây), không cần in — nhưng làm phiền khách tối đa 3 lần/bữa và vẫn có khả năng đóng phiên nếu khách ăn quá ~65 phút mà không phản hồi kịp.

Mô hình B: hoàn toàn im lặng với khách (không bao giờ bị hỏi), không trần thời gian, vận hành phần code đơn giản hơn — nhưng cần in QR ban đầu và mã sống cả ngày nên rủi ro bị chụp lại cao hơn (dù vẫn ở mức thấp với dữ liệu không nhạy cảm). Ưu tiên khách không bị làm phiền → chọn B; ưu tiên kiểm soát/dự đoán được và bảo mật cao hơn → mô hình A bản đã sửa này hoàn toàn khả thi.

Trạng thái: ý tưởng, chưa code thật. Bản chi tiết dạng file: report.md trong thư mục dự án.