Báo tin cho đội khi có khách: Web Push, email hay Zalo?

Bài toán nghe đơn giản: khách để lại liên hệ trên website, báo cho đúng người có trách nhiệm xử lý. Nhưng gửi thành công tới một dịch vụ chưa có nghĩa nhân viên đã nhìn thấy tin.

Ba kênh, ba vai trò

Không nên gọi Zalo là lựa chọn tệ nhất chỉ từ một bảng giá hay khung giờ được dẫn lại. Cũng cần phân biệt OA chat với dịch vụ gửi tin theo mẫu: chúng không phải cùng một API hay cùng điều kiện sử dụng.

Nếu muốn dùng Zalo, xác nhận điều gì trước?

Bản thảo cũ có các con số về giá, giờ gửi, cửa sổ hội thoại và vòng đời token nhưng không kèm nguồn chính sách gốc đủ để kiểm chứng. Bản này bỏ các con số đó, không dùng chúng làm cơ sở loại bỏ một kênh.

Trước khi thiết kế tích hợp, đối chiếu tại Zalo Developers và xác nhận với nhà cung cấp: luồng báo tin cho nhân viên có được hỗ trợ không, người nhận cần đồng ý thế nào, có cần duyệt mẫu không, giới hạn gửi, chi phí và quy trình cấp lại quyền. Đừng xây quanh một cách lách mục đích API.

Token cần lưu an toàn, xử lý hết hạn và mất quyền, chống chạy làm mới đồng thời nếu cơ chế token yêu cầu, và có cảnh báo khi kết nối hỏng. Chi tiết phải theo tài liệu của đúng sản phẩm API đang dùng.

Web Push phù hợp khi đội thường làm việc trên trình duyệt

Web Push cho phép nhận tin khi trang không ở phía trước, thậm chí không đang được tải. Nó cần một service worker đang hoạt động và người dùng cấp quyền. Việc hiện thông báo còn phụ thuộc trình duyệt, hệ điều hành, mạng, tiết kiệm pin và chế độ không làm phiền. Phải thử trên thiết bị thật; không hứa tức thì.

Không cần bắt buộc dùng một dịch vụ gửi tin thương mại, nhưng vẫn phụ thuộc push service của hệ sinh thái trình duyệt. Khoá VAPID chỉ là một phần; ứng dụng còn phải quản lý subscription, mã hoá payload và xử lý endpoint hết hạn.

Bốn quyết định thiết kế

1. Payload mỏng, dữ liệu lấy sau đăng nhập

Nội dung có thể hiện trên màn hình khoá. Chỉ gửi loại sự kiện và định danh khó đoán, không gửi lời khách hay thông tin cá nhân. Khi bấm, ứng dụng kiểm tra phiên và quyền trước khi lấy chi tiết. Mã định danh không thay thế phân quyền; cũng không để khoá hay token truy cập trong liên kết thông báo.

2. Gộp sự kiện để tránh gây phiền

Khách gõ năm dòng không nhất thiết cần năm tiếng chuông. Có thể chỉ báo tin đầu cuộc hội thoại hoặc gộp trong một cửa sổ ngắn. Đăng ký nhận tin lặp lại không được coi là một khách mới chỉ vì endpoint lại trả thành công.

3. Đúng người, có người thay thế

Định tuyến theo người phụ trách và quyền xem dữ liệu. Không báo cho người không mở được màn hình đích. Nếu quá hạn chưa nhận xử lý, chuyển cho người trực dự phòng. Ghi trạng thái riêng: sự kiện đã lưu, đã gửi tới dịch vụ, đã được nhận xử lý; không gộp chúng thành một trạng thái "đã giao".

4. Tôn trọng giờ trực

Chỉ dùng thông báo bám màn hình nếu thiết bị hỗ trợ và tình huống cần thiết. Có lịch trực, giờ yên lặng và mức ưu tiên. Khách gửi lúc 23 giờ không mặc định là lý do đánh thức cả đội.

Service worker cũ có thể làm mất thông báo

Bản thảo kể lại một sự cố worker cũ bỏ qua các loại tin mới:

if (data.kind && data.kind !== "visitor_waiting") return;

CDN có thể giữ bản cũ; vòng đời cài đặt và kích hoạt worker cũng có thể trì hoãn bản mới. Kiểm tra cả hai thay vì chỉ xoá cache trình duyệt.

Với URL worker không đổi, dùng chính sách tái xác thực phù hợp như Cache-Control: no-cache, kiểm tra CDN có ghi đè không và có worker mới đang chờ kích hoạt không. no-cache không có nghĩa cấm lưu. Thêm số phiên bản để biết thiết bị đang chạy bản nào, rồi thử toàn bộ luồng trên thiết bị thật.

Cách chọn cho nhóm nhỏ

Bắt đầu bằng Web Push để nhắc và email để lưu, nếu đội đã dùng màn hình quản trị thường xuyên. Thiết kế hàng đợi, retry có giới hạn, chống gửi trùng và cảnh báo thất bại. Trong ứng dụng luôn có danh sách việc chưa xử lý để không phụ thuộc hoàn toàn vào tiếng chuông.

Nếu đội chủ yếu dùng Zalo, đánh giá tích hợp chính thức sau khi xác nhận luồng được hỗ trợ và chính sách hiện hành. Tiêu chí cuối cùng là có người nhận việc trong thời hạn đã thống nhất, không phải kênh nào quen thuộc nhất.

Sự cố worker được thuật lại từ bản thảo Zukatek tháng 10/2026, chưa có log gốc để xác minh độc lập. Bài này không xác nhận giá hay chính sách Zalo.

Nguồn đối chiếu: MDN — Push API, MDN — Cache-Control.