Mã giảm giá theo gói trên Studio: cấu hình & SOP quầy

Mã giảm giá theo gói trên DANAVA Studio là công cụ chủ phòng tập boutique dùng để chạy khuyến mãi có kiểm soát — không phải “voucher điểm thưởng” và cũng không phải giảm giá miệng tại quầy. Bài viết này dành cho chủ CLB / quản lý / lễ tân trưởng cần cấu hình mã đúng gói, train ca bán hàng, và đối soát lượt dùng sau chiến dịch ads hoặc pre-sale.

Liên kết hữu ích: hội viên tự mua gói trên app · đồng bộ giá web–app–quầy · nhật ký hoạt động · bán gói · DANAVA Studio.

Coupon theo gói khác voucher điểm thưởng thế nào?

Trên thị trường, chủ CLB hay gọi chung “voucher”. Trong vận hành Studio cần tách hai luồng. Coupon là chiến dịch có mã, ngày hiệu lực, trần lượt dùng và ngân sách ưu đãi — giảm tiền hoặc tặng buổi/ngày khi bán gói. Voucher điểm thưởng (loyalty) là quy đổi điểm tích lũy thành quyền lợi trên màn phần thưởng, không thay chỗ coupon khi bạn chạy ads “nhập mã SUMMER20”.

Nếu lễ tân nhầm hai luồng, quầy sẽ tranh cãi với khách và báo cáo marketing sẽ lệch. Quy ước nội bộ nên viết rõ: mã chiến dịch đi vào ô “Mã khuyến mãi” khi bán gói; điểm thưởng đi luồng rewards. Báo cáo hiệu quả mã nằm ở nhóm báo cáo khuyến mãi theo chiến dịch, tính theo ngày gói bắt đầu hiệu lực, không phải ngày tạo bản ghi lung tung.

Một coupon tương ứng một chiến dịch có tên riêng. Studio chưa hỗ trợ chồng nhiều mã trên cùng một đơn theo kiểu “stack tùy ý”. Khi cần ưu đãi kép, thường phải thiết kế một mã duy nhất mang đúng mức giảm bạn muốn, hoặc dùng giảm giá quầy theo quyền hạn — có trần và audit riêng.

Giới hạn theo gói: khi nào mã chỉ bán đúng SKU?

Nhiều boutique yoga/pilates chạy mã chỉ cho gói thử hoặc founding member, không muốn mã lan sang PT 10 buổi. Trên Studio bạn gắn danh sách gói vào mã. Để trống hoặc không chọn = áp mọi gói đang bán của CLB. Có danh sách = chỉ các gói đó. Khi bán, hệ thống bắt buộc biết đang bán gói nào để quyết định mã có hợp lệ.

Ca quầy: khách đổi ý từ gói tháng sang gói buổi giữa chừng thì phải kiểm mã lại. Ca online: trang mua công khai và app dùng cùng quy tắc phạm vi gói — tránh tình trạng “web nhận mã, quầy từ chối” hoặc ngược lại. Khi tạo mã, chỉ chọn gói thuộc CLB đang làm việc; không gắn nhầm gói phòng khác nếu bạn quản lý nhiều pháp nhân.

Trước khi chạy ads Facebook/Zalo, in bảng một trang: mã nào ↔ gói nào ↔ ngày hết hạn ↔ trần lượt. Dán tại quầy và gửi group vận hành. Đây là bước rẻ nhất để giảm tranh cãi cuối tuần.

Giảm tiền hay tặng buổi/ngày — chọn đúng loại thưởng?

Giảm tiền: áp sau các lớp giảm giá quầy (nếu có), trước phụ thu. Máy chủ tính lại tổng phải thu — lễ tân không được “sửa tay” số tiền để khớp cảm giác. Phần trăm giảm tính trên phần còn lại đúng thứ tự quy định; nếu nghi lệch, đối chiếu hóa đơn và nhật ký hoạt động.

Mã tặng buổi hoặc tặng ngày không trừ tiền trên hóa đơn mà cộng thẳng vào số buổi còn lại hoặc ngày hết hạn của gói vừa bán. Với mã phần trăm buổi/ngày, mức tặng tính theo tổng buổi hoặc tổng ngày của gói đang mua và làm tròn lên. Ví dụ gói 10 buổi + 20% buổi → cộng thêm buổi thưởng theo quy tắc làm tròn, không phải “ước lượng miệng”.

Comp nội bộ (tặng cho HLV, đối tác, sự cố dịch vụ) nên đi luồng tặng có lý do và quyền hạn riêng, không lấy mã marketing công khai để “lách”. Lẫn marketing với comp làm ngân sách chiến dịch và báo cáo khách mới trở nên vô nghĩa.

Một mã trên một đơn và quy tắc không chồng tùy tiện

Vận hành an toàn mặc định: 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 rồi mã B trên cùng giao dịch nếu hệ thống không cho phép. Giảm giá quầy và coupon là các lớp khác nhau — chủ set trần giảm quầy theo vai trò, tách với ngân sách coupon.

