WhatsApp 語音訊息與即時通話點揀？客服系統的兩條接入路徑

客戶可以遲啲聽同回覆，就揀 WhatsApp 音訊訊息；雙方都有時間、問題需要即時釐清，再揀即時語音通話。錄好再發送嘅訊息，同雙方即時對話都可以傳遞語音，但客服系統要用唔同嘅請求、識別碼同完成判斷。

本文比較 UnifyPort 音訊訊息，同透過非官方介面提供嘅內測版、人手發起嘅單對單語音外撥，唔係 Meta WhatsApp Business Calling API 指南。完整通話接入步驟請睇語音通話接入教學。

1. 先睇客戶方唔方便同步溝通

客服場景	建議選擇	原因
客戶同客服身處唔同時區	音訊訊息	雙方可以方便時先回覆
簡短說明，唔使即刻追問	音訊訊息，加文字摘要	客戶可以重聽說明、查看重點
多個細節需要快速來回確認	確認時間後即時通話	雙方可以一齊消除歧義
客戶唔方便私下聽，或者偏好文字	文字訊息	語音唔係每個場景都適合

例如，取貨說明可以用音訊發送，再用文字列出地址同時間；某個細節有爭議，客戶同意而且得閒，就可以改用通話。呢個係業務流程建議，唔代表平台內置自動路由，亦唔承諾提高回覆率。

2. 兩種方式用唔同嘅請求結構

兩條路徑都應將 API key 留喺伺服器端，揀定預期、已授權而且 runtime_status 係 running 嘅 WhatsApp 訊息帳戶，再用該帳戶傳回嘅 conversation_id 定位單對單對話。唔好用電話號碼字串代替對話識別碼。

發送音訊訊息時，將以下請求內容提交到 POST /v1/messages：

{
  "account_id": "acc_example",
  "to": { "id": "<conversation_id>", "type": "user" },
  "message": {
    "type": "audio",
    "url": "https://cdn.example.com/support/explanation.ogg"
  }
}

將範例 URL 換成可以存取嘅音訊資源。媒體訊息契約要求喺 message.url、message.file_url 或 message.file_key 至少提供一個非空來源；URL 必須係絕對 HTTP(S) 網址。範例係發送現有檔案，唔係由 API 擷取咪高峰。副檔名唔能夠證明編碼合適，呢個請求亦唔承諾特定嘅原生語音氣泡樣式或轉寫結果。

即時語音通話就用另一種請求內容，提交到 POST /v1/calls：

{
  "account_id": "acc_example",
  "to": { "id": "<conversation_id>", "type": "user" },
  "media_type": "voice"
}

建立通話契約要求由技術支援開通工作區內測資格，is_beta 係唯讀標記。成功回應 201 入面嘅 state: preparing，代表私密嘅一次性 join_url 已準備好。客服要喺 expires_at 前開啟連結並按 Start call，淨係開啟頁面唔會撥號。準備期由建立起預設兩分鐘，伺服器可以調整，唔限制已接通嘅通話時長。咪高峰權限必須允許，鏡頭則屬可選。

3. 分別保存兩條路徑嘅結果證據

觀察到嘅結果	應該保存	仍然未能確認
訊息回應係 status: accepted	傳回嘅 message_id 同所屬帳戶	已送達、已播放或問題已解決
收到匹配嘅訊息送達或已讀事件	回執涵蓋範圍同對應訊息識別碼	客戶已聽音訊
建立通話傳回準備好嘅連結	傳回嘅 call_id 同所屬客服任務	已撥號或已接通
收到 call.answered	data.call.id 對應嘅接通證據	問題已解決
收到 call.ended	結束原因同 duration_seconds	零秒足以證明未接通

應按送達同已讀文件解讀回執範圍，唔可以將成個對話嘅訊息都標成完成。已讀狀態唔係音訊播放回執。接通時長向下取整至秒，即使時長係零，亦應保留接通事件證據。

設定所需訂閱，再按 Webhook 投遞與驗簽說明驗證原始請求內容、去重事件、處理延遲同亂序。通話內測資格同事件訂閱係兩個條件。訊息入面嘅音訊附件唔係通話事件，亦唔代表通話 API 自動產生嘅錄音。

4. 令客服清楚知道自己執行緊乜操作

喺應用程式分開設計發送音訊同發起語音通話。發送音訊前，顯示揀好嘅檔案同客戶。如果要做咪高峰錄製、檔案儲存或轉寫，應視為獨立嘅應用程式功能，先驗證產物，再將資源交畀 API。

通話入口應顯示目標客戶、所屬客服同目前係咪可用。通話連結只交畀今次操作員，完整連結唔好寫入日誌。分別儲存訊息同通話記錄，再關聯到同一個客服任務；通話結束唔應自動關閉工單。

5. 切換溝通方式，要作一次新決定

音訊訊息冇回覆，唔代表客戶冇聽，更唔應自動撥號。先問客戶方唔方便通話。通話結束但問題未解決，客服可以明確選擇發送文字總結或音訊跟進；呢個係新訊息，唔係通話結果嘅延續。

請求逾時後，應保留結果未知狀態，唔好即刻重複寫入請求。通話結果不明時，參照通話排查指南查詢目前受管理嘅通話；查詢為空唔能夠還原以前嘅結果，亦唔好為咗釋放帳戶而掛斷歸屬不明嘅通話。

6. 由一個明確嘅客服任務開始

揀適合嘅測試對話，同客戶約定溝通方式，核對帳戶、目標、請求、已存識別碼同後續事件。檢查重複事件同客服最後一次工單更新。呢啲係建議嘅驗收步驟，唔代表本文已完成真實通話測試。

目前通話範圍唔包括來電、群組通話、錄音、轉寫、SIP/PBX 或 AI 自動外撥。需要討論開通資格同具體客服場景，可以聯絡技術支援，唔好發送 API key 或私密通話連結。