Xin quyền trên Zalo Mini App: Thiết kế đúng ngữ cảnh để khách hiểu và lựa chọn

Xin quyền trên Zalo Mini App nên gắn với một nhu cầu cụ thể, giải thích rõ dữ liệu dùng để làm gì và có luồng xử lý khi khách chưa đồng ý. Việc khách mở Mini App không đồng nghĩa doanh nghiệp đã có toàn bộ thông tin, được phép dùng mọi dữ liệu hoặc được gửi mọi loại thông điệp.

Nếu người dùng chỉ muốn xem dịch vụ nhưng gặp nhiều yêu cầu cung cấp thông tin ngay từ đầu, họ có thể rời đi trước khi hiểu giá trị. Thiết kế tốt bắt đầu từ nhu cầu của khách, rồi xác định dữ liệu thực sự cần cho bước đó.

Phân biệt các trạng thái thường bị gộp chung

Mở Mini App, nhận diện người dùng, chia sẻ thông tin, quan tâm OA và đủ điều kiện nhận một loại tin là các trạng thái cần được kiểm tra theo cơ chế nền tảng và thiết kế cụ thể. Không nên coi một hành động là bằng chứng cho tất cả trạng thái còn lại.

Zalo có tài liệu riêng cho các API xin quyền và lấy số điện thoại. [1] [2] Đội triển khai cần đối chiếu tài liệu, phiên bản và quyền đã được xét duyệt tại thời điểm làm dự án, thay vì sao chép một màn hình hoặc cách gọi từ bản hướng dẫn cũ.

Đây là gợi ý thiết kế trải nghiệm, không phải kết luận rằng mọi nghiệp vụ có cùng điều kiện quyền. Phạm vi dữ liệu và trách nhiệm xử lý cần được doanh nghiệp xác nhận.

Đặt lời giải thích trước yêu cầu quyền

Lời giải thích nên ngắn và cụ thể: khách đang làm gì, thông tin hỗ trợ bước nào và điều gì xảy ra nếu chưa cung cấp. Tránh các câu chung như “để nâng cao trải nghiệm” khi không chỉ ra lợi ích thực tế.

Ví dụ nội dung đề xuất cho bước đặt lịch: “Cung cấp thông tin liên hệ để cửa hàng xác nhận và hỗ trợ lịch hẹn này.” Câu chữ cuối cần khớp luồng thực tế, chính sách của doanh nghiệp và yêu cầu nền tảng; không dùng một lời hứa rộng hơn việc hệ thống thực sự làm.

Một bước quyền cần gắn với giá trị và mục đích rõ ràng.

Thiết kế cả nhánh chưa đồng ý

Nếu dữ liệu không cần cho chức năng đang dùng, hãy cân nhắc cho khách tiếp tục. Nếu dữ liệu là điều kiện của nghiệp vụ, giải thích phần nào chưa thể hoàn thành và cung cấp cách hỗ trợ phù hợp. Không giả lập thành công khi hệ thống chưa có đủ dữ liệu.

Không nên lặp yêu cầu liên tục mà không có thay đổi ngữ cảnh. Hãy lưu trạng thái phù hợp để lần tương tác sau hiểu khách đang ở bước nào. Khi khách chủ động quay lại một chức năng cần dữ liệu đó, có thể giải thích lại đúng mục đích theo cơ chế nền tảng.

Đồng bộ quyền và nhận diện là hai công việc khác nhau

Sau khi có dữ liệu, cần kiểm tra cách liên kết với hồ sơ hiện có. Một số điện thoại trùng chưa tự giải quyết mọi trường hợp mua hộ hoặc thông tin dùng chung. Việc hợp nhất vẫn phải theo quy tắc nhận diện đã xác nhận.

Không dùng trạng thái “đã có hồ sơ” thay cho điều kiện sử dụng dữ liệu và điều kiện gửi tin.

Mỗi nơi thực thi cần nhận được trạng thái đang áp dụng. Khi thông tin thay đổi, kiểm tra các hành trình đang chờ để không tiếp tục hành động dựa trên điều kiện cũ. Độ trễ đồng bộ là một phần cần được nghiệm thu.

Đo trải nghiệm mà không tối ưu bằng mọi giá

Theo dõi tỷ lệ bắt đầu thao tác, hoàn tất nghiệp vụ, lỗi ở bước quyền và yêu cầu hỗ trợ. Tỷ lệ đồng ý chỉ là một phần; nếu nhiều người đồng ý nhưng không hoàn tất đặt lịch, vẫn cần xem lại luồng.

Thử nghiệm cách giải thích hoặc vị trí xin quyền trên nhóm phù hợp, nhưng giữ nội dung trung thực. Không đánh giá thiết kế chỉ bằng số hồ sơ thu được mà bỏ qua khách có hiểu mục đích và nhận được lợi ích đã hứa hay không.

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

Khách mở Mini App là đã chia sẻ số điện thoại chưa?

Không nên suy diễn như vậy. Cần kiểm tra trạng thái và kết quả theo API, quyền được cấp và luồng thực tế đang áp dụng.

Có thể dùng một lời giải thích cho mọi quyền không?

Nên mô tả đúng từng nhu cầu và phạm vi dữ liệu. Một câu chung dễ khiến khách không hiểu thông tin đang phục vụ bước nào.

Khách chưa đồng ý thì có bắt buộc rời Mini App không?

Phụ thuộc chức năng. Nên thiết kế rõ phần vẫn dùng được và phần cần dữ liệu, cùng phương án hỗ trợ khi chưa hoàn thành được nghiệp vụ.

Bước tiếp theo

Vẽ lại một hành trình từ lúc khách mở Mini App đến lúc hoàn tất nhu cầu, đánh dấu từng dữ liệu và điều kiện cần có. Trao đổi với CNV CDP để khảo sát điểm chạm, nhận diện và luồng chăm sóc phù hợp.

Đọc thêm: Nhận diện khách hàng trên CDP · Đổi lịch trên Mini App · Điều phối tần suất Automation.

Nguồn tham khảo

[1] Zalo Platform Document Hub – authorize.

[2] Zalo Platform Document Hub – getPhoneNumber. Đối chiếu ngày 20/10/2026. Bài viết hướng dẫn tư duy thiết kế; chi tiết quyền và điều kiện nền tảng phải được kiểm tra theo phiên bản triển khai.