Khi chạy flash sale cuối tuần, đừng phát tán mã không giới hạn gói lên group Zalo công khai nếu ngân sách chỉ đủ cho gói thử. Mã “toàn CLB” dễ bị dùng cho gói đắt, làm cháy ngân sách trong vài giờ.

Pre-sale founding: cấu hình mã chỉ gói founding + trần lượt rõ. Thông báo ngày hiệu lực trên sổ vận hành. Sau khi hết pre-sale, tắt mã trên quầy để ca mới không gõ nhầm.

Audit: lượt dùng, hủy đơn và báo cáo hiệu quả

Khi bán thành công, hệ thống gắn mã và số tiền/ưu đãi lên gói hội viên, ghi nhận lượt dùng và tăng đếm sử dụng / ngân sách đã dùng. Hủy hóa đơn đã áp mã sẽ hoàn tác lượt — tránh tình trạng mã “chết oan” sau khi khách đổi ý ngay tại quầy.

Cuối tuần marketing, đối chiếu số lượt dùng với cảm nhận chiến dịch. Nếu lệch lớn, mở nhật ký hoạt động: có phải staff test mã, hay đơn bị hủy rồi tạo lại? Báo cáo hiệu quả chiến dịch đọc snapshot gắn trên gói theo ngày bắt đầu hiệu lực — cùng quy ước với doanh thu bán gói — để so sánh kỳ với kỳ.

“Khách mới” trong báo cáo mã thường hiểu là gói đang xét là gói đầu tiên trong lịch sử hội viên. Dùng chỉ số này để biết mã đang kéo khách mới hay chỉ đang trợ giá gia hạn. Không dùng vanity metric “số lần nhập mã” nếu chưa đối soát đơn đã thanh toán.

SOP quầy 7 bước trước mỗi chiến dịch mã

Bước 1: Owner đặt tên chiến dịch, mã, loại thưởng, danh sách gói, ngày bắt đầu/kết thúc, trần lượt và ngân sách nếu có. Bước 2: Test một đơn quầy đúng gói (phải nhận) và một đơn sai gói (phải từ chối). Bước 3: Nếu bán online, test thêm một đơn trên trang/app công khai với cùng quy tắc.

Bước 4: Train lễ tân 20–30 phút: gõ mã → chờ kiểm OK → mới thu tiền; khách đổi gói → kiểm lại. Bước 5: Viết 5 câu FAQ quầy cho mã hết hạn, hết lượt, hết ngân sách, sai gói, và khách đòi chồng mã. Bước 6: Dán bảng mã–gói tại quầy và ghim group ca. Bước 7: Ngày kết thúc chiến dịch, tắt mã và khóa số lượt dùng vào báo cáo tuần.

Không hứa miệng mức giảm khác với cấu hình. Không sửa giá âm thầm để “cho khách vui”. Không chia sẻ mã nội bộ test trên group khách. Mọi ngoại lệ VIP ghi lý do trên hệ thống hoặc sổ vận hành có ngày hiệu lực.

Checklist owner khi đổi bảng giá gói

Mỗi lần đổi giá catalog, rà lại mã phần trăm: mức giảm tuyệt đối có còn hợp lý với biên lợi nhuận boutique không? Mã tặng buổi trên gói vừa rút ngắn buổi có còn đúng thông điệp ads không? Gói mới thêm vào catalog chưa được gắn vào mã “chỉ gói thử” thì mặc định không nhận mã đó — đừng để lễ tân nghĩ “mọi gói mới đều ăn mã cũ”.

Chuỗi nhẹ nhiều điểm: mỗi CLB cấu hình chiến dịch riêng. Đừng giả định một mã xuyên mọi pháp nhân trừ khi bạn chủ động tạo cùng mã và cùng quy tắc ở từng nơi. Đồng bộ thông điệp marketing trước, đồng bộ cấu hình sau.

Tình huống	Phạm vi gói	Việc làm đúng	Không làm
Mã toàn CLB	Mọi gói	Vẫn kiểm kèm gói đang bán	Giả định mọi SKU đều OK khi đổi ý
Mã chỉ gói thử	Có danh sách gói	Chỉ bán đúng SKU đã chọn	Áp sang PT / gói năm
Hủy đơn có mã	—	Kiểm lượt đã hoàn	Xóa log tay / che số
Nhầm loyalty	—	Dùng coupon chiến dịch	Đổi điểm thay mã ads
Flash sale ads	Thường hẹp gói	Trần lượt + bảng quầy	Phát tán mã không hạn
Đổi bảng giá	Rà mã %	Tính lại biên lợi nhuận	Giữ mã cũ vô thời hạn

Kịch bản thực tế boutique: pre-sale, Tết, và gia hạn

Pre-sale trước khai trương: mã founding chỉ gắn gói founding; trần lượt khớp ngân sách marketing; ngày hết mã khớp ngày mở cửa mềm. Sau soft opening, tắt mã founding và chuyển sang mã “tháng đầu” nếu cần — ghi ngày hiệu lực.

