Giao diện người dùng trò chuyện, không phải giao diện người dùng ứng dụng
Nhân viên hỗ trợ RBM rất phù hợp để giúp người dùng thực hiện công việc cụ thể và hiệu quả trong giao diện người dùng trò chuyện. Nhân viên hỗ trợ được thiết kế tốt nhất giúp duy trì tương tác tập trung, dễ hiểu và có cấu trúc như một cuộc trò chuyện tự nhiên.
Nhân viên hỗ trợ không thể dựa vào giao diện người dùng trực quan của một ứng dụng hoặc trang web và không được bắt chước nội dung đó. Thay vào đó, các nhân viên hỗ trợ cần dựa vào quy trình các cuộc trò chuyện đề cập đến người dùng nhu cầu của họ bằng cách hướng dẫn họ bằng các tín hiệu bằng lời nói, đề xuất và xử lý lỗi tốt.
Nhân viên hỗ trợ cũng không được bắt chước cây điện thoại hoặc giao diện dựa vào người dùng phản hồi bằng một số đại diện cho một hành động đã cho. Người dùng phải có thể để giao tiếp với nhân viên hỗ trợ một cách tự nhiên, giống như cách họ giao tiếp với một người khác trong cuộc trò chuyện.
Để biết thêm thông tin về giao diện người dùng trò chuyện, hãy xem Giao diện người dùng trò chuyện và lý do nên thiết lập giao diện này rất quan trọng.
Kiểm tra các chức năng của thiết bị
Trước khi bắt đầu cuộc trò chuyện với người dùng, hãy xác minh rằng thiết bị có thể nhận tin nhắn RCS. Gửi một yêu cầu chức năng để xác định các khả năng của thiết bị rồi điều chỉnh tương tác của nhân viên hỗ trợ cho phù hợp. Chỉ tương tác với người dùng theo những cách mà thiết bị của họ hỗ trợ. Nếu một thiết bị của người dùng chưa bật RCS, hãy thiết lập phương thức liên lạc dự phòng bằng một công nghệ khác, chẳng hạn như SMS.
Bắt đầu cuộc trò chuyện
Cách bắt đầu cuộc trò chuyện: đặt ra kỳ vọng của người dùng về những gì nhân viên hỗ trợ có thể làm. Bắt đầu cuộc trò chuyện bằng một ghi chú ấn tượng: thể hiện cá tính của nhân viên hỗ trợ, tải ngay thông tin mà người dùng quan tâm và chia sẻ về nhân viên hỗ trợ của bạn có khả năng. Cung cấp cho người dùng các lựa chọn rõ ràng để tương tác với nhân viên hỗ trợ và tiếp tục cuộc trò chuyện.
Tuân thủ kích thước tối đa của thư
RBM triển khai các giới hạn về kích thước tối đa của tin nhắn RBM và tệp nội dung nghe nhìn mà một thư có thể chứa. Các chi tiết này được ghi nhận trong Gửi tin nhắn .
Duy trì một nhịp điệu tốt
Việc sử dụng nhiều loại thông tin trong các cuộc trò chuyện sẽ giúp duy trì tương tác với người dùng và khi tương tác với nhân viên hỗ trợ, nhưng hãy cẩn thận để không làm người dùng bị choáng ngợp. Giữ lại thông điệp trong phạm vi thời lượng hấp dẫn, dễ hiểu để người dùng có thể thấy được toàn bộ thông báo trên màn hình cùng một lúc. Hình ảnh và thẻ thông tin chi tiết có thể chiếm không gian màn hình, vì vậy hãy lưu ý đến việc người dùng cần cuộn đến bao nhiêu đọc toàn bộ thư.
Giữ thư theo thứ tự
Nếu bạn gửi nhiều thư theo trình tự, điều quan trọng là người dùng phải nhận được
các thư đó theo thứ tự. Một số thông báo, chẳng hạn như những thông báo có nội dung nghe nhìn, hãy
lâu hơn các loại khác, chẳng hạn như tin nhắn chỉ có văn bản. Người nhận
hãy đảm bảo người dùng nhận được thư theo thứ tự bạn gửi
và đợi cho đến khi bạn
nhận được phản hồi 200 OK cho một tin nhắn trước khi gửi tin nhắn tiếp theo trong
trình tự.
Phản hồi của 200 OK xác nhận rằng nền tảng RBM đã nhận được tin nhắn và
người dùng sẽ nhận được thư của bạn theo đúng thứ tự. Nếu không
hãy đợi 200 OK phản hồi trước khi gửi một tin nhắn khác, người dùng có thể nhận được
tin nhắn của bạn không đúng thứ tự.
Kiểm tra các tin nhắn đến trùng lặp
Khi bạn kiểm tra và trả lời thư đến từ người dùng, hãy kiểm tra
messageId, rồi xác minh rằng bạn chưa nhận được
đã trả lời thư trước đó.
Với hệ thống phân phối, 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 "tối đa một lần" hệ thống, hệ thống sẽ gửi thông báo một lần, nhưng nếu có lỗi mạng hoặc lỗi liên lạc trong quá trình thực hiện, thông báo có thể không nhận được.
- Có cụm từ "ít nhất một lần" hệ thống có thể gửi thông báo, nhưng có thể nhận được tin nhắn ngay cả khi có mạng hoặc lỗi giao tiếp.
Google Cloud Pub/Sub sử dụng cụm từ "ít nhất một lần" hệ thống. Mặc dù việc này có thể dẫn đến
các tin nhắn đến trùng lặp, nên việc loại bỏ các tin nhắn trùng lặp rất dễ dàng bằng cách
theo dõi chuỗi messageId. Nếu bạn đã nhận được thư,
bạn có thể bỏ qua mọi thông báo bổ sung mà bạn nhận được cùng
messageId.
Viết thông điệp rõ ràng và nhất quán
Gửi thông điệp hấp dẫn và rõ ràng để người dùng hiểu được. Tốt thông điệp nhắc nhở người dùng trả lời và có tính nhất quán về phong cách, định dạng, và tốc độ của văn bản sẽ tạo dựng lòng tin với người dùng.
Hãy ghi nhớ các phương pháp hay nhất bổ sung sau đây khi tạo văn bản thông báo:
- Đừng tạo đường cụt. Mỗi câu trả lời đề xuất phải dẫn đến chuỗi trò chuyện với người dùng.
- Nếu cần, hãy gọi người dùng là "bạn", chứ không phải "tôi".
- Đối với tiêu đề và nhãn, hãy viết hoa đầu câu chứ không viết hoa chữ cái đầu tiên. Ví dụ: "Bảng sao kê tài khoản", không phải "Bảng sao kê tài khoản".
- Sử dụng tính năng thu gọn. "Đó là" mang tính trò chuyện hơn là "thực tế".
- Hạn chế sử dụng dấu chấm than.
- Hãy sử dụng dấu phẩy nối tiếp. Ví dụ: "A, B và C", chứ không phải "A, B và C".
- Viết số dưới dạng chữ số. Ví dụ: "1, 2, 3", chứ không phải "một, hai, ba".
Tôn trọng khi người dùng không muốn nhận thông báo
Khi người dùng cho biết rằng họ muốn ngừng nhận tin nhắn từ đại lý, bạn cần tôn trọng lựa chọn của họ. Nhân viên hỗ trợ của bạn phải biết khi nào người dùng trả lời "DỪNG" và phản ứng thích hợp. Nhân viên hỗ trợ của bạn nên hiểu rõ các những cách mà người dùng có thể truyền đạt rằng họ muốn ngừng nhận thông báo, bao gồm mọi ngôn ngữ mà họ có thể dùng để truyền đạt mong muốn của mình.
Hãy tham khảo luật và các phương pháp hay nhất dành cho quốc gia hoạt động của bạn để biết cách phản hồi lệnh STOP và các lệnh bắt buộc khác. Ví dụ: tham khảo CTIA các phương pháp hay nhất.
Giúp người dùng
Nhân viên hỗ trợ của bạn cần trả lời tin nhắn TRỢ GIÚP của người dùng và hướng dẫn người dùng về năng lực của nhân viên hỗ trợ. Nội dung đơn giản như danh sách các câu trả lời đề xuất tương ứng với chức năng của nhân viên hỗ trợ có thể mang lại trải nghiệm không tốt cho người dùng thành một thông tin hữu ích.
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ực hiện được do cơ sở hạ tầng sự cố, quá tải dịch vụ, giới hạn QPS và các lỗi khác. Để khôi phục dễ dàng từ các lệnh gọi API không thành công, hãy triển khai lượt thử lại bằng thuật toán thời gian đợi luỹ thừa.
Bằng cách sử dụng các lần thử lại bằng thuật toán thời gian đợi luỹ thừa, cơ sở hạ tầng của bạn sẽ tự động hoạt động như sau:
- Xác định lệnh gọi API không thành công.
- Đặt thời gian 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 chuyển sang bước tiếp theo trong quy trình.
- Nếu không thành công, hãy tăng thời gian chờ rồi quay lại bước 3.
- Nếu lỗi sau số lần thử lại tối đa, hệ thống sẽ 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 số liệu này dựa trên yêu cầu về độ trễ của cơ sở hạ tầng của bạn và quy trình công việc.
Thẻ thông tin
Thẻ thông tin cho phép bạn kết hợp nội dung nghe nhìn, văn bản và nội dung đề xuất trong một tin nhắn. Như chẳng hạn, nội dung đa phương tiện không nên là thành phần duy nhất trong thẻ thông tin và câu trả lời được đề xuất hoặc các hành động đề xuất nên luôn đi kèm với một thẻ thông tin chi tiết độc lập.
Thẻ thông tin chi tiết dạng dọc
Thẻ thông tin đa phương tiện dọc hiển thị nội dung nghe nhìn theo chiều ngang ở đầu thẻ. Ngang nội dung nghe nhìn nên có tỷ lệ khung hình là 2:1, 16:9 hoặc 7:3.
Khi gửi nội dung nghe nhìn cho người dùng, bạn nên tôn trọng tài nguyên của người dùng. Khi nội dung nghe nhìn ngang có tỷ lệ 2:1 thì độ phân giải tối ưu cho nội dung nghe nhìn là 1440x720 px với kích thước tệp tối đa đề xuất là 2 MB cho hình ảnh và 10 MB cho video. Độ phân giải tối ưu cho hình thu nhỏ của nội dung nghe nhìn là 770x335 px với kích thước tệp đề xuất là 40 kB kích thước tối đa là 100 kB.
Thẻ thông tin chi tiết theo chiều ngang
Thẻ thông tin đa phương tiện ngang hiển thị nội dung đa phương tiện theo chiều dọc ở bên trái hoặc bên phải của thẻ. Nội dung nghe nhìn dọc phải có tỷ lệ khung hình là 3:4.
Khi gửi nội dung nghe nhìn cho người dùng, bạn nên tôn trọng tài nguyên của người dùng. Khi nội dung nghe nhìn dọc có tỷ lệ 3:4 thì độ phân giải tối ưu cho nội dung nghe nhìn là 768x1024 px với kích thước tệp tối đa đề xuất là 2 MB cho hình ảnh và 10 MB cho video. Độ phân giải tối ưu cho hình thu nhỏ của nội dung nghe nhìn là 250x330 px với kích thước tệp đề xuất là 40 kB và kích thước đề xuất kích thước tối đa là 100 kB.
Băng chuyền thẻ thông tin chi tiết
Băng chuyền thẻ thông tin chi tiết lý tưởng để duyệt qua nội dung hoặc nhiều tùy chọn khác nhau, nhưng chúng chỉ nên sử dụng khi có nhiều mục cần đọc hoặc so sánh, chẳng hạn như gói dữ liệu hoặc thiết bị. Mục đầu tiên trong băng chuyền phải là lựa chọn tối ưu trong mọi tình huống và lý do cho việc đó là lựa chọn tối ưu cần được thông báo cho người dùng.
Các khối đề xuất bên dưới băng chuyền sẽ chuyển tiếp hoặc chuyển hướng cuộc trò chuyện. Khối đề xuất không được lặp lại những lựa chọn được liệt kê trong băng chuyền và không phải là công cụ lựa chọn cho các mục hiển thị trong băng chuyền.
Nội dung nghe nhìn trong băng chuyền thẻ đa dạng thức
Băng chuyền thẻ thông tin đa phương tiện hiển thị nội dung nghe nhìn theo chiều ngang ở đầu thẻ thông tin. Nội dung nghe nhìn ngang trong băng chuyền phải có tỷ lệ khung hình là 4:3.
Khi gửi nội dung nghe nhìn cho người dùng, bạn nên tôn trọng tài nguyên của người dùng. Khi nội dung nghe nhìn có tỷ lệ khung hình 4:3, thì độ phân giải tối ưu cho nội dung nghe nhìn là 960x720 px với kích thước tệp tối đa là 1 MB cho hình ảnh và 5 MB cho video. Độ phân giải tối ưu cho hình thu nhỏ của nội dung nghe nhìn là 605x452 px có kích thước tệp đề xuất là 40 kB và kích thước tối đa được đề xuất là 100 kB.
Câu trả lời đề xuất và hành động
Các câu trả lời và hành động đề xuất trong thẻ thông tin chi tiết phải liên quan trực tiếp đến nội dung trong thẻ đó.
Câu trả lời và hành động đề xuất trong danh sách khối phải là cách tiến hoặc việc xoay vòng cuộc trò chuyện.
Câu trả lời đề xuất
Câu trả lời đề xuất giúp người dùng trả lời nhân viên hỗ trợ của bạn theo cách mà có thể dễ dàng phản hồi. Trừ phi hoạt động tương tác yêu cầu phản hồi dạng tự do, hãy sử dụng câu trả lời đề xuất. Định dạng này dễ xử lý hơn văn bản dạng tự do và cho phép nhân viên hỗ trợ của mình để hướng các cuộc trò chuyện theo một lộ trình tối ưu.
Hành động đề xuất
Các thao tác đề xuất cho phép tác nhân kết nối với các thao tác gốc của thiết bị và cung cấp một trải nghiệm được tích hợp chặt chẽ cho người dùng. Khi phù hợp, hành động được đề xuất có thể giúp bạn dễ dàng gọi cho bộ phận hỗ trợ khách hàng hoặc tìm một vị trí trên bản đồ.
Nhưng đừng làm người dùng quá tải với các lựa chọn. Chỉ cung cấp các hành động liên quan đến thông báo gần đây nhất và chỉ đưa ra số hành động cần thiết. Giới hạn số lượng hành động được đề xuất và câu trả lời được đề xuất cho những thông tin hữu ích đối với người dùng trong ngữ cảnh cụ thể.
Tổng kết thiết kế
Thiết kế hướng đến cuộc trò chuyện, khả năng hữu dụng và hiệu quả là những yếu tố quan trọng nhất khi tạo nhân viên hỗ trợ. Nhân viên hỗ trợ nên tập trung vào giao diện người dùng trò chuyện và hướng dẫn người dùng thực hiện quy trình làm việc tối ưu bằng câu trả lời và hành động đề xuất. Thời gian bằng cách sử dụng hình ảnh hoặc thẻ thông tin, thì tác nhân phải duy trì nhịp điệu cho phép người dùng để giữ lại ngữ cảnh và đọc thư một cách dễ dàng.
Xem xét trải nghiệm người dùng và tránh tình trạng tắc nghẽn khi trò chuyện việc thiết kế nhân viên hỗ trợ mang lại cho người dùng trải nghiệm tích cực và khiến họ sẵn sàng sử dụng lại nhân viên hỗ trợ của bạn trong tương lai.