Voucher / mã giảm giá theo gói trên Studio

Voucher / mã giảm giá theo gói trên Studio — dành cho chủ CLB / quản lý vận hành trên DANAVA Studio. Bài thuộc cụm công nghệ & tích hợp: nắm đúng khả năng sản phẩm, gắn SOP quầy, tránh hứa tính năng chưa có.

Liên kết: POS quầy · tự mua gói trên app · activity log · DANAVA Studio.

Coupon theo gói khác voucher loyalty thế nào

Coupon (mã khuyến mãi) trên Studio là chiến dịch có mã, ngân sách, giới hạn lượt — giảm tiền hoặc tặng buổi/ngày khi mua gói. Voucher loyalty (đổi điểm) là luồng khác: quy đổi điểm tích lũy thành quyền lợi, không thay thế coupon chiến dịch.

Chủ CLB hay nhầm vì cùng chữ 'voucher' trên thị trường. Trong vận hành Studio: bài này nói coupon `/promotions` + ô mã ở Sell/POS/online — không mô tả chương trình điểm thưởng loyalty nếu CLB chưa bật.

Một coupon = một chiến dịch (`coupons.name`). Chưa hỗ trợ nhiều mã cùng lúc trên một đơn theo kiểu 'stack tùy ý' — quy tắc cộng dồn phải đọc từng chiến dịch và SOP nội bộ.

package_ids: khi nào mã chỉ áp một số gói

`coupons.package_ids` (JSON): NULL hoặc mảng rỗng = áp mọi gói CLB. Có id gói = chỉ các gói đó — ví dụ mã 'YOGA-TRIAL' chỉ cho gói thử, không dùng cho PT 10 buổi.

Validate bắt buộc kèm `package_id`: Sell/POS gọi `GET clubs/{club}/coupons/validate?code=&amount=&package_id=`. Mua online qua `public/gym/{slug}/coupon-check`. Thiếu gói khi mã đã chỉ định → từ chối (`Coupon::appliesToPackage`).

Khi tạo mã: chỉ chọn gói thuộc CLB hiện tại — không gắn id gói phòng khác. Train lễ tân: đổi gói trên màn bán = phải validate lại mã.

Quy tắc giảm giá và tặng buổi/ngày

Giảm tiền: áp sau giảm giá 1+2 (nếu có), trước giảm trừ/phụ thu. Server tính lại — không tin số client gửi.

Mã tặng buổi/ngày (`reward_kind=sessions|days`): không giảm tiền, cộng thẳng vào `remaining_sessions`/`end_date`. Phần trăm tính theo tổng buổi/ngày của gói, làm tròn lên.

Comp/tặng tay (is_comp) không dùng chung coupon trừ khi SOP cho phép — tránh lẫn marketing và nội bộ.

Stacking và một mã trên một đơn

Mặc định vận hành an toàn: một mã coupon trên một lần bán gói. Không khuyến khích lễ tân thử 'mã A xong mã B' nếu hệ thống không hỗ trợ.

Giảm giá quầy (discount 1/2) và coupon là các lớp khác nhau — thứ tự đã cố định trên server. Owner set trần giảm quầy riêng với chiến dịch coupon.

Khi chạy ads có mã: in bảng 'gói nào + mã nào' tại quầy — giảm tranh cãi cuối tuần.

Audit: redemption, hủy đơn và báo cáo

Khi bán thành công: lưu `coupon_id/coupon_code/coupon_discount` trên subscription + `coupon_redemptions` — tăng `used_count`/`budget_used`.

Hủy hoá đơn đã áp mã → hoàn tác lượt dùng (không để mã 'chết' oan). QL rà activity log khi số lượt lệch với cảm nhận marketing.

Báo cáo hiệu quả chiến dịch đọc snapshot trên subscription theo `start_date` gói — đối chiếu với ngân sách coupon, không chỉ doanh thu tổng.

SOP quầy: validate trước, không hứa miệng

Lễ tân gõ mã → chờ validate OK → mới thu tiền. Khách đổi gói giữa chừng → validate lại.

Mã hết hạn/hết lượt/hết ngân sách: script từ chối lịch sự + đề xuất gói/giá chuẩn — không sửa tay giá âm thầm.

Online và quầy dùng cùng rule package scope — tránh 'web được, quầy không'.

Checklist owner trước chiến dịch

