Chuỗi nhà hàng 2–10 chi nhánh không cần mua một hệ thống CRM doanh nghiệp đắt tiền. Thứ cần có là một mã khách dùng chung cho mọi chi nhánh (thường là số điện thoại) được nhập ngay trên POS, một bảng khách hàng trung tâm gom dữ liệu từ các chi nhánh, vài kịch bản gửi tin tự động qua Zalo OA, và báo cáo giữ chân khách theo từng chi nhánh. Phần lớn POS F&B phổ biến ở Việt Nam như KiotViet, Sapo FnB, iPOS hay MISA CukCuk đã có sẵn tính năng thành viên, tích điểm. Thứ thường thiếu là quy tắc vận hành và kỷ luật dữ liệu, không phải phần mềm.
Tóm tắt: Ưu tiên tăng tỷ lệ hoá đơn có gắn số điện thoại trước, sau đó mới làm kịch bản chăm sóc. Đơn từ ứng dụng giao đồ ăn gần như là điểm mù vì thường không có số điện thoại thật của khách. Đo tỷ lệ khách quay lại lần thứ hai theo từng chi nhánh, đây là con số nói lên nhiều nhất.
Chuỗi nhà hàng cần CRM để trả lời những câu hỏi nào?#
Trước khi chọn công cụ, hãy viết ra những câu hỏi mà chủ chuỗi muốn có câu trả lời mỗi tuần. Thường là:
- Tháng này có bao nhiêu khách mới, bao nhiêu người quay lại lần thứ hai?
- Khách quen của chi nhánh A có ghé chi nhánh B không, hay mỗi chi nhánh là một tệp khách riêng?
- Chi nhánh nào giữ khách tốt nhất, chi nhánh nào chỉ sống nhờ khách vãng lai?
- Ai là những khách đặt bàn nhóm, tiệc công ty, và họ thường đặt vào dịp nào?
- Khách đánh giá kém ở chi nhánh nào, món nào, ca nào?
Nếu CRM không giúp trả lời những câu này nhanh hơn, nó chỉ là danh bạ số điện thoại nằm trong POS.
Bài toán riêng của mô hình đa chi nhánh#
Một nhà hàng đơn lẻ làm CRM khá đơn giản. Khi có nhiều chi nhánh, xuất hiện những vấn đề sau:
Một khách, nhiều chi nhánh. Nếu mỗi chi nhánh dùng một tài khoản POS riêng, không liên thông, thì cùng một khách sẽ là hai hồ sơ khác nhau. Điểm tích ở chi nhánh này không dùng được ở chi nhánh kia, và báo cáo "khách quay lại" bị thấp hơn thực tế.
Dữ liệu bẩn từ quầy thu ngân. Thu ngân nhập số điện thoại sai một chữ số, nhập số của chính mình để tích điểm hộ, hoặc nhập số giả để qua bước bắt buộc. Một số điện thoại có hàng chục hoá đơn mỗi ngày ở nhiều chi nhánh là dấu hiệu cần kiểm tra.
Ứng dụng giao đồ ăn là điểm mù. Đơn từ GrabFood, ShopeeFood, Be thường không trả về số điện thoại thật của khách cho nhà hàng. Doanh thu delivery có thể lớn nhưng gần như không đưa được vào CRM. Muốn có dữ liệu kênh này, nhà hàng phải tự kéo khách sang kênh riêng (website đặt món, Zalo OA, hotline) bằng ưu đãi phù hợp.
Nhân sự luân chuyển, part-time nhiều. Quy trình hỏi số điện thoại, giải thích tích điểm phải đủ đơn giản để nhân viên mới làm đúng ngay trong ca đầu tiên.
Kiến trúc tối giản: POS, bảng khách trung tâm và Zalo OA#
POS chi nhánh 1 ─┐
POS chi nhánh 2 ─┼──→ Bảng khách hàng trung tâm ──→ Kịch bản tự động (n8n / Make)
POS chi nhánh n ─┘ (mã khách = SĐT chuẩn hoá) ↓
↑ Zalo OA (ZNS) / SMS
Đặt bàn (hotline, Zalo, web) ──┘ ↓
Báo cáo theo chi nhánh
Có hai cách triển khai tuỳ hiện trạng:
Cách A, dùng module thành viên của POS chuỗi. Nếu toàn chuỗi dùng cùng một POS và POS đó quản lý khách hàng dùng chung giữa các chi nhánh, hãy tận dụng tối đa: tích điểm, hạng thành viên, ưu đãi sinh nhật. Đây là cách nhanh nhất và ít điểm hỏng nhất. Cần kiểm tra trước với nhà cung cấp POS: khách hàng có dùng chung giữa chi nhánh không, có API hoặc xuất file để lấy dữ liệu ra không.
Cách B, gom dữ liệu ra ngoài. Khi các chi nhánh dùng POS khác nhau, hoặc POS không đủ khả năng phân tích, dùng API hoặc file xuất hằng ngày đổ về một bảng trung tâm (Google Sheets cho quy mô nhỏ, cơ sở dữ liệu như PostgreSQL hoặc BigQuery khi dữ liệu lớn). Công cụ workflow như n8n hay Make đọc bảng này để kích hoạt kịch bản gửi tin. Cách này linh hoạt hơn nhưng cần người duy trì.
Ở cả hai cách, bước quan trọng nhất là chuẩn hoá số điện thoại: bỏ khoảng trắng, đổi +84 thành 0, loại số không đủ 10 chữ số. Không làm bước này, mọi báo cáo phía sau đều lệch.
Thu thập số điện thoại tại quầy mà không làm phiền khách#
Tỷ lệ hoá đơn có gắn số điện thoại quyết định CRM của bạn có dùng được hay không. Một số cách nhà hàng thường áp dụng:
- Tích điểm ngay khi thanh toán, nói một câu ngắn và rõ lợi ích: "Anh chị cho em số điện thoại để tích điểm, đủ điểm được đổi món".
- Mã QR trên bàn dẫn đến Zalo OA của chuỗi kèm ưu đãi lần sau. Khách quét khi chờ món, không làm chậm quầy thu ngân.
- Đặt bàn qua hotline hoặc Zalo luôn ghi số điện thoại vào cùng bảng khách hàng, không để trong sổ riêng của quản lý chi nhánh.
- Kiểm soát gian lận tích điểm: cảnh báo khi một số điện thoại phát sinh quá nhiều hoá đơn trong ngày, hoặc xuất hiện ở nhiều chi nhánh cách xa nhau trong vài giờ.
Khi thu thập số điện thoại để gửi tin chăm sóc, cần cho khách biết mục đích và có cách để khách từ chối nhận tin, theo tinh thần Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân.
5 kịch bản tự động nên làm trước#
| Kịch bản | Điều kiện kích hoạt | Kênh | Lưu ý |
|---|---|---|---|
| Cảm ơn sau lần đầu | Khách có hoá đơn đầu tiên | Zalo ZNS | Gửi trong ngày, kèm ưu đãi nhỏ cho lần thứ hai |
| Nhắc quay lại | Khách lâu không quay lại hơn nhịp thường lệ | Zalo ZNS hoặc SMS | Nhịp tính từ dữ liệu của chính chuỗi, khác nhau giữa quán lẩu, quán cà phê, nhà hàng tiệc |
| Sinh nhật | Trước sinh nhật vài ngày | Zalo ZNS | Ưu đãi nên dùng được ở mọi chi nhánh |
| Khách đặt bàn nhóm | Khách từng đặt bàn từ 8–10 người trở lên | Gọi điện hoặc Zalo cá nhân hoá | Liên hệ trước các dịp liên hoan cuối năm, lễ |
| Phản hồi kém | Đánh giá thấp qua QR khảo sát | Thông báo cho quản lý chi nhánh | Liên hệ khách trong ngày, ghi lại cách xử lý |
Kịch bản cuối cùng không gửi tin cho khách mà gửi cho người quản lý. Đây thường là kịch bản đem lại giá trị nhanh nhất vì giúp xử lý trải nghiệm xấu trước khi nó thành đánh giá một sao trên Google Maps.
Muốn chia khách thành nhóm (khách thân thiết, khách sắp rời, khách mới) để nhắn tin khác nhau, phương pháp RFM là điểm khởi đầu dễ nhất. Xem cách làm từng bước trong bài phân khúc khách hàng RFM cho SME.
Báo cáo theo chi nhánh: những chỉ số nên xem mỗi tuần#
| Chỉ số | Cách tính | Dùng để làm gì |
|---|---|---|
| Tỷ lệ hoá đơn gắn số điện thoại | Hoá đơn có SĐT hợp lệ ÷ tổng hoá đơn tại quán | Đo kỷ luật thu thập dữ liệu của từng chi nhánh |
| Khách mới | Số SĐT xuất hiện lần đầu trong toàn chuỗi | Hiệu quả marketing thu hút khách |
| Tỷ lệ quay lại lần hai | Khách mới tháng trước có quay lại trong 30 hoặc 60 ngày | Chỉ số giữ chân quan trọng nhất |
| Khách dùng chéo chi nhánh | Khách có hoá đơn ở từ hai chi nhánh trở lên | Đánh giá sức mạnh thương hiệu chung |
| Chi tiêu trung bình mỗi khách quen | Tổng chi ÷ số khách quay lại | So sánh chất lượng tệp khách giữa chi nhánh |
Khi so sánh chi nhánh, chỉ so những chi nhánh có tỷ lệ hoá đơn gắn số điện thoại tương đương. Chi nhánh thu thập kém sẽ luôn trông như giữ khách kém, dù thực tế không phải vậy. Bài 5 chỉ số vận hành SME nên theo dõi hằng tuần có thêm cách dựng bảng theo dõi tuần.
Chi phí thật sự nằm ở đâu?#
Bảng giá thay đổi theo nhà cung cấp và thời điểm nên ở đây chỉ liệt kê các khoản cần dự trù:
- Phí POS theo chi nhánh hoặc theo gói, thường đã có module khách hàng.
- Phí gửi tin Zalo ZNS hoặc SMS, tính theo từng tin. Đây là khoản tăng theo số khách, nên kịch bản gửi càng đúng người càng tiết kiệm.
- Chi phí thiết lập và kết nối nếu đi theo cách B: viết luồng đồng bộ, làm báo cáo.
- Thời gian vận hành: người viết nội dung tin, người theo dõi báo cáo, người xử lý phản hồi kém. Khoản này hay bị quên nhất.
Góc nhìn từ DsAI#
Qua các dự án DsAI đã triển khai cho F&B, chúng tôi thấy phần lớn chuỗi nhà hàng nhỏ đã có đủ công cụ, chỉ chưa có người chịu trách nhiệm về dữ liệu khách. Mỗi quản lý chi nhánh lo doanh thu chi nhánh mình, không ai lo tệp khách chung.
Một điểm khác: chủ chuỗi thường muốn bắt đầu bằng chương trình thành viên nhiều hạng, nhiều quyền lợi. Trong khi đó, một chương trình tích điểm đơn giản cộng với kịch bản cảm ơn lần đầu và nhắc quay lại thường đủ để tạo khác biệt trong vài tháng đầu, và dễ giải thích cho nhân viên hơn.
Lỗi thường gặp#
- Bắt buộc nhập số điện thoại mới cho thanh toán. Nhân viên sẽ nhập số giả. Nên khuyến khích bằng lợi ích, không ép.
- Mỗi chi nhánh tự làm khuyến mãi riêng trên Zalo OA. Khách nhận nhiều tin trùng lặp, giọng văn không thống nhất. Nội dung gửi khách nên do một người phụ trách cho cả chuỗi.
- Gửi tin cho cả danh sách thay vì nhóm phù hợp. Tốn phí tin nhắn và khiến khách chặn OA.
- Không loại hoá đơn huỷ, hoá đơn nội bộ. Bữa ăn nhân viên, hoá đơn test làm sai số liệu khách quen.
- Bỏ qua dữ liệu đặt bàn. Khách đặt bàn nhóm thường là người ra quyết định cho cả bàn, nhưng hay chỉ nằm trong sổ của lễ tân.
Khi nào KHÔNG nên làm CRM cho chuỗi nhà hàng?#
- Quán chủ yếu phục vụ khách vãng lai: gần bến xe, khu du lịch, trạm dừng chân. Khách khó quay lại dù được chăm sóc tốt.
- Doanh thu chủ yếu đến từ ứng dụng giao đồ ăn và chưa có kế hoạch kéo khách sang kênh riêng. Dữ liệu khách không về tay nhà hàng thì CRM không có nguyên liệu.
- Các chi nhánh dùng POS khác nhau và quy trình khác nhau. Nên thống nhất POS và quy trình thu ngân trước. Nếu đơn online cũng đang rối, xem cách chuẩn hoá quy trình duyệt đơn online cho chuỗi F&B.
- Chưa có ai phụ trách nội dung và chăm sóc khách. Kịch bản tự động vẫn cần người viết nội dung, theo dõi và điều chỉnh.
Câu hỏi thường gặp#
Chuỗi 3 chi nhánh có cần phần mềm CRM riêng không?#
Thường là chưa. Nếu cả 3 chi nhánh dùng chung một POS có quản lý khách hàng liên chi nhánh, hãy khai thác module đó trước, kết hợp Zalo OA để gửi tin. Chỉ khi cần phân tích sâu hơn hoặc POS không xuất được dữ liệu, mới tính đến việc gom dữ liệu ra một bảng riêng.
Làm sao lấy dữ liệu khách từ GrabFood, ShopeeFood?#
Các ứng dụng giao đồ ăn thường không cung cấp số điện thoại thật của khách cho nhà hàng. Cách khả thi là đặt thẻ hoặc tem trong túi đồ ăn dẫn về Zalo OA của chuỗi, kèm ưu đãi khi đặt trực tiếp lần sau. Khi khách tự để lại thông tin, dữ liệu mới thuộc về nhà hàng.
Nên dùng Zalo OA hay SMS để nhắn khách?#
Với khách Việt Nam, Zalo ZNS thường là lựa chọn chính vì gửi theo số điện thoại, hiển thị tên thương hiệu và có nút bấm. Tuy nhiên ZNS cần OA xác thực và mẫu tin được duyệt, nội dung quảng cáo thuần thường không được chấp nhận. SMS dùng bổ sung cho khách không dùng Zalo bằng số đó.
Bao lâu thì thấy hiệu quả?#
Tỷ lệ hoá đơn gắn số điện thoại có thể cải thiện trong vài tuần nếu quy trình thu ngân rõ ràng. Tỷ lệ khách quay lại lần hai cần ít nhất một đến hai chu kỳ quay lại thông thường của chuỗi mới đánh giá được. Đừng kết luận sau một tuần chạy kịch bản.
Bạn đang vận hành chuỗi nhà hàng và muốn biết dữ liệu khách hiện có đang nằm ở đâu, dùng được đến mức nào? DsAI có thể cùng bạn kiểm tra POS, quy trình thu ngân và đề xuất lộ trình CRM vừa với quy mô. Bạn có thể đặt lịch tư vấn CRM cho chuỗi F&B với DsAI. Nếu bạn muốn xem một ví dụ về CRM gắn với POS cho F&B, đọc thêm bài F&B và CRM: tăng tỷ lệ khách quay lại.

