Khi bạn tương tác với người dùng thông qua các nhân viên hỗ trợ của Business Messages, hãy lưu ý các phương pháp hay nhất sau.
Đừng cung cấp hoặc yêu cầu thông tin nhạy cảm
Việc tránh nội dung nhạy cảm trong khi trò chuyện sẽ giúp bảo vệ thông tin của bạn và khách hàng. Thông tin nhạy cảm bao gồm nhưng không giới hạn ở:
- Số thẻ tín dụng
- Số an sinh xã hội, số hộ chiếu hoặc số định danh khác do chính phủ cấp
- Thông tin đăng nhập, chẳng hạn như mật khẩu
Nhanh chóng phản hồi người dùng
Thời gian phản hồi chậm hoặc không hợp lý đối với tin nhắn của người dùng sẽ khiến khách hàng có trải nghiệm không tốt. Hãy đảm bảo rằng bạn thiết kế cơ sở hạ tầng phản hồi để luôn cung cấp phản hồi kịp thời cho tin nhắn của người dùng.
Tệ hơn cả việc phản hồi chậm là không phản hồi gì cả. Đảm bảo rằng người dùng luôn nhận được phản hồi cho tin nhắn của họ, bất kể tải tin nhắn của bạn. Ví dụ: nếu không có nhân viên trực tiếp, hãy gửi một thông báo tự động xác nhận với người dùng và cho biết thời gian ước tính để người dùng có thể nhận được phản hồi đầy đủ.
Google đo lường thời gian phản hồi (TTR) giữa các tin nhắn. Nếu nhân viên của một thương hiệu phản hồi người tiêu dùng chậm, Google sẽ xoá các nút nhắn tin của thương hiệu đó.
Khi hệ thống tự động không thể thực hiện yêu cầu, hãy chuyển sang con người
Người dùng sẽ cảm thấy khó chịu khi tính năng tự động hoá không phản hồi đúng cách. Đó là lý do tại sao tất cả các trợ lý khởi chạy từ điểm truy cập do Google quản lý (ngoại trừ điểm truy cập Google Ads) phải có người đại diện có thể xử lý các cuộc trò chuyện khi hệ thống tự động không thể xử lý. Trước khi ra mắt, bạn cần thiết lập loại tương tác của nhân viên hỗ trợ để bao gồm cả nhân viên hỗ trợ là con người.
Khi tính năng tự động hoá không thể thực hiện yêu cầu của người dùng hai lần liên tiếp, tốt nhất bạn nên gửi tin nhắn có đề xuất yêu cầu nhân viên hỗ trợ trực tiếp.
Khi người dùng nhấn vào đề xuất này, nhân viên hỗ trợ của bạn sẽ nhận được một sự kiện do nhân viên hỗ trợ trực tiếp yêu cầu. Nhân viên hỗ trợ của bạn phải phản hồi bằng cách chuyển cuộc trò chuyện sang một người đại diện để người dùng nhận được sự trợ giúp họ cần.
Nhân viên không cần phải làm việc 24/7. Đặt lịch làm việc của nhân viên hỗ trợ để người dùng biết thời điểm họ có thể nhận được phản hồi của nhân viên hỗ trợ.
Xác thực người dùng bằng OAuth
Để xác minh danh tính của người dùng và cung cấp thông tin được cá nhân hoá cho họ, hãy xác thực người dùng bằng các hệ thống phụ trợ thông qua OAuth. Tính năng xác thực bằng OAuth giúp nhân viên hỗ trợ nhanh chóng truy cập vào dữ liệu người dùng và ngăn người dùng hoặc nhân viên hỗ trợ đưa thông tin nhạy cảm (chẳng hạn như tên người dùng hoặc mật khẩu) vào cuộc trò chuyện. Xem bài viết Xác thực bằng OAuth.
Đo lường CSAT trong Business Messages
Business Messages đo lường Điểm hài lòng của khách hàng (CSAT) bằng các bản khảo sát ngay trong trải nghiệm nhắn tin. Để ngăn người dùng nhận nhiều bản khảo sát, hãy sử dụng chức năng khảo sát của Tin nhắn doanh nghiệp. Đừng triển khai các kỹ thuật đo lường CSAT của riêng bạn.
Xem tiếp chủ đề này
Không gửi tin nhắn không mong muốn hoặc không liên quan đến cuộc trò chuyện hiện tại. Ví dụ:
- Tin nhắn về một sản phẩm hoặc dịch vụ không liên quan đến yêu cầu ban đầu
- Tin nhắn lặp lại mà người dùng không phản hồi
- Tin nhắn quá dài hoặc sử dụng quá nhiều biểu tượng cảm xúc và URL
Tận dụng Mã vị trí khi có
Đối với các điểm truy cập dựa trên vị trí, thông báo có thể chứa placeId trong tải trọng ngữ cảnh. Bạn có thể tận dụng thông tin này để cung cấp thông tin mà người dùng có thể đang hỏi, chẳng hạn như kho hàng tại một vị trí cụ thể. placeId giúp xác định riêng một địa điểm trong cơ sở dữ liệu Google Địa điểm và trong Nền tảng Google Maps.
Ngay cả khi bạn chỉ khởi chạy bằng các điểm truy cập dựa trên vị trí, hãy nhớ triển khai một chiến lược cho các trường hợp không có placeId. Mặc dù không phổ biến, nhưng có một số trường hợp placeId, cùng với các dữ liệu theo ngữ cảnh khác, không được truyền đến webhook của bạn.
Triển khai các lần thử lại bằng thuật toán thời gian đợi luỹ thừa
Khi gọi bất kỳ API nào, lệnh gọi có thể không thành công do các vấn đề về cơ sở hạ tầng, quá tải dịch vụ, giới hạn QPS và các lỗi khác. Để khôi phục một cách linh hoạt từ các lệnh gọi API không thành công, hãy triển khai các lần thử lại với thời gian đợi luỹ thừa.
Khi sử dụng các lần thử lại với thời gian đợi luỹ thừa, cơ sở hạ tầng của bạn sẽ tự động
- Xác định lệnh gọi API không thành công
- Đặt thời lượng chờ ban đầu và số lần thử lại tối đa
- Tạm dừng trong thời gian chờ
- Thử lại lệnh gọi API
Đánh giá phản hồi của lệnh gọi API:
- Nếu thành công, hãy tiếp tục bước tiếp theo trong quy trình công việc
- Nếu không thành công, hãy tăng thời gian chờ và quay lại bước 3
- Nếu không thành công sau số lần thử lại tối đa, hãy chuyển sang trạng thái không thành công
Thời gian chờ lý tưởng và số lần thử lại tối đa lý tưởng sẽ khác nhau tuỳ theo trường hợp sử dụng. Xác định các con số này dựa trên yêu cầu về độ trễ của cơ sở hạ tầng và quy trình làm việc.
Kiểm tra các tin nhắn đến trùng lặp
Khi bạn kiểm tra và trả lời tin nhắn đến từ người dùng, hãy kiểm tra messageId và xác minh rằng bạn chưa nhận và trả lời tin nhắn đó trước đây.
Với các hệ thống phân tán, có hai cách gửi thông báo: tối đa một lần và ít nhất một lần. Với hệ thống "tối đa một lần", hệ thống sẽ gửi một thông báo một lần, nhưng nếu có lỗi mạng hoặc lỗi giao tiếp trong quá trình này, thì thông báo có thể không được nhận. Với hệ thống "ít nhất một lần", hệ thống có thể gửi một thông báo nhiều lần, nhưng thông báo có thể được nhận ngay cả khi có lỗi mạng hoặc lỗi giao tiếp.
Business Messages sử dụng hệ thống "ít nhất một lần". Mặc dù điều này có thể dẫn đến việc trùng lặp tin nhắn đến, nhưng bạn có thể dễ dàng loại bỏ tin nhắn trùng lặp bằng cách theo dõi các chuỗi messageId. Nếu bạn đã nhận được một thông báo, bạn có thể bỏ qua mọi thông báo khác mà bạn nhận được bằng cùng một messageId.