最佳做法

本頁面提供最佳做法，協助您打造有效且引人入勝的 RCS for Business 體驗，涵蓋技術實作和對話設計。

技術指南

檢查裝置功能

與使用者展開對話前，請先確認對方的裝置可以接收 RCS 訊息。如要判斷使用者能力，請傳送功能檢查，並據此調整代理程式的互動方式。請僅以裝置支援的方式與使用者互動。如果使用者的裝置未啟用 RCS，請設定透過其他管道 (例如簡訊) 通訊的備援方法。

遵守訊息大小上限

RCS for Business 訊息和內含媒體檔案的大小上限有所限制。詳情請參閱「郵件大小上限」。

避免傳送重複訊息

為避免重複傳送訊息給使用者，系統必須先確認訊息未送達，再嘗試改用簡訊傳送。

請遵循下列最佳做法，提升系統可靠性並避免重複訊息：

  • 將連線集區生命週期設為與 DNS 存留時間 (TTL) 相符：使用連線和用戶端物件集區，重複使用現有連線和用戶端物件。為避免在 DNS 更新後使用過時的 IP 位址，請將連線或物件保留在集區中的最長時間，設為與 API 的 DNS 存留時間相符。
  • 請勿假設連線逾時代表傳送失敗：請勿假設連線逾時代表 RCS for Business 訊息未傳送。伺服器端可能仍在處理郵件。
  • 確認送達回條：觸發備援訊息前，請務必先檢查送達回條。
  • 將存留時間與連線逾時時間相符：盡可能將訊息存留時間設為與連線逾時時間相符。
  • 在改用簡訊傳送前撤銷訊息：一律先嘗試撤銷原始訊息，再傳送備援簡訊。如果撤銷失敗，請處理失敗情形，因為這可能表示訊息已傳送給使用者。
  • 重試傳送訊息：如果訊息因可重試的錯誤或連線逾時而傳送失敗，請重試傳送作業。使用初始 messageID 可避免重複，並實作指數輪詢，拉長嘗試間隔。

檢查是否有重複的來電訊息

查看及回覆使用者傳來的訊息時，請檢查「messageId」，確認你尚未收到並回覆該訊息。

在分散式系統中，傳送訊息的方式有兩種：

  • 最多一次：系統會傳送一次訊息，但如果傳送過程中發生網路或通訊錯誤，訊息可能無法送達。
  • 至少一次：系統可能會多次傳送訊息，但即使發生網路或通訊錯誤，訊息仍可送達。

Google Cloud Pub/Sub 使用「至少一次」系統。雖然這可能會導致重複收到郵件，但只要追蹤 messageId 字串，就能輕鬆移除重複郵件。如果您已收到訊息，可以放心忽略任何含有相同 messageId 的額外訊息。

為所有外寄郵件使用專屬 ID

服務專員傳送訊息給使用者時，您在 API 呼叫中加入的 messageId 必須是每則訊息專屬的。

如要進一步瞭解如何接收訊息，請參閱「處理傳入的事件」。

請勿使用過時的 IP 位址

系統連線至 RBM API 時，一律須使用正確的最新 IP 位址。各種程式設計平台使用的預設 DNS 快取逾時時間，可能遠長於 Google 的 DNS TTL 設定，導致系統嘗試連線至過期的 IP 位址，進而發生逾時。RBM 網域 DNS 快取存留時間為 300 秒。

如要確保連線邏輯遵守 300 秒的 TTL，請按照下列步驟操作。

  1. 將連線集區逾時時間設為與 TTL 相符：如果您使用連線或用戶端物件集區，請將其生命週期上限設為 300 秒 (或更短)。這樣一來，系統會在物件重新整理時強制擷取新的 IP 位址。
  2. 確保 DNS 重新整理：確認平台或 HTTP 用戶端程式庫已設定為每 300 秒或更短時間重新整理 DNS 快取。
  3. 檢查目前的 TTL：建議以程式輔助方式檢查 RBM API 網域 TTL，確保您使用的是正確的最大值。請檢查與部署區域對應的網域：
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

實作指數輪詢重試

呼叫任何 API 時，呼叫可能會因基礎架構問題、服務過載、每秒查詢次數限制和其他錯誤而失敗。如要從 API 呼叫失敗中順利復原，請實作指數輪詢重試。

使用指數輪詢重試時，基礎架構會自動執行下列動作：

  1. 識別失敗的 API 呼叫。
  2. 設定初始等待時間和重試次數上限。
  3. 暫停等待時間。
  4. 重試 API 呼叫。

  5. 評估 API 呼叫回應：

    • 如果成功，請繼續工作流程中的下一個步驟。
    • 如果失敗，請增加等待時間，然後返回步驟 3。
    • 如果重試次數達到上限後仍失敗，就會進入失敗狀態。

