對話式 UI，而非應用程式 UI
RBM 代理程式非常適合用於向使用者提供高效率的特定工作。 對話式使用者介面這款設計最佳的服務專員 不僅聚焦、清楚易懂，且結構類似自然的對話
服務專員不能仰賴應用程式或網頁的視覺化 UI 試圖如實模仿相反地 對話中提到的使用者透過口語提示引導使用者需求 並提供良好的錯誤處理機制
此外，服務專員也不得模仿手機樹狀結構，或需要使用者的介面 以代表指定動作的數字回應。使用者可以 和服務專員進行自然通訊 對話中的另一個人。
如要進一步瞭解對話式 UI，請參閱「對話式 UI 和原因 案件：
檢查裝置功能
與使用者進行對話前，請先確認使用者的 裝置可接收 RCS 訊息。傳送 功能要求 辨識裝置的功能，以及調整代理程式的互動方式 。務必以使用者裝置支援的方式與使用者互動。如果 使用者的裝置未啟用 RCS。請設定備用的通訊方式 與其他技術 (例如簡訊) 通訊
發起對話
對話開頭有助使用者對服務專員的期望 信任關係以強烈附註開始對話：展現服務專員的個性 優先顯示使用者重視的資訊，並分享你的虛擬服務專員 所有功能為使用者提供清楚的代理程式互動選項，並 繼續對話
遵守訊息大小上限
RBM 設有 RBM 訊息和媒體檔案的大小上限 可包含的訊息這類修訂版本記錄在 傳送訊息 頁面。
維持良好的節奏
在對話中使用不同類型的資訊，可以提高使用者參與度並 與您的代理程式互動，但請注意不要讓使用者感到疲乏。保留 訊息，提供容易理解、易於理解的長度 畫面上的訊息圖片和複合式資訊卡會佔用大量儲存空間 因此請務必留意使用者需要捲動網頁 讀取整封郵件
依順序保留郵件
如果您依序傳送多則訊息，請務必讓使用者收到
依序排列這些訊息部分訊息 (例如含有媒體的訊息) 會
較其他格式 (例如純文字訊息) 的處理時間比較長目的地：
請確保使用者依照您傳送訊息的順序接收訊息，直到您
因為先收到訊息的 200 OK 回應，才在
序列
「200 OK」回應會確認 RBM 平台已收到訊息，且
，使用者會按正確順序收到你的訊息。如果您不
等 200 OK 回應再傳送其他訊息時，使用者可能會收到：
訊息排序錯誤
檢查是否有重複收到的郵件
檢查並回覆使用者傳送的訊息時，請檢查
messageId，並確認尚未收到，
已回覆訊息。
根據分散式系統，訊息傳送的方式有兩種：最多一次、 至少一次
- 「最多」一次系統會傳送訊息給一次訊息 如果過程中發生網路或通訊錯誤 可能無法接收。
- 「至少一次」系統可能會傳送訊息 多次，但即使有網路，仍可接收訊息 或通訊錯誤
Google Cloud Pub/Sub 會使用「至少一次」有些人會將 Cloud Storage 視為檔案系統
但實際上不是雖然這會導致
重複收到郵件，可以直接刪除重複的郵件。
追蹤 messageId 字串。如果您已經收到訊息
可以放心忽略先前收到的其他訊息
messageId。
撰寫清楚一致的訊息
傳送具吸引力且清楚易懂的訊息，讓使用者能夠理解。不錯 訊息文字可促使使用者做出回應 並確保內容格式、格式 文字速度和步調，能建立使用者的信任感
撰寫訊息文字時，請謹記以下其他最佳做法：
- 不要建立死路。每則建議回覆的內容都要有意義 與使用者相關的對話串
- 如有必要，將使用者稱呼「您」，而不是「我」。
- 標題和標籤應採用句首字母大寫格式，而非每字字首大寫。例如： 「帳戶對帳單」，而非「帳戶活動報表」。
- 使用縮寫。「現在是」語氣比「打開」更好
- 謹慎使用驚嘆號。
- 使用半形逗號。例如「A、B 和 C」，而非「A、B 和 C」。
- 將數字寫成數字。例如「1, 2, 3」，而不是「one, two, 3」。
在使用者不想要訊息的情況下尊重
使用者指出想要停止接收來自您的以下郵件時， 就必須尊重他們的選擇你的代理程式必須瞭解使用者 回覆「STOP」並採取適當的因應措施你的服務專員應該瞭解 使用者表達對於停止接收訊息的方法 包括他們能夠使用各種語言表達需求
請參閱所屬國家/地區的法律和最佳做法，瞭解如何 回應 STOP 和其他必要指令。舉例來說，請參閱 CTIA 最佳做法
協助使用者
您的服務專員應回覆使用者的「HELP」訊息，並向使用者說明 代理程式的功能類似建議回覆清單 對應至服務專員的功能可能會對使用者體驗造成負面影響 變成實用的範本
以指數輪詢方式實作重試
呼叫任何 API 時，可能會因為基礎架構而呼叫失敗 問題、服務超載、QPS 限制以及其他錯誤為了安全復原 ，以指數輪詢方式實作重試。
基礎架構會自動採用指數輪詢策略 包括：
- 識別失敗的 API 呼叫，
- 設定初始等待時間長度和重試次數上限。
- 等待期間會暫停。
- 重試 API 呼叫。
評估 API 呼叫回應：
- 如果成功，請繼續進行工作流程的下一個步驟。
- 如果失敗，請延長等待時間並返回步驟 3。
- 如果重試次數上限後失敗，就會進入失敗狀態。
理想的等待時間長度和重試次數上限會因用途而異。 請依據基礎架構的延遲時間需求判定數量 和工作流程
複合式資訊卡
複合式資訊卡可讓你在單一訊息中結合媒體、文字和建議。阿斯 因此不應成為複合式資訊卡的唯一元素和建議回覆 或建議動作應一律與獨立的複合式資訊卡一起顯示。
直向複合式資訊卡
直向互動式多媒體資訊卡會在資訊卡頂端顯示橫向媒體。橫式抽屜 媒體的顯示比例應為 2:1、16:9 或 7:3
傳送媒體給使用者時，應尊重使用者的資源。 當橫向媒體的比例為 2:1 時，媒體的最佳解析度為 1440 x 720 px，建議圖片檔案大小上限為 2 MB 影片則為 10 MB媒體縮圖的最佳解析度為 770x335 px，建議檔案大小為 40 KB 大小上限為 100 KB
水平複合式資訊卡
水平互動式多媒體資訊卡的左側或右側會顯示垂直媒體 資訊卡直向媒體的顯示比例應為 3:4。
傳送媒體給使用者時，應尊重使用者的資源。 當直向媒體的比例為 3:4 時，媒體的最佳解析度為 768 x 1024 px，建議圖片檔案大小上限為 2 MB 影片則為 10 MB媒體縮圖的最佳解析度為 250 x 330 px，建議檔案大小為 40 KB 大小上限為 100 KB
複合式資訊卡輪轉介面
複合式資訊卡輪轉介面是瀏覽內容或多樣選項的理想選擇， 。 數據方案或裝置。輪轉介面中的第一個項目是最佳選擇 以及為什麼最適合你的選擇 必須向使用者傳達
輪轉介面下方的建議方塊應可前進或引導對話。 建議方塊不應重複顯示輪轉介面中列出的選項， 並非適用於輪轉介面顯示項目的選取工具。
複合式資訊卡輪轉介面中的媒體
複合式資訊卡輪轉介面會在複合式資訊卡頂端顯示橫向媒體。 輪轉介面中的橫向媒體長寬比應為 4:3。
傳送媒體給使用者時，應尊重使用者的資源。 當媒體長寬比為 4:3 時，媒體的最佳解析度為 960 x 720 px，圖片檔案大小上限為 1 MB，且檔案大小上限為 5 MB 影片廣告。媒體縮圖的最佳解析度為 605x452 像素 建議的檔案大小為 40 KB，建議的大小上限為 100 KB。
建議的回覆和動作
複合式資訊卡中的建議回覆和操作應與 資訊卡的內容
方塊清單的建議回覆和動作應可繼續或 引導對話方向
建議的回覆
建議回覆功能可協助使用者以特定方式回覆服務專員 輕鬆回應除非互動需要任意形式的回應，否則請使用 建議回覆。比任意形式的文字更容易處理 服務專員將對話引導到最佳途徑。
建議採取的動作
建議採取的動作可讓代理程式連線至原生裝置動作，並提供 確保使用者享有緊密整合的使用體驗需要採取相關的建議動作 可讓你輕鬆致電客服中心，或在地圖上尋找地點。
但也不要提供多種選項，讓使用者感到不堪負荷。只提供與下列主題相關的動作 ，且只在必要時提供必要的動作。限制 最實用的建議動作和建議回覆 以及特定情境下的使用者資訊
設計總結
以對話、可用性和效率的設計而言，最重要的是 來建立虛擬服務專員服務專員應專注於對話式 UI 透過建議的回覆與動作，引導使用者完成最佳的工作流程。時間 使用圖片或複合式資訊卡時，服務專員應維持發布速度，讓使用者能夠視需要 來保留相關資料及輕鬆閱讀訊息。
考慮到使用者體驗，並避免在出現提示時 設計代理程式能為使用者提供良好體驗 日後會再次使用代理程式