收发双向实时翻译
客户的外文自动译成中文，你的中文自动译成客户语言，14+ 引擎覆盖 200+ 语言，发送前还能预览译文。
使用说明 →API 还是客户端
先看你要解决的是哪件事
"要不要上 WhatsApp Business API"几乎是每个出海团队都会卡一次的问题。它不是好坏之分，而是路线之分：系统自动发通知，API 是正解；人工谈单、多号多平台，桌面客户端更顺手。很多团队最后是两条腿一起走。
WhatsApp Business API 和桌面聚合客户端该怎么选？
看你的主要场景是系统自动发通知还是人工谈单。官方 Business API 需要经 BSP 服务商接入、完成企业认证、主动消息要用送审通过的模板并按对话计费，优势是官方通道、可申请认证标识、能和订单系统打通做规模化通知；桌面聚合客户端不需要开发对接，客服登录后即可开工，优势在人工销售场景 —— 多个账号、多个平台同时在线，收发双向实时翻译，客户资料沉淀到企业。如果你既有大批量的订单通知，又有靠人聊出来的成交，两者并用是常见做法。
选型对照按场景匹配
订单通知 / 验证码 / 物流提醒
官方 API询盘跟进 / 报价谈判 / 售后
客户端多号多平台矩阵运营
客户端通知 + 人工承接
两者并用上线周期当天客户端无需开发对接
当天上线不用开发对接
多号多平台人工谈单更顺
卡在"要不要上 API"的团队，通常是这几种情况
问题往往不是 API 不好，而是它解决的不是你眼下最疼的那件事。
流程走不完，业务先停了
企业认证、BSP 对接、模板送审一轮轮走下来，等能发第一条消息，旺季已经过去了。
按对话计费，账算不过来
主动发起的对话按条计费，做高频跟进的团队一算账，成本比人工客服还高。
模板反复被拒
想说的话必须先做成模板送审，改一版等一轮，销售话术根本没法灵活调整。
API 管不了多账号矩阵
一个号一套配置，几十个号的矩阵运营要挨个走流程，还是解决不了"人在哪个号上聊"。
只解决了 WhatsApp 这一个渠道
客户还散在 Telegram、Instagram、LINE 上，接完 API 依然要在多个平台之间来回切。
语言关一点没解决
不管走哪条通道，客服看不懂客户在问什么这件事，API 本身并不负责。
两条路线逐项对比
不是替代关系 —— 看清各自擅长什么，才知道自己该走哪条，或者哪些场景该并用。
| 对比项 | 官方 Business API（经 BSP 接入） | WhatsApp Business App（手机版） | 网页版 + 人工 | 企鹅出海 SCRM 客户端 |
|---|---|---|---|---|
| 接入门槛 | 企业认证 + BSP 对接 + 开发 | 下载即用 | 扫码即用 | ✓装客户端、凭邀请码登录 |
| 上线周期 | 通常以周计 | 即时 | 即时 | ✓通常一个工作日内 |
| 主动发消息 | 需用送审通过的模板 | 可自由发送，受频率限制 | 可自由发送 | ✓人工对话自由发送，群发内置频率限制 |
| 费用结构 | 按对话计费 + 服务商费用 | 免费 | 免费 | ✓按端口数或字符量买套餐 |
| 多账号 | 一个号一套配置 | 一台设备一个号 | 同时只挂一个会话 | ✓多账号同时在线，统一工作台 |
| 多平台 | 仅 WhatsApp | 仅 WhatsApp | 各平台各开一个网页 | ✓18+ 平台账号聚合 |
| 实时翻译 | 不含，需自行开发 | 不含 | 不含 | ✓收发双向自动翻译，14+ 引擎 |
| 客户数据归属 | 在你自己的系统里 | 在员工手机里 | 在员工账号里 | ✓统一沉淀到企业侧 SCRM |
| 最适合的场景 | 规模化通知、系统对接 | 小团队单号自用 | 临时过渡 | ✓人工谈单、多号多平台矩阵 |
⚙️ 不用等流程审批
不走 API 也能开工
3 步把团队接进来
整个过程不涉及服务器部署，也不需要开发对接，通常一个工作日内客服就能开始接单。
- 1
开通后台并购买套餐
注册管理后台、购买端口版或字符版套餐，端口数决定团队能同时在线多少个社交账号。
- 2
生成邀请码把客服接进来
从套餐中划拨端口生成邀请码，客服凭邀请码登录 Windows / macOS 桌面客户端。
- 3
登录账号并开启翻译与内控
在客户端登录 WhatsApp 等平台账号，开启实时翻译，在后台配置敏感词监控与代理 IP，即可正式接单。
会话设置桌面客户端
翻译开关
翻译语言
当天开工
翻译引擎
- DeepL推荐
- Google 翻译
- ChatGPT
发送前预览
中文检测提醒
客户端补上的，正是 API 不负责的部分
官方通道解决"消息能不能发出去"，这些能力解决"人怎么把单谈下来"。
多账号同时在线
一个客户端里多个 WhatsApp 账号并行在线，消息汇总到一个工作台，不用为每个号单独走一遍接入流程。
使用说明 →18+ 平台一起接
Telegram、Instagram、Messenger、X、LINE、Zalo 的账号和 WhatsApp 一起管，客户在哪个平台都接得住。
使用说明 →内控与飞单监控
敏感词、敏感链接、敏感行为三层监控，客服把客户往私人账号引时立刻留痕告警。
使用说明 →代理 IP 隔离
后台统一维护代理资源并绑定到指定账号，一账号一 IP 隔离运行，多号运营的基础动作。
使用说明 →批量触达带频率控制
需要主动触达时多账号轮换发送，内置发送间隔与单号数量上限，不必为每条消息送审模板。
使用说明 →话术模板团队共享
高频问答做成快捷回复模板全团队共用，改话术不用等审核，新人当天就能按标准接客。
使用说明 →线索与工单对账
每个账号带来多少线索、哪个客服跟了多少，逐层可查，不用自己写报表拉数据。
使用说明 →什么情况该选哪条路
同一家公司的不同业务线，答案也可能不一样。
01
订单通知、验证码、物流提醒
系统触发、量大、内容固定 —— 这是官方 API 的主场，模板审核和按对话计费都在可接受范围内。
02
询盘跟进、报价谈判、售后
多轮人工对话、话术要临场调整、还要跨语言，用桌面客户端更顺手，也省掉模板送审的等待。
03
多号多平台矩阵运营
几十个账号横跨七八个渠道，逐个走 API 接入既不现实也解决不了统一工作台的问题。
04
两者并用
用 API 把通知规模化发出去，用客户端承接回来的人工对话 —— 这是成熟团队最常见的组合。
关于WhatsApp API 对比，大家都在问
没找到答案？直接联系在线客服，我们的顾问在跨境一线待了很多年。
什么情况下应该选官方 Business API？
当你的核心需求是"系统自动、大批量、内容固定"的消息时，官方 API 是更合适的选择：订单状态通知、验证码、物流更新、预约提醒这类场景，需要和自己的业务系统打通，也需要官方通道的稳定性与认证标识。这种情况下模板审核和按对话计费都是合理成本。反过来，如果你的成交主要靠人一句句聊出来，API 帮不上太多忙。
接了官方 API 还需要客户端吗？
很多团队是两者并用。API 负责把通知规模化发出去，但客户收到通知后回过来的问题仍然要人来答 —— 而这些人往往还同时在管 Telegram、Instagram 上的客户，也需要翻译。客户端解决的正是"人工承接"这一段：多号多平台汇总到一个工作台、实时翻译、客户资料沉淀、内控与对账。
不走官方 API 会有什么代价？
要如实说明：不走官方通道就没有官方认证标识，也不适合做那种一次几万条的系统化通知。桌面客户端承载的是真人使用场景 —— 账号是你自己的号，行为要遵守平台本身的频率与内容规则。所以我们在群发功能里内置了发送间隔和单号数量上限的建议，而不是鼓励无限量发送。想清楚这一点再选，比事后返工划算。
桌面客户端需要开发对接吗？
不需要。管理后台通过浏览器访问，客服使用 Windows 或 macOS 桌面客户端凭邀请码登录，整个流程不涉及服务器部署，也不需要接口开发。这也是它上线快的主要原因。
费用上两者差多少？
结构完全不同，很难直接换算。官方 API 是按对话计费，再加上 BSP 服务商的费用，成本随消息量线性增长；客户端是按端口数（同时在线的账号数）或字符量购买套餐，成本随团队规模增长而不是随消息量增长。做高频人工跟进的团队通常后者更可控，做海量系统通知的团队则相反。
客户数据分别留在哪里？
走官方 API 时数据在你自己的系统里，前提是你已经有一套系统去接。用桌面客户端时，客户档案、标签、跟进记录和聊天记录统一沉淀在企业侧的 SCRM 里，人员变动可以一键继承。如果既没有自建系统、客户又都在员工手机里，那才是最该先解决的问题。
可以先用客户端，以后再上 API 吗？
可以，而且是不少团队的实际路径：先用客户端把人和渠道跑通、把客户数据沉淀下来，等通知类需求的量真正上来了，再去接官方 API 做系统化触达。两者面向的场景不同，先后顺序不冲突。
支持哪些平台和操作系统？
桌面客户端提供 Windows 和 macOS（Intel 与 Apple Silicon）版本，可接入 WhatsApp、Telegram、Instagram、Facebook Messenger、X（Twitter）、LINE、Zalo 等 18+ 海外社交平台，翻译、多账号、代理 IP 等能力在各渠道通用。
其他解决方案
同一个工作台里的其他能力，配合使用效果更好 —— 账号稳、触达准、数据留得住。
