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 或私密通話連結。