理想的等待時間和重試次數上限會因用途而異。 根據基礎架構和工作流程延遲時間需求，決定這些數字。

使用區域端點提升 API 效能

如要提升 API 效能，縮短延遲時間，請採取下列做法：

  • 使用最接近使用者所在區域的端點。

    下表根據使用者的電話號碼，提供建議使用的區域 RBM 端點。

    電話號碼前置字元 建議端點 地理區域
    +1 us-rcsbusinessmessaging.googleapis.com 美洲
    +2 europe-rcsbusinessmessaging.googleapis.com 歐洲
    +3 europe-rcsbusinessmessaging.googleapis.com 歐洲
    +4 europe-rcsbusinessmessaging.googleapis.com 歐洲
    +5 us-rcsbusinessmessaging.googleapis.com 美洲
    +6 asia-rcsbusinessmessaging.googleapis.com 亞洲
    +7 europe-rcsbusinessmessaging.googleapis.com 歐洲
    +8 asia-rcsbusinessmessaging.googleapis.com 亞洲
    +9 asia-rcsbusinessmessaging.googleapis.com 亞洲
    預設 us-rcsbusinessmessaging.googleapis.com 美洲

  • 請考慮將伺服器設在所選端點附近。

    如要瞭解 Google 資料中心，請參閱 https://www.google.com/about/datacenters/locations/。

如要進一步瞭解如何識別代理程式的區域，請參閱「建立代理程式」說明文件。

對話式 UI 和使用者體驗

對話式 UI，而非應用程式 UI

RCS for Business 代理程式非常適合在對話式使用者介面中，為使用者提供有效率且具體的任務。設計完善的代理程式可讓互動專注於特定主題、清楚易懂，並以自然對話的形式進行。

代理程式無法依賴應用程式或網頁的視覺化 UI，也不應嘗試模仿。因此，服務專員必須透過精心設計的對話，以口頭提示、建議和良好的錯誤處理方式引導使用者，滿足他們的需求。

代理程式也不應模仿電話樹狀結構，或依賴使用者輸入代表特定動作的數字。使用者應能像與他人對話一樣，自然地與代理程式溝通。

發起對話

對話的開頭會決定使用者對代理程式功能的期望。因此，請以強而有力的開場白展開對話：展現代理程式的個性、優先提供使用者關心的資訊，並說明代理程式的功能。為使用者提供清楚的選項，讓他們與代理互動及繼續對話。

  • 展現商家 AI 專員的個性：向使用者打招呼並介紹品牌，藉此設定語氣。如果為代理程式建立虛擬助理或數位服務人員等角色，請明確指出這是聊天機器人，而非真人。您可以設定與角色相符的代理名稱。虛擬化身是強化個人形象的好方法。可以是標誌，但卡通風格的圖像角色也很適合。

  • 說明代理程式的功能：好的問候訊息應清楚說明對話可提供的服務。這份文件會概略說明代理程式的功能，此外，還包括建議的回覆和動作，引導使用者完成特定路徑。使用這些建議，協助使用者瀏覽對話，並瞭解代理程式可協助執行的工作。

含有建議回覆的訊息

撰寫清楚一致的訊息

傳送使用者容易理解及回覆的訊息。撰寫訊息內容，提示使用者回覆。維持一致的風格、格式和步調，建立使用者的信任感。

建立訊息文字時，請注意下列其他最佳做法：

  • 請勿建立死胡同。每則訊息都應引導使用者採取有意義的下一步。

    • 如果使用者歷程包含多個步驟的任務，請使用話語標記引導使用者完成程序。

    例如「現在…」、「然後…」、「瞭解了！」訊息傳送中…

    • 建議回覆和動作最多只能有 25 個半形字元，因此請簡潔扼要。
    • 如果對話中包含交接，快速確認可讓交接過程更順暢。

    例如「Alright. 接下來會由您的帳戶管理員接手處理。」

    例如「Perfect! 我想我知道你要找什麼。」並提供網站連結。

  • 使用表示認同的字詞或詞組回應使用者的訊息。

    例如「好選擇！」、「OK」、「好」或「我知道了」。

  • 直接以姓名 (如果知道) 或代名詞「你」稱呼使用者。請勿以「我」或「我們」稱呼使用者，以免造成混淆。

  • 標題和標籤應使用句首字母大寫格式，而非每字字首大寫格式。

    例如「Account statement」，而非「Account Statement」。

  • 使用縮寫，即使是語氣嚴肅或高亢的代理人也適用。

    例如「it's」比「it is」更貼近口語。

  • 請謹慎使用驚嘆號。

  • 使用序列逗號，也就是「A、B 和 C」，而非「A、B 和 C」。

  • 以數字形式寫出。

    例如「1, 2, 3」，而非「one, two, three」。

  • 使用表情符號時，請確認活潑的語氣是否適合該用途。

    舉例來說，使用者預約拖吊車或查詢健康檢查結果時，可能沒有心情。

