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 để cung cấp các thao tác hiệu quả và cụ thể cho người dùng trong giao diện người dùng trò chuyện. Các tác nhân có thiết kế tốt nhất giúp các tương tác tập trung, dễ hiểu và có cấu trúc giống như cuộc trò chuyện tự nhiên.
Tác nhân 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à cũng không nên bắt chước giao diện đó. Thay vào đó, các nhân viên hỗ trợ cần dựa vào các cuộc trò chuyện được tạo thủ công để giải quyết nhu cầu của người dùng bằng cách hướng dẫn họ thông qua các lời nhắc, lời khuyên và khả năng xử lý lỗi hiệu quả.
Tác nhân 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 nhất định. Người dùng phải giao tiếp được với nhân viên hỗ trợ một cách tự nhiên, giống như khi họ giao tiếp với người khác.
Để biết thêm thông tin về giao diện người dùng trò chuyện, hãy xem bài viết Giao diện người dùng trò chuyện và lý do nên sử dụng trò chuyện trực tiếp.
Kiểm tra khả 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ủa người dùng có thể nhận tin nhắn RCS. Gửi yêu cầu về khả năng để xác định các tính năng của thiết bị và điều chỉnh hoạt động tương tác của nhân viên hỗ trợ sao cho phù hợp. Chỉ tương tác với người dùng theo cách thiết bị của họ hỗ trợ. Nếu thiết bị của người dùng chưa bật RCS, hãy thiết lập phương thức giao tiếp 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
Việc bắt đầu một cuộc trò chuyện sẽ giúp người dùng có kỳ vọng về những việc họ có thể làm. Hãy bắt đầu các cuộc trò chuyện với lưu ý rõ ràng: thể hiện tính cách của nhân viên hỗ trợ, cung cấp thông tin ngay từ đầu mà người dùng quan tâm và chia sẻ về những việc nhân viên hỗ trợ có thể làm. Cung cấp cho người dùng các tùy chọn rõ ràng để tương tác với nhân viên hỗ trợ và tiếp tục trò chuyện.
Duy trì nhịp điệu tốt
Việc sử dụng nhiều loại thông tin trong cuộc trò chuyện giúp giữ người dùng gắn bó và tương tác với nhân viên hỗ trợ của bạn, nhưng hãy cẩn thận để không làm cho người dùng quá tải. Hãy giữ cho thông báo có độ dài hấp dẫn và dễ hiểu để người dùng có thể xem toàn bộ thông điệp cùng một lúc. Hình ảnh và thẻ thông tin có thể chiếm rất nhiều không gian màn hình, vì vậy hãy lưu ý đến mức độ người dùng cần cuộn để đọc toàn bộ thông điệp.
Sắp xếp 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ố tin nhắn, chẳng hạn như tin nhắn bao gồm phương tiện, sẽ mất nhiều thời gian hơn để xử lý so với các tin nhắn khác, chẳng hạn như tin nhắn chỉ văn bản. Để đảm bảo người dùng nhận được tin nhắn theo thứ tự bạn gửi, hãy đợi cho đến khi bạn nhận được phản hồi 200 OK cho tin nhắn trước khi gửi tin nhắn tiếp theo trong trình tự.
Phản hồi 200 OK xác nhận rằng nền tảng RBM đã nhận được thông báo và người dùng sẽ nhận được thông báo của bạn theo đúng thứ tự. Nếu bạn không đợi phản hồi 200 OK trước khi gửi một tin nhắn khác, thì người dùng có thể nhận được tin nhắn không theo thứ tự.
Kiểm tra thư đế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 được và trả lời tin nhắn trước đó.
Với hệ thống phân tán, có hai cách gửi thông báo: nhiều nhất là 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, bạn có thể không nhận được thông báo.
- Với hệ thống "ít nhất một lần", hệ thống có thể gửi thông báo nhiều lần, nhưng có thể nhận được thông báo ngay cả khi có lỗi mạng hoặc lỗi giao tiếp.
Google Cloud Pub/Sub sử dụng hệ thống "ít nhất một lần". Mặc dù việc này có thể dẫn đến việc
trùng lặp thư đến, nhưng bạn có thể dễ dàng loại bỏ các thư trùng lặp bằng cách
theo dõi các chuỗi messageId. Nếu đã nhận được một thư, bạn có thể bỏ qua mọi thư khác có cùng messageId.
Viết thông điệp rõ ràng và nhất quán
Gửi tin nhắn hấp dẫn và dễ hiểu. Văn bản thông điệp hiệu quả nhắc người dùng phản hồi và tính nhất quán trong phong cách, định dạng và tốc độ 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 khác sau đây khi tạo nội dung thư:
- Không tạo đường cụt. Mỗi câu trả lời đề xuất phải dẫn đến một chuỗi trò chuyện có ý nghĩa với người dùng.
- Nếu cần, đề cập đến 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 thay vì viết hoa chữ cái đầu tiên của mỗi từ. Ví dụ: "Báo cáo tài khoản" chứ không phải "Báo cáo tài khoản".
- Sử dụng tính năng thu hẹp. "Nó" mang tính trò chuyện nhiều hơn là "nó".
- Sử dụng dấu chấm than một cách thận trọng.
- 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", không phải "một, hai, ba".
Tôn trọng khi người dùng không muốn nhận thư
Khi người dùng cho biết họ muốn ngừng nhận tin nhắn từ nhân viên hỗ trợ của bạn, 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 hiểu khi nào người dùng trả lời "STOP" và phản ứng đúng cách. Nhân viên hỗ trợ của bạn cần nắm được nhiều cách để người dùng truyền đạt mong muốn ngừng nhận tin nhắn, bao gồm cả bất kỳ và mọi ngôn ngữ mà họ có thể sử dụng để truyền đạt mong muốn của mình.
Hãy tham khảo luật pháp và các phương pháp hay nhất dành cho quốc gia bạn đang hoạt động về cách phản hồi STOP và các lệnh bắt buộc khác. Ví dụ: tham khảo các phương pháp hay nhất về CTIA.
Giúp người dùng
Nhân viên hỗ trợ của bạn phải phản hồi thông báo HELP từ người dùng và hướng dẫn người dùng về các khả năng của nhân viên hỗ trợ. Một danh sách đơ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ũng có thể biến trải nghiệm người dùng kém thành một thông tin hữu ích.
Thử lại các lệnh thử với thời gian đợi luỹ thừa
Khi gọi bất kỳ API nào, bạn có thể gọi không thành công do các vấn đề về cơ sở hạ tầng, dịch vụ quá tải, 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 số lần thử lại bằng thuật toán thời gian đợi luỹ thừa.
Khi 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 thực hiện những việc sau:
- Xác định một 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ử gọi 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, tiếp tục với bước tiếp theo trong luồng công việc.
- Nếu không thành công, hãy tăng thời lượng chờ rồi quay lại bước 3.
- Nếu lỗi 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 lượng chờ lý tưởng và số lần thử lại tối đa lý tưởng sẽ khác nhau tùy theo trường hợp sử dụng. Xác định các số này dựa trên yêu cầu về độ trễ của cơ sở hạ tầng 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 phương tiện, văn bản và đề xuất trong một thư. Do đó, nội dung nghe nhìn không nên là thành phần duy nhất trong thẻ thông tin. Các câu trả lời đề xuất hoặc hành động đề xuất phải 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 theo chiều dọc
Thẻ thông tin theo chiều dọc hiển thị phương tiện ngang ở đầu thẻ. Phương tiện ngang phải 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 phải tôn trọng các tài nguyên của người dùng. Khi phương tiện ngang có tỷ lệ 2:1, độ phân giải tối ưu cho phương tiện là 1440x720 px với kích thước tệp tối đa được đề 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 và kích thước tối đa đề xuất là 100 kB.
Thẻ thông tin chi tiết theo chiều ngang
Thẻ đa phương tiện theo chiều ngang hiển thị nội dung nghe nhìn dọc ở bên trái hoặc bên phải thẻ. Phương tiện dọc phải có tỷ lệ cỡ ảnh là 3:4.
Khi gửi nội dung nghe nhìn cho người dùng, bạn phải tôn trọng các tài nguyên của người dùng. Khi nội dung nghe nhìn dọc có tỷ lệ 3:4, độ 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 đề xuất tối đa 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 tối đa đề xuất là 100 kB.
Băng chuyền thẻ thông tin chi tiết
Băng chuyền thẻ thông tin rất lý tưởng để duyệt qua nội dung hoặc nhiều tuỳ chọn, nhưng băng chuyền này chỉ được 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 nhất định và bạn nên thông báo cho người dùng lý do tại sao đó là lựa chọn tối ưu.
Các khối đề xuất bên dưới một băng chuyền sẽ chuyển tiếp hoặc xoay vòng cuộc trò chuyện. Khối đề xuất không được lặp lại các tuỳ 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 xuất hiện trong băng chuyền.
Phương tiện trong băng chuyền thẻ thông tin
Băng chuyền thẻ thông tin chi tiết hiển thị phương tiện ngang ở đầu thẻ rich. Phương tiện ngang trong băng chuyền phải có tỷ lệ khung hình 4:3.
Khi gửi nội dung nghe nhìn cho người dùng, bạn phải tôn trọng các 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, độ 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 với kích thước tệp đề xuất là 40 kB và kích thước tối đa đề xuất là 100 kB.
Câu trả lời và hành động đề xuất
Các phản hồi và hành động đề xuất trong một thẻ thông tin phải liên quan trực tiếp đến nội dung trong thẻ đó.
Các câu trả lời và hành động đề xuất trong danh sách khối nên là cách thúc đẩy hoặc chủ động chuyển hướ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 phản hồi nhân viên hỗ trợ của bạn theo cách có thể dễ dàng phản hồi. Trừ khi hành động tương tác yêu cầu phản hồi tự do, hãy sử dụng phản hồi được đề xuất. Các thao tác này dễ dàng xử lý hơn so với văn bản dạng tự do và cho phép tác nhân hướng cuộc trò chuyện đến một đường dẫn tối ưu.
Hành động đề xuất
Hành động đề xuất cho phép nhân viên hỗ trợ thực hiện thao tác trên thiết bị gốc và cung cấp trải nghiệm tích hợp chặt chẽ cho người dùng. Khi có liên quan, các hành động đề 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 choáng ngợp với các tùy chọn. Chỉ cung cấp các thao tác liên quan đến thông báo gần đây nhất và chỉ cung cấp càng nhiều thao tác càng tốt. Giới hạn số lượng hành động đề xuất và câu trả lời đề xuất cho những hành động hữu ích cho người dùng trong ngữ cảnh cụ thể.
Bản tóm tắt thiết kế
Việc thiết kế để trò chuyện, sử dụng và hiệu quả là những việc 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 người dùng đến quy trình làm việc tối ưu với các câu trả lời và hành động đề xuất. Khi sử dụng hình ảnh hoặc thẻ thông tin, nhân viên hỗ trợ phải duy trì một nhịp độ cho phép người dùng duy trì ngữ cảnh và đọc tin nhắn một cách dễ dàng.
Việc xem xét trải nghiệm người dùng và tránh các trường hợp phụ thuộc khi trò chuyện khi thiết kế tác nhân cho người dùng sẽ mang lại trải nghiệm tích cực và khiến họ sẵn sàng sử dụng lại tác nhân của bạn trong tương lai.