Sau Tết: rà mã hết hạn còn hiện trên quầy; tắt mã cũ; train ca mới không gõ mã năm trước. Đối chiếu lượt dùng với activity log nếu nghi staff test mã nhiều lần.

Gia hạn: cân nhắc mã chỉ áp gói gia hạn (nếu bạn tách SKU), hoặc dùng giảm quầy có trần thay vì phát mã công khai. Mã công khai trên MXH dễ bị khách mới “cướp” ưu đãi dành cho khách cũ.

Khi đo hiệu quả: tách doanh thu từ đơn có mã và đơn không mã trong cùng kỳ; nhìn tỷ lệ khách mới; nhìn tỷ lệ hủy đơn sau khi áp mã. Ba chỉ số này đủ cho họp tuần boutique — không cần dashboard phức tạp hơn nếu đội ngũ chưa đọc số tuần nào ổn định.

Giới hạn trung thực bạn nên nói với đội ngũ

Studio không biến mã thành chương trình điểm thưởng. Chưa hỗ trợ chồng nhiều mã tùy ý trên một đơn. Không tự đồng bộ một mã sang mọi CLB trong chuỗi. Không thay SOP giá và quyền giảm quầy. Không cam kết tỷ lệ chuyển đổi ads — mã chỉ là công cụ vận hành ưu đãi.

Nếu nghi tính năng trên môi trường CLB của bạn khác mô tả, xác minh trên tài khoản thật hoặc hỏi hỗ trợ trước khi train lễ tân thao tác “lách”. Thao tác lách thường phá đối soát và làm mất uy tín boutique nhanh hơn thiếu mã giảm giá.

Đọc thêm cụm công nghệ liên quan: tự mua gói trên app (cùng rule mã), đồng bộ giá kênh, nhật ký hoạt động, và xuất Excel doanh thu khi cần gửi kế toán.

Lộ trình 14 ngày triển khai mã theo gói

Ngày 1–3: chốt mục tiêu chiến dịch (kéo mới / gia hạn / founding), chọn SKU đích, viết bảng mã–gói. Ngày 4–7: cấu hình trên Studio, test quầy + online, sửa FAQ. Ngày 8–10: train ca và mystery check một đơn thật. Ngày 11–14: chạy chiến dịch hẹp, đo lượt dùng và doanh thu đơn có mã, họp rút 5 điểm vào SOP.

Không mở rộng mã sang chi nhánh thứ hai trước khi chi nhánh một tuân thủ ổn định hai tuần. Mọi thay đổi mã ghi ngày hiệu lực trên sổ vận hành.

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

Mã giảm giá theo gói cấu hình ở đâu trên Studio?

Trong khu vực khuyến mãi / promotions của CLB: tạo chiến dịch, nhập mã, chọn loại thưởng, gắn danh sách gói nếu cần giới hạn, đặt ngày và trần lượt. Kiểm quyền nhân sự trước khi giao cho marketing tự tạo mã.

Voucher điểm thưởng dùng chung ô mã bán gói được không?

Không nên lẫn. Điểm thưởng đi luồng rewards; mã chiến dịch đi ô mã khi bán gói. Hai hệ thống khác nhau về ngân sách, báo cáo và ý nghĩa marketing.

Khách đòi dùng hai mã cùng lúc thì trả lời thế nào?

Script chuẩn: hiện tại mỗi lần mua chỉ áp một mã khuyến mãi. Nếu cần ưu đãi cao hơn, đề xuất đúng mã chiến dịch đang chạy hoặc giảm quầy theo quyền hạn đã quy định — không chồng mã tùy tiện.

Hủy hóa đơn đã dùng mã thì sao?

Hệ thống hoàn tác lượt dùng gắn với đơn đó. Vẫn nên đối chiếu cuối ngày nếu ca có nhiều hủy/tạo lại, để tránh hiểu nhầm ngân sách.

Mã trên app và mã tại quầy có khác rule không?

Cùng quy tắc phạm vi gói và kiểm trên máy chủ. Lệch trải nghiệm thường do cấu hình gói bán online khác catalog quầy hoặc do mã hết hạn — kiểm đồng bộ giá/gói trước khi đổ lỗi “phần mềm”.

Làm sao biết mã đang kéo khách mới?

Dùng báo cáo hiệu quả khuyến mãi theo chiến dịch: xem tỷ lệ khách mới (gói đầu tiên) so với khách cũ dùng mã để gia hạn. Kết hợp doanh thu đơn có mã trong kỳ đã chọn.

Staff test mã có làm cháy ngân sách không?

Có thể làm lệch đếm lượt. Quy định môi trường test hẹp, hủy đúng quy trình, và rà nhật ký khi số liệu bất thường. Không test mã production trên hội viên thật ngoài SOP.

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ý, thuế hay cam kết SLA nhà cung cấp thanh toán / tin nhắn / thiết bị. Số liệu ví dụ là khung quản trị, không phải số liệu vận hành riêng của khách hàng.