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 或私密通话链接。