RCS Business Messaging (RBM) 服務專員可透過訊息與使用者溝通， 事件，以及有助於達成業務目標的要求。這些目標 簡單 (例如傳送遞送通知) 或複雜 (例如預訂 虛擬服務專員會使用複合式資訊卡、媒體和建議來引導使用者 即時流暢對話，滿足使用者與服務專員的需求
運作方式
代理程式和使用者之間的對話流程與 兩人之間的對話，每一方輪流發言， 以及回應對方
你的 RBM 服務專員開啟了與使用者對話。使用者無法啟動 與代理程式對話，但服務專員發起對話後 使用者隨時都可回覆
代理程式會在收到外部觸發條件時傳送第一則訊息 每個 Pod 都有專屬的 IP 位址觸發條件可以是任何內容，視代理程式的用途而定：
- 包裹出貨
- 立刻送出午餐時間三明治特惠
- 使用者在即時通訊中與客戶服務團隊聯絡
代理程式收到觸發條件後，代理程式會傳送訊息 透過 RCS Business Messaging API 連線至使用者的裝置。服務專員會將所有訊息 透過 RBM API 以 HTTP 傳送的訊息、事件和其他要求 內含 JSON 酬載的要求使用者在「訊息」應用程式中收到訊息 在裝置上。
如果裝置不支援 RCS，RBM 平台會傳回 404 錯誤，且
服務專員應改用其他技術，如簡訊
當使用者回覆訊息或觸發 event、 Google 的 RBM 服務將回應傳送到 Webhook 然後將資訊傳回代理程式。Webhook 傳送 所有使用者訊息、事件，以及以 JSON 格式傳送至代理程式的其他要求。
服務專員收到訊息後， 解碼 JSON 並剖析回應使用內部邏輯或依賴 自然語言理解 (NLU) 模組，例如 Dialogflow 時，代理程式會決定 透過 RBM API 將回應傳送至使用者的裝置。
服務專員和使用者之間的對話會持續，直到觸及 或是使用者停止回應
範例
以下範例是一個簡單的情境，其中使用者要求取得天氣資訊 更新。
- 虛擬服務專員收到外部服務的觸發條件，表示 使用者要求取得最新天氣資訊。
- 您的代理程式會傳送訊息給使用者，確認使用者的要求並 要求取得使用者的位置
- 使用者在「訊息」應用程式中閱讀訊息，並回應 讓我們看看 DNS 解析 進一步探索內部和外部位址
- 代理程式會處理回應、擷取天氣資訊、 對話訊息，然後將相關資訊傳送給使用者。此外， 代理程式會詢問使用者是否也想使用其他的天氣資訊 或 HTTP/HTTPS 位置
- 使用者閱讀訊息並感謝服務專員。
- 您的代理程式確認使用者未要求其他資訊 並結束對話
加密
使用者和服務專員之間傳送的 RBM 訊息都會經過加密。 Google 伺服器，以及在 Google 伺服器和使用者裝置。合作夥伴無法使用 自己的加密金鑰，因為 Google 需要掃描郵件是否含有惡意內容 保障所有使用者和企業的安全。
如要進一步瞭解 RBM 資料安全性，請參閱 RCS Business Messaging 的資料安全性。
後續步驟
掌握這些概念後，請思考您想要 建立及建構第一個代理程式。