Các phương pháp hay nhất Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

Trang này cung cấp các phương pháp hay nhất để tạo trải nghiệm RCS cho Doanh nghiệp hiệu quả và hấp dẫn, bao gồm cả việc triển khai kỹ thuật và thiết kế đàm thoại.

Nguyên tắc kỹ thuật

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ủa người dùng có thể nhận tin nhắn RCS. Để xác định các chức năng của người dùng, hãy gửi một yêu cầu kiểm tra chức năng và điều chỉnh các hoạt động 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 thiết bị của người dùng không hỗ trợ RCS, hãy thiết lập một phương thức giao tiếp dự phòng bằng một kênh khác, chẳng hạn như SMS.

Tuân thủ kích thước tối đa của thư

Có giới hạn về kích thước tối đa của một tin nhắn RCS cho doanh nghiệp và tệp đa phương tiện mà tin nhắn đó có thể chứa. Hãy xem phần Kích thước tối đa của thư để biết thông tin chi tiết.

Ngăn chặn việc gửi thư trùng lặp

Để tránh gửi trùng lặp tin nhắn cho người dùng, trước tiên, hệ thống của bạn phải xác nhận rằng một tin nhắn chưa được gửi trước khi thử chuyển sang SMS.

Hãy làm theo các phương pháp hay nhất này để cải thiện độ tin cậy của hệ thống và ngăn chặn các thông báo trùng lặp:

• Đặt thời gian tồn tại của nhóm kết nối sao cho phù hợp với thời gian tồn tại (TTL) của DNS: Sử dụng nhóm kết nối và đối tượng máy khách để sử dụng lại các kết nối và đối tượng máy khách hiện có. Để tránh sử dụng địa chỉ IP cũ sau khi cập nhật DNS, hãy đặt thời gian tối đa mà một kết nối hoặc đối tượng vẫn còn trong nhóm sao cho phù hợp với thời gian DNS của API để hoạt động.
• Đừng cho rằng hết thời gian chờ kết nối có nghĩa là thất bại: Đừng cho rằng hết thời gian chờ kết nối có nghĩa là tin nhắn RCS cho doanh nghiệp không được gửi. Thư có thể vẫn đang được xử lý ở phía máy chủ.
• Xác minh biên nhận gửi: Luôn kiểm tra biên nhận gửi trước khi kích hoạt thông báo dự phòng.
• Điều chỉnh TTL cho phù hợp với thời gian chờ kết nối: Bất cứ khi nào có thể, hãy đặt TTL của thông báo sao cho phù hợp với thời gian chờ kết nối.
• Thu hồi tin nhắn trước khi chuyển sang SMS dự phòng: Luôn cố gắng thu hồi tin nhắn gốc trước khi gửi SMS dự phòng. Nếu quá trình thu hồi không thành công, hãy xử lý lỗi này vì điều này có thể cho thấy thông báo đã được gửi đến người dùng.
• Thử lại khi gửi thư: Nếu thư không gửi được do lỗi có thể thử lại hoặc hết thời gian chờ kết nối, hãy thử lại thao tác gửi. Sử dụng messageID ban đầu để ngăn chặn các bản sao và triển khai thuật toán đợi luỹ tuyến để giãn cách các lần thử.

Kiểm tra xem có tin nhắn đến nào bị trùng lặp hay không

Khi bạn kiểm tra và trả lời tin nhắn đến của 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 đó.

Với các hệ thống phân tán, có 2 cách gửi thông báo:

• Tối đa một lần: Hệ thống gửi thông báo một lần, nhưng nếu có lỗi về 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.
• Í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 vẫn có thể nhận được ngay cả khi có lỗi về 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ù điều này có thể dẫn đến việc nhận được tin nhắn trùng lặp, 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, thì bạn có thể yên tâm bỏ qua mọi thông báo khác mà bạn nhận được có cùng messageId.

Sử dụng mã nhận dạng riêng biệt cho tất cả các thông báo gửi đi

Khi nhân viên hỗ trợ gửi tin nhắn cho người dùng, messageId mà bạn đưa vào lệnh gọi API phải là duy nhất cho mỗi tin nhắn.

Quan trọng: Vì mỗi mã nhận dạng thư đều là duy nhất, nên bạn không được dùng lại mã nhận dạng thư cho các thư khác nhau. Nền tảng RCS cho doanh nghiệp sẽ trả về lỗi 409 ALREADY_EXISTS nếu bạn tìm cách gửi một tin nhắn mới bằng mã nhận dạng đã được sử dụng. Để biết thêm thông tin, hãy tham khảo tài liệu tham khảo về API.

