對話式 UI，而非應用程式 UI
RBM 代理程式相當適合在對話使用者介面中提供使用者效率高的具體工作。最優秀的服務專員會聚焦於易於理解、易於理解，以及像自然對話這類的結構。
代理程式無法依賴應用程式或網頁的視覺化使用者介面，因此不應試圖模仿。相反地，代理程式需要仔細處理，並依據口頭提示、建議和良好錯誤處理來滿足使用者的需求。
代理程式也不得模仿手機樹狀結構，或是仰賴回應指定動作數字的介面。使用者應該要能自然而然地與服務專員進行通訊，就像在對話中與其他人溝通一樣。
如要進一步瞭解對話式 UI，請參閱「對話式 UI 和重要性」。
檢查裝置功能
與使用者開始對話之前，請先確認使用者裝置能接收 RCS 訊息。傳送功能要求來識別裝置的功能，然後據此調整代理程式的互動方式。只以支援裝置的方式與使用者互動。如果使用者的裝置未啟用 RCS，請設定備用方式與其他技術 (例如簡訊) 進行通訊。
發起對話
對話的開始，讓使用者能夠瞭解服務專員可執行哪些工作。在有強烈備忘的氛圍下開始對話：展示服務專員的個性、預先載入使用者重視的資訊，並分享服務專員提供的功能。提供明確的選項，讓使用者能與服務專員互動，並延續對話。
保持節奏良好
在對話中使用各種資訊可以吸引使用者參與您的服務專員並進行互動，但請務必小心，以免讓使用者感到疲乏。訊息應簡明扼要，讓使用者能一次在螢幕上看到完整訊息。圖片和複合式資訊卡可能會佔用大量螢幕空間，因此請留意使用者需要捲動多久才能讀取完整訊息。
妥善保存訊息
如果您依序傳送多則訊息，請務必讓使用者按照順序收到這些訊息。部分訊息 (例如包含媒體的訊息) 的處理時間較長，例如不含簡訊。為確保使用者能夠按您傳送的順序接收訊息，請等待訊息接收 200 OK 回應後再傳送下一則訊息。
200 OK 回應確認 RBM 平台已收到訊息，且使用者應按照正確順序接收訊息。如果您等到 200 OK 回應後才能再傳送其他訊息，使用者可能會無法順利訂購您的訊息。
檢查郵件是否重複
當您檢查及回覆使用者收到的訊息時，請檢查 messageId，並確認您還沒有收到並回覆訊息。
使用分散式系統時，有兩種傳送訊息的方式：最多一次，最少一次。
- 採用「最多一次」系統時，系統僅會傳送一次訊息，但如果過程中出現網路或通訊錯誤，則可能無法收到訊息。
- 使用「至少一次」系統時，系統可能會多次傳送訊息，但即使發生網路或通訊錯誤，也可能會收到訊息。
Google Cloud Pub/Sub 使用「至少一次」系統。儘管這會導致重複收到的訊息，但透過追蹤 messageId 字串，簡化訊息重複作業。即使您收到了訊息，仍可忽略所有使用相同 messageId 接收的訊息。
撰寫內容清楚明確
傳送兼具吸引力和簡單易懂的訊息。良好的訊息文字會提示使用者做出回應，且文字的樣式、格式和使用速度一致，有助於贏得使用者的信任。
建立訊息文字時，請牢記下列最佳做法：
- 不要建立死結。每項建議回覆都應與使用者進行有意義的對話串。
- 如有需要，將使用者稱為「您」而非「我」。
- 關於標題和標籤，請採用句首字母大寫格式，不要使用大寫。例如「帳戶對帳單」，而不是「帳戶對帳單」。
- 使用縮寫。「It's」並非對話性質。
- 請謹慎使用驚嘆號。
- 使用序號。例如「A、B 和 C」，而非「A、B 和 C」。
- 將數字寫成數字。例如「1, 2, 3」而非「one, two,三」。
使用者不想看到訊息時請尊重
如果使用者指出不想再收到您服務專員傳送的訊息，您必須尊重他們的選擇。代理程式必須瞭解使用者何時回覆「STOP」並正確回應。您的服務專員應瞭解使用者可能會想用哪些方式不繼續接收訊息，包括他們可能會用來傳達所需訊息的一切語言。
請參閱作業所在國家/地區的法律和最佳做法，瞭解如何回覆「STOP」和其他強制性指令。如需相關範例，請參閱 CTIA 最佳做法。
協助使用者
您的服務專員應回應來自使用者的 HELP 訊息，並向使用者說明您的服務專員功能。若是單純對應至服務專員功能的建議回覆清單，反而可能將使用者體驗不佳，轉變為實用的資訊。
以指數輪詢方式重試
呼叫任何 API 時，可能會因為基礎架構問題、服務超載、每秒查詢次數和其他錯誤而導致呼叫失敗。如要透過失敗的 API 呼叫順利復原，請使用指數輪詢實作重試。
使用指數輪詢搭配重試時，您的基礎架構會自動執行以下操作：
- 識別失敗的 API 呼叫。
- 設定初始等待時間長度和重試次數上限。
- 暫停，等待等候時間。
- 重試 API 呼叫。
評估 API 呼叫回應：
- 如果成功，請執行工作流程中的下一個步驟。
- 如果失敗，請增加等待時間並返回步驟 3。
- 如果重試次數已達上限，請輸入失敗狀態。
理想的等待時間，以及理想的重試次數會因用途而異。請根據基礎架構和工作流程的延遲時間要求來決定這些數據。
複合式資訊卡
複合式資訊卡可讓您將訊息、文字和建議合併成一則訊息。因此，媒體不應是複合式資訊卡中的唯一元素，而建議的回覆或建議行動也應做為獨立的複合式資訊卡。
垂直複合式資訊卡
垂直複合式資訊卡會在資訊卡頂端顯示橫向媒體。橫向媒體的長寬比必須為 2:1、16:9 或 7:3。
將媒體傳送給使用者時，請尊重他們的資源。 如果橫向媒體的顯示比例為 2:1，則媒體的最佳解析度為 1440x720 像素，圖片建議大小上限為 2 MB，而影片為 10 MB。媒體縮圖的最佳解析度為 770x335 px，建議的檔案大小為 40 KB，建議大小上限為 100 KB。
橫向複合式資訊卡
橫向複合式資訊卡會在資訊卡左側或右側顯示垂直媒體。垂直媒體的長寬比必須為 3:4。
將媒體傳送給使用者時，請尊重他們的資源。 直向媒體的長寬比為 3:4 時，媒體的最佳解析度為 768x1024 像素，建議圖片大小上限為 2MB，影片大小上限為 10 MB。媒體縮圖的最佳解析度為 250x330 px，建議的檔案大小為 40 KB，建議大小上限為 100 KB。
複合式資訊卡輪轉介面
複合式資訊卡輪轉介面最適合用於瀏覽內容或各種選項，但只有在有多個項目可供讀取或比較 (例如數據方案或裝置) 時，才應使用。在任何情況下，輪轉介面中的第一個項目應是最佳選擇，並應告知使用者這是最佳選擇的原因。
輪轉介面下方的建議方塊應向上或反轉對話。 建議方塊不應重複填入輪轉介面中列出的選項，也不要為輪轉介面中顯示的項目選取工具。
複合式資訊卡輪轉介面中的媒體
複合式資訊卡輪轉介面會在複合式資訊卡頂端顯示水平媒體。 輪轉介面中的橫向媒體長寬比應為 4:3。
將媒體傳送給使用者時，請尊重他們的資源。 當媒體的顯示比例為 4:3 時，媒體的最佳解析度為 960x720 px，圖片的檔案大小上限為 1MB，影片 5MB。媒體縮圖的最佳解析度為 605x452 px，建議的檔案大小為 40 KB，建議大小上限為 100 KB。
建議的回覆和動作
複合式資訊卡中的建議回覆和動作應與資訊卡中的內容直接相關。
方塊清單中的建議回覆和動作應是促進或調整對話的方法。
建議的回覆
建議回覆可以協助使用者回應服務專員，方便回覆。除非互動需要任何形式的回應，否則使用建議的回覆。形式比任意形式文字更容易處理，且可讓服務專員將對話轉化為最佳路徑。
操作建議
建議動作可讓代理程式擷取原生裝置動作，並為使用者提供緊密整合的體驗。在適當情況下，建議動作可以輕鬆致電客服人員，或在地圖上找到特定地點。
但是，別讓使用者擁有過多選項。請只提供與最新訊息相關的動作，並視需求提供最多的動作。在特定情況下，限制對使用者有幫助的建議動作和建議回覆數量。
設計總結
建立代理程式時，設計對話、可用性和效率最為重要。代理程式應專注於對話式 UI，並透過建議的回覆和動作引導使用者採用最佳工作流程。使用圖片或複合式資訊卡時，代理程式應維持節奏，讓使用者更輕鬆地保留結構定義及讀取訊息。
在設計代理程式時，請考量使用者體驗並避免對話倦怠，進而為使用者提供良好的使用體驗，讓他們日後再次使用您的服務專員。