Cách làm hiện tại: ngay khi khách bấm "đổi quà", hệ thống lập tức lấy 1 mã thật từ nhà cung cấp và giữ riêng cho khách — dù khách có bao giờ quay lại xem mã hay không. Nếu khách không bao giờ xem, phần chi phí lấy mã đó coi như lãng phí.
Cách làm mới: ngay khi khách bấm "đổi quà", hệ thống chỉ ghi nhận "khách này đã có quyền nhận 1 phần quà loại X, chưa lấy mã" — giống như phát cho khách 1 tấm phiếu hẹn, chưa phải mã dùng thật. Chỉ khi khách thực sự mở phiếu ra xem (bấm "xem mã"), hệ thống mới đi lấy mã thật từ nhà cung cấp. Nếu khách không bao giờ mở phiếu, không có chi phí nào phát sinh.
Bấm nút bên dưới để xem khách hàng trải qua từng bước — từ lúc đổi quà tới lúc cầm mã đi cửa hàng.
Câu hỏi quan trọng nhất của mô hình này là: làm sao đảm bảo khi khách bấm "xem mã" luôn có mã sẵn sàng, trong khi lúc đổi quà chưa hề đụng tới mã thật? Câu trả lời nằm ở 2 cơ chế phối hợp với nhau: 1 cơ chế chặn nhẹ ngay lúc khách đổi quà, và 1 cơ chế kho tự động theo dõi để luôn nhập hàng kịp thời — không đợi tới lúc cạn mới biết.
Mỗi lần khách bấm đổi quà, hệ thống kiểm tra nhanh: số lượng khách đang "đã đổi, chưa lấy mã" cho loại quà này có còn nhỏ hơn số mã kho đang sẵn sàng không. Nếu còn — cho đổi. Nếu đã bằng hoặc vượt — chặn ngay, không cho đổi thêm, tránh phát sinh 1 quyền nhận quà mà kho không thể đáp ứng. Phép kiểm tra này rất nhẹ (chỉ so 2 con số), không cần hệ thống đi dò từng mã trong kho mỗi lần khách đổi quà.
Mỗi loại quà (vd voucher Highlands 50k) có thể được nhiều chương trình khác nhau cùng tặng — chương trình Vingroup, chương trình Techcombank... đều lấy chung từ 1 kho mã. Vì vậy hệ thống cần 1 nơi ghi nhận riêng: tổng nhu cầu đang chờ lấy mã của 1 loại quà, cộng dồn từ TẤT CẢ chương trình đang tặng quà đó. Mỗi lần có khách đổi quà (ở bất kỳ chương trình nào), con số nhu cầu này tăng lên ngay lập tức.
Định kỳ (vd mỗi 15 phút), hệ thống tự động quét lại: so nhu cầu đang chờ với số mã thực tế còn trong kho. Nếu số mã còn lại không đủ đáp ứng nhu cầu đang chờ, hệ thống chủ động cảnh báo cho đội vận hành biết cần nhập thêm bao nhiêu mã — trước khi kho thực sự cạn, không phải đợi tới lúc khách bấm xem mã mới phát hiện thiếu hàng.
| Ghi nhận | Ý nghĩa kinh doanh |
|---|---|
| Nhu cầu đang chờ (theo từng loại quà) | Có bao nhiêu khách đã đổi quà loại này nhưng chưa xem mã — cộng dồn từ mọi chương trình đang tặng loại quà đó. Tăng ngay khi có khách đổi quà, giảm khi khách xem mã hoặc huỷ đổi. |
| Số mã còn trong kho (theo từng loại quà) | Snapshot số mã thực tế còn sẵn sàng — được cập nhật định kỳ bởi hệ thống, dùng để tính cần nhập thêm bao nhiêu và để cảnh báo vận hành. |
| Ngưỡng an toàn (buffer) | Khoảng dư tối thiểu kho luôn phải giữ thêm, phòng trường hợp có nhiều khách cùng đổi quà dồn dập giữa 2 lần quét. Không phải cứ đủ đáp ứng nhu cầu hiện tại là dừng nhập — phải dư thêm 1 khoảng để có thời gian phản ứng trước lần quét kế tiếp. Con số cụ thể (cố định hay theo %) do đội vận hành cấu hình theo từng loại quà. |
| Số lượng cần nhập thêm | = (Nhu cầu đang chờ + Ngưỡng an toàn) − Số mã còn trong kho (nếu dương). Đây là con số đội vận hành cần theo dõi để chủ động nhập hàng trước khi khách hàng bị ảnh hưởng — nhập đủ để vừa đáp ứng nhu cầu hiện tại, vừa còn dư ra đúng bằng ngưỡng an toàn. |
Nếu vì lý do bất khả kháng (nhà cung cấp giao chậm, sự cố vận hành...) mà tới lúc khách bấm xem mã vẫn không đủ mã đáp ứng — hệ thống sẽ tự động hoàn lại điểm/lượt đã trừ cho khách ngay lập tức, không để khách tự phát hiện hoặc phải liên hệ hỗ trợ. Đây là lưới an toàn cuối cùng, chỉ nên xảy ra rất hiếm khi 2 cơ chế ở mục trên đã hoạt động đúng.
Khách hàng (hoặc đội chăm sóc khách hàng) có thể huỷ 1 lần đổi quà. Cách xử lý khác nhau tuỳ khách đã lấy mã hay chưa: nếu chưa lấy mã, huỷ ngay và hoàn điểm/lượt không cần đụng tới kho; nếu đã lấy mã nhưng cửa hàng chưa quét dùng, huỷ + trả mã về kho + hoàn điểm/lượt; nếu cửa hàng đã quét dùng rồi thì không thể huỷ tự động. Xem chi tiết thiết kế API tại trang riêng: Hủy đơn & Refund ↗.
OQ-1. Khi huỷ 1 lần đổi quà đã lấy mã (nhưng chưa dùng), với loại quà lấy mã theo kiểu gọi
trực tiếp nhà cung cấp — có bắt buộc phải báo huỷ ngược lại phía nhà cung cấp, hay chỉ cần cập nhật nội bộ và để
nhà cung cấp tự đối soát sau?
OQ-2. Khi số mã còn trong kho giảm đột ngột ngoài dự kiến (vd do sự cố vận hành) khiến
không còn đủ đáp ứng nhu cầu đang chờ — có cần hệ thống chủ động báo động ngay (thay vì chờ tới chu kỳ quét định
kỳ tiếp theo) không?
OQ-3. API hủy đơn có cần lưu lịch sử riêng (ai huỷ, lý do gì) tách khỏi log hoạt động
chung, để phục vụ đối soát tài chính sau này không?