Để biết thêm thông tin về cách nhận thông báo, hãy xem phần Xử lý các sự kiện đến.

Không sử dụng địa chỉ IP cũ

Hệ thống của bạn phải luôn sử dụng địa chỉ IP chính xác và mới nhất khi kết nối với RBM API. Nhiều nền tảng lập trình sử dụng thời gian chờ mặc định của bộ nhớ đệm DNS, có thể dài hơn đáng kể so với chế độ cài đặt TTL của DNS của Google. Điều này có thể khiến hệ thống của bạn cố gắng kết nối với các địa chỉ IP đã hết hạn, dẫn đến hết thời gian chờ. TTL bộ nhớ đệm DNS miền RBM là 300 giây.

Để đảm bảo logic kết nối của bạn tuân thủ TTL 300 giây của chúng tôi, hãy làm theo các bước sau.

1. Điều chỉnh thời gian chờ của nhóm kết nối cho phù hợp với TTL: Nếu bạn sử dụng nhóm kết nối hoặc đối tượng máy khách, hãy đặt thời gian tồn tại tối đa của nhóm này thành 300 giây (hoặc ít hơn). Thao tác này buộc hệ thống tìm nạp một địa chỉ IP mới khi đối tượng được làm mới.
2. Đảm bảo làm mới DNS: Xác nhận rằng nền tảng hoặc thư viện ứng dụng HTTP của bạn được thiết lập để làm mới bộ nhớ đệm DNS sau mỗi 300 giây hoặc ít hơn.
3. Kiểm tra TTL hiện tại: Bạn nên kiểm tra TTL miền RBM API theo phương thức lập trình để đảm bảo bạn đang sử dụng giá trị tối đa chính xác. Bạn cần kiểm tra miền tương ứng với khu vực triển khai của mình:

dig +nocmd +noall +answer +ttlid A us-rcsbusinessmessaging.googleapis.com | sort dig +nocmd +noall +answer +ttlid A asia-rcsbusinessmessaging.googleapis.com | sort dig +nocmd +noall +answer +ttlid A europe-rcsbusinessmessaging.googleapis.com | sort

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, có thể một lệnh gọi sẽ không thành công do các vấn đề về cơ sở hạ tầng, tình trạ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 suôn sẻ 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 thực hiện những việc sau:

1. Xác định một lệnh gọi API không thành công.
2. Đặt thời gian chờ ban đầu và số lần thử lại tối đa.
3. Tạm dừng trong khoảng thời gian chờ.
4. Thử lại lệnh gọi API.

5. Đá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 với 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ờ và quay lại bước 3.
   • Nếu thất bại sau số lần thử lại tối đa, hãy chuyển sang trạng thái thất bại.

Khoả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 những con số này dựa trên cơ sở hạ tầng và yêu cầu về độ trễ của quy trình công việc.

Tối ưu hoá hiệu suất API bằng các điểm cuối theo khu vực

Cách tối ưu hoá hiệu suất API để giảm độ trễ:

• Sử dụng các điểm cuối gần nhất với khu vực của người dùng.

  Bảng sau đây đưa ra các đề xuất về việc sử dụng điểm cuối RBM theo khu vực, tuỳ thuộc vào số điện thoại của người dùng.

  Tiền tố số điện thoại Điểm cuối được đề xuất Khu vực địa lý +1 us-rcsbusinessmessaging.googleapis.com Châu Mỹ +2 europe-rcsbusinessmessaging.googleapis.com Châu Âu +3 europe-rcsbusinessmessaging.googleapis.com Châu Âu +4 europe-rcsbusinessmessaging.googleapis.com Châu Âu +5 us-rcsbusinessmessaging.googleapis.com Châu Mỹ +6 asia-rcsbusinessmessaging.googleapis.com Châu Á +7 europe-rcsbusinessmessaging.googleapis.com Châu Âu +8 asia-rcsbusinessmessaging.googleapis.com Châu Á +9 asia-rcsbusinessmessaging.googleapis.com Châu Á Mặc định us-rcsbusinessmessaging.googleapis.com Châu Mỹ

• Hãy cân nhắc việc đặt máy chủ gần điểm cuối đã chọn.

  Hãy truy cập vào https://www.google.com/about/datacenters/locations/ để xem các trung tâm dữ liệu của Google.