保持訊息順序

如果你依序傳送多則訊息，使用者必須依序收到這些訊息。含有媒體的訊息處理時間會比純文字訊息長。為確保使用者收到的訊息順序正確，請等到收到訊息的 200 OK 回覆後，再傳送序列中的下一則訊息。

使用建議回覆和建議動作，創造引人入勝的對話

建議回覆和動作是引導及提升使用者對話體驗的強大工具。他們可以接續訊息或豐富資訊卡，並提供選項，讓使用者繼續或變更對話主題。

  • 建議回覆：提供預先定義的選項，協助使用者快速回覆服務專員。盡可能使用建議回覆，尤其是在預期會收到特定回覆時。

    有和沒有建議回覆的對話範例

  • 建議動作：允許代理程式與裝置功能整合，簡化撥打支援電話或尋找地點等工作。

請參考以下重要考量，打造更吸引人且有效率的對話：

  • 相關性：確保建議內容與當前對話相關。
  • 簡潔：限制建議數量，避免使用者感到疲乏。
  • 清晰：建議文字應簡明扼要。

協助使用者

代理程式應回覆使用者的 HELP 訊息，並說明代理程式的功能。根據代理程式功能量身打造的建議回覆清單，可將不佳的使用者體驗轉變為實用體驗。

確認標誌和主頁橫幅顯示正常

  • 標誌周圍應保留足夠空間，以利裁剪並維持視覺完整性。
  • 請勿延展或扭曲標誌或主頁橫幅，否則可能會對品牌形象造成負面影響。
  • 測試淺色和深色模式下的標誌和主頁橫幅，確保圖片清晰可見，且呈現最佳視覺效果。

如需更多有助於設計標誌或排解問題的資源，請參閱標誌設計指南。

  • 設計時請考量圓角正方形的顯示效果。為符合 Google 和業界標準，RCS for Business 標誌在對話清單、對話畫面和對話詳細資料中，會顯示為「圓角正方形」。
  • 將標誌置於圖片中央，確保裁剪後品牌元素仍清晰可見。
  • 通過驗證的服務專員名稱旁會自動顯示驗證勾號。這個標記受到保護，可防止他人冒用，且無法手動新增。
  • 如果標誌採用透明背景，請確保標誌與淺色和深色背景的對比度足夠，以配合深色模式。如果不確定，請使用純白色背景。

Hero image

  • 請使用 45:14 的顯示比例，避免不必要的裁剪。

設計主頁橫幅時，請考慮標誌重疊問題，以免重要元素遭到遮蔽。

尊重使用者不想接收訊息的意願

尊重使用者的通訊偏好設定，才能維持使用者信任。 如果使用者表示不想再收到訊息，代理程式必須尊重他們的選擇。包括以所有相關語言理解並適當回應各種停用要求，例如「STOP」。

如需瞭解如何回應「STOP」和其他強制性指令，請參閱作業所在國家/地區適用的法律和最佳做法。

舉例來說，請參閱 CTIA 最佳做法。

處理取消訂閱和訂閱事件

Google 訊息內建取消訂閱和訂閱功能，方便使用者控管對話。使用者選擇取消訂閱時，代理程式會收到 UNSUBSCRIBE Webhook 事件。SUBSCRIBE 事件表示使用者有意願再次與代理程式互動。

如要詳細瞭解如何處理「取消訂閱」和「重新訂閱」事件，包括酬載詳細資料、業務規則和範例，請參閱「使用者產生的事件」文件。

處理選擇不採用

RCS for Business 平台無法直接管理使用者停用清單。您有責任維護自己的使用者資料庫，當中列出選擇透過取消訂閱或其他停用方式停止接收訊息的使用者。

繼續對話

如果使用者刪除與代理程式的對話，必須透過其他管道重新發起聯絡，例如網站選擇加入、簡訊短代碼或其他同意聲明機制。這項新互動表示他們對接收訊息的興趣重燃。

下一頁
複合式資訊卡