Đặt tên chiến dịch rõ, chọn gói đích, ngày bắt đầu/kết thúc, trần lượt dùng và ngân sách nếu có.

Test 1 đơn quầy + 1 đơn online (nếu bán app) với đúng gói và sai gói.

Thông báo lễ tân ngày hiệu lực; dán bảng mã–gói tại quầy.

Tình huống	package_ids	Việc làm	Không làm
Mã toàn CLB	NULL/rỗng	Validate có package_id	Giả định mọi gói OK
Mã chỉ gói thử	Có id gói	Chỉ bán đúng SKU	Áp sang PT
Hủy đơn có mã	—	Kiểm hoàn lượt	Xóa log tay
Nhầm loyalty	—	Dùng coupon promotions	Đổi điểm thay mã

In bảng 'mã ↔ gói' trước mỗi chiến dịch ads — giảm tranh cãi quầy.

Sau Tết: rà coupon hết hạn, tắt mã cũ trên POS để lễ tân không gõ nhầm.

Pre-sale founding: mã chỉ gói founding + giới hạn lượt — tránh phát tán MXH vượt ngân sách.

Đối chiếu used_count cuối tuần với activity log khi nghi staff test mã.

Không dùng coupon thay comp nội bộ — comp có lý do và audit riêng.

Khi đổi bảng giá gói: rà mã % có còn hợp lý không.

In bảng 'mã ↔ gói' trước mỗi chiến dịch ads — giảm tranh cãi quầy.

Sau Tết: rà coupon hết hạn, tắt mã cũ trên POS để lễ tân không gõ nhầm.

Pre-sale founding: mã chỉ gói founding + giới hạn lượt — tránh phát tán MXH vượt ngân sách.

Đối chiếu used_count cuối tuần với activity log khi nghi staff test mã.

Không dùng coupon thay comp nội bộ — comp có lý do và audit riêng.

Khi đổi bảng giá gói: rà mã % có còn hợp lý không.

In bảng 'mã ↔ gói' trước mỗi chiến dịch ads — giảm tranh cãi quầy.

Sau Tết: rà coupon hết hạn, tắt mã cũ trên POS để lễ tân không gõ nhầm.

Pre-sale founding: mã chỉ gói founding + giới hạn lượt — tránh phát tán MXH vượt ngân sách.

Đối chiếu used_count cuối tuần với activity log khi nghi staff test mã.

Không dùng coupon thay comp nội bộ — comp có lý do và audit riêng.

Khi đổi bảng giá gói: rà mã % có còn hợp lý không.

In bảng 'mã ↔ gói' trước mỗi chiến dịch ads — giảm tranh cãi quầy.

Sau Tết: rà coupon hết hạn, tắt mã cũ trên POS để lễ tân không gõ nhầm.

Pre-sale founding: mã chỉ gói founding + giới hạn lượt — tránh phát tán MXH vượt ngân sách.

Đối chiếu used_count cuối tuần với activity log khi nghi staff test mã.

Không dùng coupon thay comp nội bộ — comp có lý do và audit riêng.

Khi đổi bảng giá gói: rà mã % có còn hợp lý không.

In bảng 'mã ↔ gói' trước mỗi chiến dịch ads — giảm tranh cãi quầy.

Sau Tết: rà coupon hết hạn, tắt mã cũ trên POS để lễ tân không gõ nhầm.

Pre-sale founding: mã chỉ gói founding + giới hạn lượt — tránh phát tán MXH vượt ngân sách.

Đối chiếu used_count cuối tuần với activity log khi nghi staff test mã.

Không dùng coupon thay comp nội bộ — comp có lý do và audit riêng.

Khi đổi bảng giá gói: rà mã % có còn hợp lý không.

In bảng 'mã ↔ gói' trước mỗi chiến dịch ads — giảm tranh cãi quầy.

Sau Tết: rà coupon hết hạn, tắt mã cũ trên POS để lễ tân không gõ nhầm.

Pre-sale founding: mã chỉ gói founding + giới hạn lượt — tránh phát tán MXH vượt ngân sách.

Đối chiếu used_count cuối tuần với activity log khi nghi staff test mã.

Không dùng coupon thay comp nội bộ — comp có lý do và audit riêng.

Khi đổi bảng giá gói: rà mã % có còn hợp lý không.

In bảng 'mã ↔ gói' trước mỗi chiến dịch ads — giảm tranh cãi quầy.