Để biết thêm thông tin về cách xác định khu vực của trợ lý ảo, hãy xem tài liệu Tạo trợ lý ảo.

Giao diện người dùng đàm thoại và trải nghiệm người dùng

Giao diện người dùng đàm thoại, không phải giao diện người dùng ứng dụng

Các nhân viên RCS cho doanh nghiệp rất phù hợp để cung cấp các tác vụ hiệu quả và cụ thể cho người dùng trong giao diện người dùng đàm thoại. Những trợ lý ảo được thiết kế tốt nhất sẽ giúp các hoạt động 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.

Các 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à không nên cố gắng bắt chước giao diện đó. Thay vào đó, các tác nhân cần dựa vào những cuộc trò chuyện được thiết kế cẩn thận để đáp ứng nhu cầu của người dùng 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à khả năng xử lý lỗi hiệu quả.

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 việc người dùng trả lời bằng một số đại diện cho một hành động nhất định. Người dùng có thể giao tiếp với các nhân viên một cách tự nhiên, giống như cách họ giao tiếp với người khác trong một cuộc trò chuyện.

Bắt đầu cuộc trò chuyện

Khi bắt đầu một cuộc trò chuyện, người dùng sẽ kỳ vọng về những việc mà nhân viên hỗ trợ có thể làm. Hãy bắt đầu cuộc trò chuyện một cách hiệu quả: thể hiện cá tính của nhân viên hỗ trợ, cung cấp trước thông tin mà người dùng quan tâm và chia sẻ những việc mà nhân viên hỗ trợ có thể làm. Cung cấp cho người dùng các lựa chọn rõ ràng để tương tác với trợ lý ảo và tiếp tục cuộc trò chuyện.

• Thể hiện cá tính của trợ lý ảo: Đặt tông giọng bằng cách chào người dùng và giới thiệu thương hiệu của bạn. Nếu bạn tạo một nhân vật cho tác nhân, chẳng hạn như trợ lý ảo hoặc nhân viên hỗ trợ kỹ thuật số, hãy cho biết rõ rằng đó là một chatbot chứ không phải người thật. Bạn có thể đặt tên cho trợ lý ảo sao cho phù hợp với tính cách. Hình đại diện là một cách tuyệt vời để củng cố hình ảnh của bạn. Đó có thể là biểu trưng của bạn, nhưng một nhân vật đồ hoạ theo phong cách hoạt hình cũng rất phù hợp.

  Lưu ý: Không sử dụng hình ảnh người thật để đại diện cho chatbot; điều này có thể gây hiểu lầm.

• Chia sẻ những việc mà nhân viên hỗ trợ có thể làm: Một tin nhắn chào hỏi hiệu quả sẽ giúp khách hàng hiểu rõ về nội dung của cuộc trò chuyện. Nội dung này giải thích các chức năng của trợ lý ảo ở cấp độ tổng quát. Tính năng này cũng bao gồm câu trả lời đề xuất và hành động để hướng dẫn người dùng đi theo các lộ trình cụ thể. Hãy sử dụng những đề xuất này để giúp người dùng điều hướng cuộc trò chuyện và hiểu rõ những việc mà tác nhân có thể hỗ trợ.

Viết thông điệp rõ ràng và nhất quán

Gửi những thông điệp dễ hiểu và dễ phản hồi đối với người dùng. Tạo văn bản tin nhắn nhắc người dùng phản hồi. Duy trì phong cách, định dạng và tốc độ nhất quán để tạo dựng niềm tin với người dùng.

Hãy lưu ý 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 ra những ngõ cụt. Mỗi thông báo phải dẫn đến một bước tiếp theo có ý nghĩa.

  • Nếu hành trình của người dùng có một tác vụ gồm nhiều bước, hãy sử dụng các dấu hiệu diễn ngôn để hướng dẫn người dùng thực hiện quy trình.

  Ví dụ: Now…, And…, Got it! Bạn xem nhé…

  • Hãy viết ngắn gọn vì câu trả lời đề xuất và hành động có tối đa 25 ký tự.
  • Nếu cuộc trò chuyện có yêu cầu chuyển giao, thì việc xác nhận nhanh có thể giúp quá trình chuyển giao diễn ra suôn sẻ.

  Ví dụ: "Được thôi. Người quản lý tài khoản của bạn sẽ tiếp tục từ đây."

  Ví dụ: "Tuyệt vời! Tôi nghĩ tôi biết bạn đang tìm gì" và cung cấp đường liên kết đến trang web của bạn.

