Zalo OA là gì? Cách nhắn tin ZBS tự động cho doanh nghiệp

Zalo OA là gì?

Zalo OA là viết tắt của Zalo Official Account, tài khoản chính thức của doanh nghiệp trên Zalo. Đây là nơi doanh nghiệp giới thiệu thông tin và tương tác với khách hàng bằng danh tính thương hiệu, thay vì dùng tài khoản Zalo cá nhân của một nhân viên.

OA đã xác thực có thể được nhiều quản trị viên vận hành. Các tính năng được sử dụng phụ thuộc loại tài khoản và gói dịch vụ OA. Hồ sơ quảng cáo chưa có giấy đăng ký kinh doanh không đồng nghĩa với OA xác thực và không có đầy đủ khả năng nhắn tin, bài viết hay chatbot.

Nguồn: Hướng dẫn khởi tạo OA của Zalo.

Với một cửa hàng, OA là đầu mối liên hệ với khách. Với một chuỗi cửa hàng, bài toán còn là ai phụ trách hội thoại, dữ liệu thuộc chi nhánh nào và kết quả chiến dịch được ghi nhận ở đâu. Tạo OA giải quyết phần hiện diện; tổ chức dữ liệu và quy trình mới giúp vận hành nhất quán.

Zalo OA và tin nhắn ZBS khác nhau thế nào?

OA là tài khoản đại diện doanh nghiệp. ZBS Template Message là giải pháp tin nhắn doanh nghiệp theo mẫu, có luồng gửi qua UID hoặc số điện thoại trên Zalo. Từ ngày 01/01/2026, Zalo đưa ZNS cùng các loại tin UID giao dịch, truyền thông vào giải pháp ZBS Template Message.

ZBS không phải ô chat để viết tùy ý rồi gửi hàng loạt. Mẫu tin cần được Zalo kiểm duyệt trước khi gửi, dù gửi qua UID hay số điện thoại. Nội dung và người nhận phải phù hợp mục đích của mẫu.

Nguồn: Thông báo ra mắt ZBS Template Message.

Vì vậy, trước khi xây quy trình, hãy tách hai việc: nhân viên tư vấn trong hội thoại và hệ thống gửi thông tin theo mẫu. Hai nhu cầu có cách vận hành khác nhau, không nên gộp thành một nút “gửi tin tự động”.

Nhắn tin ZBS tự động hoạt động như thế nào?

Nhắn tin ZBS tự động là để hệ thống xử lý một sự kiện, kiểm tra điều kiện và gọi API gửi mẫu phù hợp. Thay vì nhân viên lần lượt chọn khách, điền thông tin và bấm gửi, quy trình dùng dữ liệu đã chuẩn hóa để thực hiện những bước này.

Ví dụ, dữ liệu một đơn hàng được cập nhật vào hệ thống. Quy trình kiểm tra trạng thái, người nhận và mẫu được phép dùng; sau đó điền các tham số như tên khách, mã đơn hoặc mã ưu đãi. Kết quả gửi được ghi lại để biết hồ sơ nào đã xử lý và hồ sơ nào cần kiểm tra.

Cần chuẩn bị gì trước khi bật gửi thật?

• Kết nối đúng OA và ứng dụng: quyền truy cập, tài khoản dịch vụ và cấu hình phải thuộc doanh nghiệp cần gửi.
• Mẫu tin được duyệt: chọn đúng mục đích và điền đầy đủ tham số, không biến mẫu giao dịch thành quảng cáo tùy ý.
• Dữ liệu và điều kiện người nhận: có cơ sở xác định khách phù hợp, không chỉ một danh sách số điện thoại.
• Sự kiện và chống gửi trùng: xác định một đơn hàng hoặc một sự kiện được xử lý bao nhiêu lần.
• Giới hạn và người theo dõi: chốt ngân sách, giới hạn gửi và cách xử lý lỗi trước khi kích hoạt.

Nguồn: Quy định kiểm duyệt mẫu tin ZBS và Chính sách dịch vụ ZBS. Quy định có thể thay đổi; đối chiếu bản hiện hành trước khi gửi.

Ví dụ: gửi ưu đãi cho khách đã mua hàng

Giả sử doanh nghiệp muốn gửi ưu đãi hậu mãi cho khách đã hoàn tất đơn hàng. Luồng cần có nhánh không gửi, không mặc định mọi khách đều đủ điều kiện.

