Trên trang này ↓
Một báo giá chờ duyệt có thể cần nhắc quản lý ngay trong ngày. Việc đồng bộ danh bạ hoàn tất chỉ cần xuất hiện trong ứng dụng. Nếu cả hai đều gửi qua nhiều kênh, người dùng sớm bỏ qua tất cả. Mỗi thông báo vì thế phải gắn với một sự kiện, người nhận và hành động cụ thể.
Bắt đầu từ sự kiện và hành động, không bắt đầu từ kênh gửi
Yêu cầu "gửi email khi đơn hàng thay đổi" chưa đủ để dev triển khai. Đơn hàng có thể được xác nhận, đổi lịch giao, hủy hoặc hoàn tiền. Mỗi sự kiện có người nhận khác nhau.
Đội sản phẩm nên lập danh mục sự kiện gồm điều kiện kích hoạt, người nhận, hành động, thời hạn, kênh và điều kiện hủy. Với yêu cầu duyệt báo giá, người nhận là người có quyền duyệt. Khi báo giá bị thu hồi, thông báo đang chờ phải mất hiệu lực.
Thông báo trong ứng dụng phù hợp với người truy cập thường xuyên. Email dành cho hành động có thời hạn. SMS hay Zalo chỉ nên dùng khi đã có sự đồng ý và giới hạn tần suất.
Phân biệt thông tin, việc cần làm và cảnh báo
Thông tin cho biết một thay đổi đã xảy ra. Việc cần làm dẫn tới một bản ghi cụ thể. Cảnh báo cho biết quy trình có nguy cơ dừng.
MVP thường chỉ cần hai mức: cần hành động và để biết. Cảnh báo kỹ thuật dành cho đội vận hành nên đi qua kênh riêng, không trộn với thông báo cho khách hàng.
Quy trình thiết kế thông báo cho MVP
Bước 1: Liệt kê sự kiện từ quy trình chính
Đi qua từng trạng thái, ghi lại sự kiện khiến một người cần biết hoặc cần hành động. Chưa chọn kênh ở bước này.
Bước 2: Gắn người nhận và quyền xem
Xác định người nhận theo vai trò và phạm vi dữ liệu. Người được thông báo phải có quyền mở đối tượng liên quan tại thời điểm nhận.
Bước 3: Chốt hành động và thời hạn
Mỗi thông báo cần dẫn tới nơi xử lý cụ thể. Nếu không có hành động, hãy quyết định thời điểm tự ẩn.
Bước 4: Chọn kênh và tần suất
Chọn thông báo trong ứng dụng, email hoặc kênh ngoài dựa trên độ khẩn cấp và thói quen truy cập. Quy định việc gộp, nhắc lại và giới hạn số lần gửi.
Bước 5: Thiết kế trạng thái gửi
Lưu trạng thái đã tạo, đang gửi, gửi thành công hoặc thất bại. Đặt mã nhận diện để cùng một sự kiện không sinh nhiều thông báo ngoài ý muốn.
Bước 6: Kiểm tra bằng tình huống thay đổi
Thử trường hợp người nhận đổi vai trò, bản ghi bị xóa, sự kiện đảo ngược hoặc kênh gửi tạm thời không hoạt động.
Quy trình thử gửi lại cần áp dụng retry và idempotency. Lần thử mới không được tạo thông báo trùng.
Nội dung thông báo cần đủ để quyết định bước tiếp theo
Tiêu đề nên nêu đối tượng và thay đổi, chẳng hạn "Báo giá đang chờ duyệt". Phần mô tả cho biết người tạo, mốc thời gian và lý do cần xử lý. Nút hành động mở đúng bản ghi.
Gộp thông báo và cho người dùng quyền kiểm soát
Khi nhiều bản ghi cùng thay đổi trong vài phút, hệ thống có thể gộp thành một bản tổng hợp. Việc có hạn xử lý riêng vẫn cần xuất hiện độc lập.
Quyền tắt nên áp dụng cho thông báo tham khảo. Thông báo bảo mật, thay đổi quyền hoặc hành động bắt buộc có thể không cho tắt. Tùy chọn nên theo loại sự kiện và kênh.
Checklist nghiệm thu hệ thống thông báo
Sự kiện và người nhận
- Mỗi loại thông báo có điều kiện kích hoạt và điều kiện hủy rõ ràng.
- Người nhận được xác định theo vai trò, phạm vi dữ liệu và quyền hiện tại.
- Một sự kiện lặp lại không tạo thông báo trùng ngoài quy tắc.
Nội dung và hành động
- Tiêu đề gọi đúng đối tượng hoặc trạng thái đã thay đổi.
- Liên kết mở đúng bản ghi và kiểm tra lại quyền truy cập.
- Thông báo hết hiệu lực không còn yêu cầu người dùng xử lý.
Kênh và vận hành
- Email hoặc kênh ngoài có trạng thái gửi và cơ chế thử lại an toàn.
- Quy tắc gộp, nhắc lại và giới hạn tần suất được kiểm tra.
- Người dùng có thể điều chỉnh các thông báo không bắt buộc.
- Đội vận hành có cách tra nguyên nhân khi thông báo không đến.
Khi nào MVP chưa cần xây trung tâm thông báo?
Nếu sản phẩm chỉ có vài sự kiện, một danh sách việc cần xử lý cùng email cho tình huống quan trọng có thể đủ. Chỉ thêm trung tâm thông báo khi người dùng cần tra lại nhiều loại sự kiện.
Hãy thiết kế nền tảng sớm nếu quy trình phụ thuộc vào duyệt nội bộ, thời hạn thanh toán hoặc bàn giao giữa nhiều vai trò. Trạng thái công việc và thông báo phải dùng cùng một định nghĩa. Xem thêm cách thiết kế trạng thái công việc.
Dịch vụ Product Development của Auranium có thể hỗ trợ đội ngũ chốt sự kiện, quyền nhận, kênh gửi và tiêu chí nghiệm thu. Kết quả cần là bộ quy tắc dev và QA có thể kiểm tra.