• Xác nhận tin nhắn của người dùng bằng một từ hoặc cụm từ nhận dạng.

  Ví dụ: "Lựa chọn tuyệt vời!", "OK", "Được" hoặc "Hiểu rồi".

• Trực tiếp đề cập đến người dùng bằng tên của họ (nếu biết) hoặc đại từ nhân xưng "bạn". Tránh đề cập đến người dùng là "tôi" hoặc "mình", vì điều này có thể gây nhầm lẫn.

• Đối với tiêu đề và nhãn, hãy sử dụng cách viết hoa đầu câu, chứ không phải cách viết hoa chữ cái đầu.

  Ví dụ: "Account statement" (Bảng sao kê tài khoản), chứ không phải "Account Statement" (Bảng sao kê tài khoản).

• Sử dụng từ viết tắt, ngay cả đối với những trợ lý có giọng điệu nghiêm túc hoặc trang trọng.

  Ví dụ: "it's" mang tính trò chuyện hơn "it is".

• Hạn chế sử dụng dấu chấm than.

• Sử dụng dấu phẩy nối tiếp, tức là "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".

• Khi sử dụng biểu tượng cảm xúc, hãy đảm bảo giọng điệu vui tươi phù hợp với trường hợp sử dụng.

  Ví dụ: những người dùng đang đặt xe kéo hoặc tra cứu kết quả kiểm tra sức khoẻ có thể không muốn xem quảng cáo.

Sắp xếp tin nhắn theo thứ tự

Nếu bạn gửi nhiều thông báo liên tiếp, thì điều quan trọng là người dùng phải nhận được các thông báo đó theo thứ tự. Tin nhắn có nội dung nghe nhìn mất nhiều thời gian xử lý hơn tin nhắn chỉ có văn bản. Để đảm bảo người dùng nhận được tin nhắn theo đúng thứ tự, hãy đợ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 chuỗi.

Tạo cuộc trò chuyện hấp dẫn bằng câu trả lời và hành động đề xuất

Câu trả lời đề xuất và hành động là những công cụ mạnh mẽ giúp hướng dẫn và nâng cao các cuộc trò chuyện của người dùng. Các đề xuất này có thể xuất hiện sau một tin nhắn hoặc thẻ đa phương tiện và đưa ra các lựa chọn để tiếp tục hoặc thay đổi chủ đề của cuộc trò chuyện.

• Câu trả lời đề xuất: Giúp người dùng nhanh chóng phản hồi nhân viên hỗ trợ của bạn bằng cách cung cấp các lựa chọn được xác định trước. Sử dụng câu trả lời gợi ý bất cứ khi nào có thể, đặc biệt là khi bạn muốn có câu trả lời cụ thể.

  

• Hành động đề xuất: Cho phép tác nhân tích hợp với các tính năng của thiết bị, giúp đơn giản hoá các tác vụ như gọi điện cho bộ phận hỗ trợ hoặc tìm địa điểm.

Hãy làm theo những điểm cần cân nhắc chính sau đây để tạo ra các cuộc trò chuyện hấp dẫn và hiệu quả hơn:

• Mức độ liên quan: Đảm bảo các đề xuất phù hợp với cuộc trò chuyện hiện tại.
• Tính súc tích: Giới hạn số lượng đề xuất để tránh làm người dùng cảm thấy quá tải.
• Rõ ràng: Sử dụng ngôn từ rõ ràng và súc tích cho văn bản đề xuất.

Lưu ý: Trong thẻ đa phương tiện, các câu trả lời và hành động được đề xuất phải liên quan trực tiếp đến nội dung trong thẻ đó.

Giúp người dùng

Nhân viên hỗ trợ của bạn phải phản hồi tin nhắn HELP (TRỢ GIÚP) của người dùng và hướng dẫn họ về các chức năng của nhân viên hỗ trợ. Danh sách các câu trả lời đề xuất phù hợp với khả năng của trợ lý ảo có thể biến trải nghiệm người dùng kém thành trải nghiệm hữu ích.

Đảm bảo biểu trưng và hình ảnh chính của bạn hiển thị rõ ràng