Sau Tết: rà coupon hết hạn, tắt mã cũ trên POS để lễ tân không gõ nhầm.

Pre-sale founding: mã chỉ gói founding + giới hạn lượt — tránh phát tán MXH vượt ngân sách.

Đối chiếu used_count cuối tuần với activity log khi nghi staff test mã.

Không dùng coupon thay comp nội bộ — comp có lý do và audit riêng.

Khi đổi bảng giá gói: rà mã % có còn hợp lý không.

In bảng 'mã ↔ gói' trước mỗi chiến dịch ads — giảm tranh cãi quầy.

Sau Tết: rà coupon hết hạn, tắt mã cũ trên POS để lễ tân không gõ nhầm.

Pre-sale founding: mã chỉ gói founding + giới hạn lượt — tránh phát tán MXH vượt ngân sách.

Đối chiếu used_count cuối tuần với activity log khi nghi staff test mã.

Không dùng coupon thay comp nội bộ — comp có lý do và audit riêng.

Khi đổi bảng giá gói: rà mã % có còn hợp lý không.

In bảng 'mã ↔ gói' trước mỗi chiến dịch ads — giảm tranh cãi quầy.

Sau Tết: rà coupon hết hạn, tắt mã cũ trên POS để lễ tân không gõ nhầm.

Ghi chú triển khai 14 ngày — Voucher / mã giảm giá theo gói trên Studio

Ngày 1–3: đọc SOP liên quan và phân công owner. Ngày 4–7: cấu hình/thử trên Studio với dữ liệu thật hẹp. Ngày 8–10: train lễ tân 30–45 phút + viết FAQ quầy 5 câu. Ngày 11–14: đo một chỉ số (tỷ lệ redemption coupon, lệch tồn retail, thời gian check-in, % gia hạn app, số file Excel chuỗi đúng hạn…) và chỉnh SOP.

Không mở rộng sang chi nhánh 2 trước khi chi nhánh 1 tuân thủ ổn định hai tuần. Mọi thay đổi coupon, giá online hoặc modality check-in ghi ngày hiệu lực trên sổ vận hành.

Kỷ luật dữ liệu & không hứa ngoài sản phẩm

Bài voucher-giam-gia-theo-goi-tren-studio chỉ mô tả việc chủ CLB làm được với cấu hình và báo cáo hiện có. Không suy đoán số liệu khách hàng DANAVA. Không cam kết SLA nhà mạng/Zalo/PayOS/thiết bị. Khi nghi ngờ tính năng, xác minh trên môi trường thật của CLB hoặc hỏi hỗ trợ — không dạy lễ tân thao tác 'lách' làm vỡ đối soát.

Đọc tuần tự cụm F batch 15–16: kế toán MISA kỳ vọng → Hikvision → CRM lead → PT appointment → waitlist → coupon theo gói → tồn kho POS → so sánh check-in → tự mua app → báo cáo chuỗi. Mỗi mắt xích yếu đều có thể làm mất tiền hoặc mất uy tín boutique.

Câu hỏi thường gặp

Coupon và voucher loyalty khác gì?

Coupon là mã chiến dịch giảm/tặng khi mua gói. Voucher loyalty đổi điểm — luồng và màn hình khác; không thay nhau.

Một đơn dùng hai mã coupon được không?

Vận hành mặc định một mã/đơn. Không stack tùy ý trừ khi sản phẩm/SOP nói rõ.

Mã chỉ gói A mà khách mua gói B?

Validate từ chối. Đổi gói hoặc mã khác — không override miệng.

Online có cùng rule package_ids?

Có — coupon-check và settle đều truyền package_id.

Hủy gói có trả lượt mã không?

Hủy hoá đơn đã áp mã → hoàn tác redemption theo logic hệ thống.

Ai được tạo/sửa coupon?

Owner/manager theo phân quyền; lễ tân thường chỉ nhập mã khi bán.

Tìm hiểu thêm: DANAVA Studio · Giải pháp Wellness · báo cáo doanh thu.

Lưu ý: Nội dung giáo dục cho chủ CLB / quản lý; mô tả quy trình vận hành quanh tính năng DANAVA Studio đã có. Không cấu thành tư vấn pháp lý, bảo mật chứng nhận hay cam kết SLA nhà cung cấp thanh toán/tin nhắn. Số liệu ví dụ là khung quản trị.