Điểm quan trọng nằm ở bước cuối: gửi thành công không đồng nghĩa với khách đã dùng ưu đãi. Nếu chỉ lưu kết quả gửi mà không nối dữ liệu sử dụng, báo cáo chưa trả lời được câu hỏi chiến dịch tạo ra kết quả gì.

Yêu cầu nội dung ưu đãi: Quy định kiểm duyệt ZBS. Phần kết nối và đo lường trên là cách tổ chức quy trình đề xuất, không phải điều kiện bắt buộc do Zalo quy định.

Đo hiệu quả chiến dịch, không chỉ số tin đã gửi

Một chiến dịch có thể gửi thành công nhưng chuyển đổi thấp. Để biết cần sửa dữ liệu, mẫu tin hay ưu đãi, hãy nhìn từng bước với một mẫu số rõ ràng.

Đủ điều kiện

Số hồ sơ được phép đi tiếp sau kiểm tra. Tách khỏi tổng danh sách để biết bao nhiêu khách bị loại và vì sao.

Kết quả gửi

Thành công, thất bại hoặc bỏ qua. Không tự gọi phản hồi API thành công là “khách đã đọc”. Chỉ dùng trạng thái đọc khi có dữ liệu xác nhận tương ứng.

Ưu đãi đã dùng

Mã được xác nhận sử dụng, không phải chỉ đã phát hành. Đếm đúng người hoặc đúng mã, tránh cộng trùng sự kiện.

Chuyển đổi

Số kết quả mục tiêu chia cho nhóm được chọn làm mẫu số. Ghi rõ đang tính trên người nhận tin, người tham gia hay số ưu đãi đã cấp.

Chi phí

Đối chiếu chi phí gửi với kết quả có thể xác nhận. Không suy ra doanh thu hay ROI nếu chưa kết nối dữ liệu đơn hàng và cách ghi nhận phù hợp.

A/B test mẫu tin nào hiệu quả hơn?

Để so sánh hai mẫu, chia các khách đủ điều kiện thành hai nhóm tương đương. Giữ cùng ưu đãi, khoảng thời gian và cách ghi nhận chuyển đổi; chỉ thay yếu tố muốn thử. Cả hai mẫu dùng để gửi thật đều phải đáp ứng yêu cầu kiểm duyệt.

Để gắn kết quả với mẫu tin, dữ liệu cần nối được chiến dịch, khách hàng, mẫu đã nhận và sự kiện chuyển đổi. Khách tự dùng ưu đãi dù không nhận ZBS cần được tách riêng; không cộng toàn bộ lượt dùng vào hiệu quả tin nhắn. Đây là cách đo theo thiết kế chiến dịch, không phải số liệu mặc nhiên có từ API gửi tin.

Những lỗi thường gặp khi bắt đầu tự động hóa

• Bắt đầu bằng nội dung, chưa xác định mục tiêu. “Gửi một tin chăm sóc” quá rộng. Hãy chốt kết quả: xác nhận đơn, nhắc một công việc hay đo lượt dùng ưu đãi.
• Không có nhánh bỏ qua. Hồ sơ thiếu dữ liệu hoặc chưa phù hợp vẫn đi vào bước gửi, khiến lỗi và nguyên nhân khó theo dõi.
• Một sự kiện kích hoạt nhiều lần. Cần khóa nhận diện rõ ràng, chẳng hạn mã đơn và loại sự kiện, để tránh gửi lặp ngoài ý muốn.
• Lấy số gửi thành công làm hiệu quả. Đây là kết quả vận hành, không thay thế lượt xác nhận, lượt dùng ưu đãi hay đơn hàng.
• So hai mẫu trên hai nhóm quá khác nhau. Mẫu B có thể tốt hơn vì nhóm khách khác, không phải vì nội dung. Cần thống nhất điều kiện chia nhóm trước khi thử.

Triển khai workflow ZBS với Zorbit

Zorbit tổ chức dữ liệu khách hàng trong Data Hub, dùng điều kiện để rẽ nhánh, ánh xạ tham số vào mẫu ZBS và ghi nhật ký xử lý của chiến dịch. Trước khi kích hoạt, bạn có thể chạy thử đường đi của dữ liệu mà không gửi tin thật.

Phần đo lượt chơi, mã ưu đãi và chuyển đổi cần dữ liệu tương ứng từ chương trình, Mini App hoặc hệ thống bán hàng. Khi tư vấn, nên xác định nguồn dữ liệu và mục tiêu đo trước; phạm vi kết nối, báo cáo và A/B cần được xác nhận theo triển khai, không chỉ dựa trên giao diện minh họa.