• Chừa đủ khoảng trống xung quanh biểu trưng để có thể cắt và duy trì tính toàn vẹn về mặt hình ảnh.
• Tránh kéo giãn hoặc bóp méo biểu trưng hoặc hình ảnh chính vì việc này có thể ảnh hưởng tiêu cực đến nhận thức về thương hiệu.
• Kiểm thử biểu trưng và hình ảnh chính ở cả chế độ sáng và tối để có khả năng hiển thị và tính thẩm mỹ tối ưu.

Để biết thêm tài nguyên giúp bạn thiết kế biểu trưng hoặc khắc phục vấn đề, hãy xem Nguyên tắc thiết kế biểu trưng.

Biểu trưng

• Thiết kế biểu trưng theo hướng cắt hình tròn để duy trì sự cân bằng và rõ ràng.
• Đặt biểu trưng ở giữa hình ảnh để tránh các vấn đề về việc cắt hình ảnh.
• Đối với biểu trưng có nền trong suốt, hãy đảm bảo có đủ độ tương phản so với cả nền sáng và nền tối để phù hợp với chế độ tối. Nếu không chắc chắn, hãy sử dụng nền trắng đồng nhất.

Hình ảnh chính

• Sử dụng tỷ lệ khung hình 45:14 để tránh bị cắt không mong muốn.

Hãy cân nhắc việc chồng chéo biểu trưng khi thiết kế hình ảnh chính để các phần tử chính không bị che khuất.

Tôn trọng khi người dùng không muốn nhận tin nhắn

Duy trì lòng tin của người dùng có nghĩa là bạn phải tôn trọng lựa chọn ưu tiên của họ về thông tin liên lạc. Khi người dùng cho biết họ muốn ngừng nhận tin nhắn, nhân viên hỗ trợ của bạn phải tôn trọng lựa chọn của họ. Điều này bao gồm việc hiểu và phản hồi một cách thích hợp đối với nhiều cách thể hiện việc chọn không nhận, chẳng hạn như "DỪNG", bằng tất cả các ngôn ngữ có liên quan.

Tham khảo luật pháp và các phương pháp hay nhất dành cho quốc gia mà bạn hoạt động về cách phản hồi lệnh "STOP" và các lệnh bắt buộc khác.

Ví dụ: hãy tham khảo các phương pháp hay nhất của CTIA.

Xử lý sự kiện Huỷ đăng ký và Đăng ký

Lưu ý quan trọng: Mặc dù giao diện người dùng để huỷ đăng ký/đăng ký đang được triển khai trong chương trình Thử nghiệm công khai của Google Tin nhắn, nhưng các sự kiện webhook cho UNSUBSCRIBE và SUBSCRIBE hiện chưa có. Chúng tôi hiện đang chia sẻ tài liệu này để các đối tác có thể hiểu cách hoạt động của tính năng này và chuẩn bị cho bản phát hành đầy đủ trong một bản cập nhật trong tương lai.

Ứng dụng Google Tin nhắn tích hợp sẵn các tính năng Huỷ đăng ký và Đăng ký, giúp người dùng kiểm soát các cuộc trò chuyện của họ. Khi người dùng chọn huỷ đăng ký, tác nhân của bạn sẽ nhận được một sự kiện webhook UNSUBSCRIBE. Sự kiện SUBSCRIBE cho biết ý định của người dùng là tương tác lại với nhân viên hỗ trợ của bạn.

Để biết thông tin chi tiết về cách xử lý các sự kiện Huỷ đăng ký và Đăng ký lại, bao gồm cả thông tin chi tiết về tải trọng, quy tắc kinh doanh và ví dụ, hãy tham khảo tài liệu về Sự kiện do người dùng tạo.

Xử lý yêu cầu chọn không hiển thị

Nền tảng RCS cho doanh nghiệp không cung cấp cách thức trực tiếp để quản lý danh sách chọn không nhận của người dùng. Bạn có trách nhiệm duy trì cơ sở dữ liệu riêng về những người dùng đã chọn ngừng nhận tin nhắn thông qua việc huỷ đăng ký hoặc các hình thức chọn không nhận khác.

Tiếp tục cuộc trò chuyện

Nếu xoá cuộc trò chuyện với trợ lý ảo, người dùng phải bắt đầu lại việc liên hệ thông qua một kênh khác, chẳng hạn như lựa chọn tham gia trên trang web, mã SMS ngắn hoặc cơ chế đồng ý khác. Tương tác mới này cho thấy họ đã gia hạn sự quan tâm đến việc nhận tin nhắn.