AI 外呼系统：五块能力，缺一块都上不了生产
外呼不是「拨号 + 放录音」。一套能长期跑的系统要同时解决：号码该不该打、对话听不听得懂、打完之后线索归谁、出问题时能不能自证。这一页把这五块摊开讲。
产品结构
一套能上生产的 AI 外呼系统，由五块组成
市场上很多「外呼系统」只做了第 1 块。剩下四块缺失时，系统能打通电话， 但你回答不了三个问题：这批号码为什么该打、打完之后线索归谁、出现投诉时凭什么是合规的。
少一块会出什么事
| 缺失 | 表面现象 | 真实后果 |
|---|---|---|
| 名单管理 | 能拨通 | 同一客户被多个业务员重复拨打，投诉率飙升 |
| 意向分级 | 通话记录都有 | 业务员要自己听录音找线索，等于没省人力 |
| 接听 | 外呼正常 | 客户回拨无人接，前面打的全是负资产 |
| 质检 | 通话量上去了 | 违规承诺无人发现，出问题时无法自证清白 |
| 留痕 | 功能都能跑 | 监管或客户追责时拿不出证据链 |
为什么先讲结构，不先讲功能
因为功能是可以后加的，结构不行。如果一个系统的名单、通话、线索分属三个互不相通的模块， 后面想加「跨模块退订比对」这类能力就只能靠人工导出再比对 —— 那是每周都要做一次的脏活。
本系统的做法是把这五块放在同一套数据模型上：号码用同一个摘要做键， 所以退订一次，外呼、接听、导入三条路径同时生效。
外呼能力
对话这一层，具体能做什么
下面每一条都是外呼过程中真实会发生的情况，不是功能清单上的名词。
开场身份确认
第一句先确认「是不是本人」「现在方不方便」。对方说不方便就改约，不硬推。 这既是礼貌，也是避免在错误时间点触发投诉。
多轮意图追问
客户说「我考虑一下」时，系统会区分是价格顾虑、时机不对、还是不信任产品， 再按不同方向追一句。而不是重复念完剩下的台词。
打断与抢话处理
客户中途打断时立刻停止播报，先听。人被打断会生气，机器一直说下去同样会。
知识库问答
产品参数、服务范围、资质、价格区间都从知识库取。取不到就明说「我确认一下」， 不编造。这条是硬规则，不可配置关闭。
信息采集与确认
需要收集的信息（意向城市、预算区间、方便回访的时间）逐项问、逐项复述确认， 避免「听成别的内容」这种低级错误进到 CRM。
转人工与交接
触发转人工时，把已确认的信息、客户原话、当前进行到哪一步一并交给坐席， 客户不用从头再说一遍。
未接通分级重试
关机、空号、占线、无人接听是四种不同结果。空号不再重试， 占线和无人接听按退避策略重试，且计入频次上限。
通话中实时兜底
识别服务或合成服务不可用时，立即转人工或按预案播放兜底语音， 而不是让客户对着沉默的电话等待。
部署形态
两种部署方式，选哪种取决于数据敏感度
不是「私有化更高级」这种话。两种方式各有明确适用面， 下面把取舍写清楚，你自己判断。
| 对比项 | 托管部署 | 私有化部署 |
|---|---|---|
| 初始投入 | 低，按月计费 | 高，需要 GPU 服务器 |
| 数据位置 | 运行在服务方机房 | 完全在你自己的机房 |
| 单通成本 | 随通话量线性增长 | 通话量越大越省（GPU 摊销） |
| 模型升级 | 服务方统一升级，你无感 | 你决定什么时候升、是否升 |
| 内网可用 | 需要能访问公网 | 可完全离线，内网运行 |
| 定制深度 | 限于开放出来的配置项 | 可改代码、可接内部系统 |
| 运维责任 | 服务方 | 你自己（我们提供部署说明与排障手册） |
| 适用 | 50 席以下、数据敏感度一般 | 金融医疗等强监管、或通话量大 |
私有化的真实门槛是 GPU，不是软件
语音合成与大模型推理在 CPU 上不具备可用性 —— 不是「慢一点」，是慢几十倍： 一句话要等几十秒，客户早挂了。所以私有化必须配 GPU 服务器， 具体卡型与数量按你的并发峰值算。
我们会在报价前先把容量测算做完再给结论，而不是先报个价再说「机器你自己解决」。
托管也不是「数据交出去」
即使托管部署，原始号码仍然不落盘：存储的是加密形态 + HMAC 摘要， 界面与导出都是脱敏形态。录音是否保留、保留多久都可配置。
但要说清楚：托管意味着数据物理上在别人机房。如果你的合规要求是 「数据不得出机房」，那只有私有化能满足，这一点没有折中方案。
系统边界
这些事我们不做
把不做的写清楚，比把能做的写满更有用。下面是明确不提供的， 如果你的需求落在这些范围里，我们不是合适的供应商。
不卖、不代购号码名单
名单必须是你合法持有的客户数据。买卖个人信息在国内是刑事风险， 不是商务问题。
不转租外呼线路
线路由你与持牌运营商直接签约。我们做系统，不做线路二道贩子 —— 线路被转租过，出问题时责任归属会变得很难看。
不做「一键群呼无限打」
没有绕过频次上限、绕过退订名单的开关。这类开关一旦存在， 早晚会有人打开它，然后公司承担后果。
不让 AI 冒充真人
被问到「你是不是机器人」时如实回答。刻意伪装在合规上是加重情节， 不是卖点。
不做医疗诊断、不做投资建议
这两类内容有执业资质要求。系统只做信息确认、预约、提醒、回访。
不承诺具体转化率
转化率取决于名单质量、产品竞争力、话术水平。任何「保证提升 300%」的说法 都不该被相信。
常见选择困难
采购时最容易选错的两处
这两条来自实际项目里反复出现的返工。
「外呼」和「接听」要不要一起买？
如果你的业务会引发客户回拨，建议一起。原因很实际：外呼把客户兴趣勾起来之后， 他第一反应是回拨这个号码。如果那边没人接，前面那通外呼的效果直接归零， 甚至变成负分 —— 客户会觉得「这家公司打给我，我打回去却没人」。
反过来，如果只是纯通知（停电通知、账单提醒），客户基本不会回拨， 那只做外呼是合理的。
质检是必选还是可选？
取决于你的行业监管强度。金融、医疗、教育这类有明确话术禁区的行业， 质检实质上是合规成本，不是效率工具 —— 出一次违规承诺，罚的钱远多于系统钱。
如果是普通 B2B 销售外呼，质检可以先不上，但至少要保留「全量转写 + 可检索」， 否则客户投诉「你们的人说过 XX」时，你无法自证。
能不能只买软件，线路和号码我们自己搞定？
可以，这也是推荐做法。线路由你与运营商直签，系统通过标准协议对接。 这样线路资质、实名、报备都在你名下，责任清晰。
需要你提供的是：线路接入方式（SIP 中继 / API）、主叫号码、并发数。 这三项确定后，对接通常 1–3 个工作日。
存量 CRM 需要换掉吗？
不需要。系统通过 API 与你的 CRM 双向同步：名单往下推，通话结果与意向等级往上传。 支持按你的字段结构做映射。
如果 CRM 没有开放接口，退一步的做法是导出/导入 CSV， 但这会让人工介入变成每周例行工作，长期不建议。
采集时最容易漏的两条
回拨与质检，为什么建议一起上
这两条不是「多卖两块」，是「少一块会漏掉最有价值的客户」。
会主动回拨的客户，是意向最强的一批
只做外呼、不做接听的部署里，回拨未接的量往往占外呼接通量的相当比例。 这部分人恰恰是意向最强的 —— 愿意主动回拨，说明他确实有兴趣。
把他们漏掉是最可惜的损失：前面外呼的钱已经花了，兴趣也勾起来了， 却因为那边没人接而断掉。而且这类客户很少会再打第二次。
所以如果业务会引发回拨，接听这块建议一起上，而不是等以后再补。
抽检 3% 在统计上等于没做
抽检 3% 的录音，意味着 97% 的通话没人看过。违规的那一通很可能就在这 97% 里， 而这一通被投诉的概率跟抽检比例无关 —— 客户该投诉还是会投诉。
全量转写 + 规则识别的成本已经不高了。真正的分界线不是「抽检还是全量」， 而是「出事时你能不能拿出这一通」。
怎么开始
三步判断值不值得往下走
企业级项目最贵的成本不是软件钱，是内部协调与试错时间。 所以这三步设计成「花最少的时间排除最不可能的情况」。
半小时能做完
用两个问题自测
电话是不是你和客户的主要触点？名单是有对应关系的存量客户，还是陌生名单？ 两个都是「是」，基本值得试跑；有一个「否」，先解决名单与触点问题。
一到两周
小流量试点
一条业务线、一份真实名单、每天几十到两百通。目标不是看转化率， 而是找出：哪些问题答不上来、哪些表述客户反应异常、哪些名单无效。
按规模决定
选部署形态
数据不得出机房或通话量大，走私有化；否则托管更省事。 这一步选错，后面所有成本项都要重算，所以要在容量测算之后定。
为什么强调「先试点」
因为外呼系统的失败方式很特别：它不会崩，它会「看起来在跑」。 电话打出去了、记录也生成了、报表也有数字 —— 但客户体验很差、 意向客户被漏掉、话术在第三轮就答不上来。这些问题全量上线后才发现， 返工成本是试点期的十倍以上。
试点期的核心产出一份「答不上来清单」，它是后面所有话术与知识库工作的基础。 没有这份清单就直接全量，等于赌客户不会问出格的问题 —— 这个赌注基本会输。
混合形态
除了纯托管与纯私有化，还有三种现实形态
实际项目里，客户的要求往往不是二选一。下面三种是我们在项目里真遇到过的折中形态， 各写清它解决了什么、又引入了什么新问题。
形态一：生产在内网，报表脱敏外发
通话与模型全在内网，只有脱敏后的统计数字（通话量、意向分布、质检合格率） 同步到一个轻量的外部看板，方便管理层在手机上查看。
解决了：管理层随时看数，又不用把明细数据带出机房。 新问题：脱敏口径要定义清楚，否则「统计维度」本身也可能泄露信息。
形态二：模型本地，语音线路走公网
识别、合成、大模型都在本地，只有电话音频通过运营商的 SIP 中继进出。 这是最常见的形态 —— 因为线路本来就必须走运营商。
解决了：核心算力与数据在本地，线路用现成的。 新问题：音频在传输段仍然是明文，需要确认运营商侧的合规口径。
形态三：总部私有化，分支用托管
总部或主业务线私有化部署，分支机构用托管版本，两边数据不通， 名单与话术各自独立管理。
解决了：分支不需要采购 GPU，上线快。 新问题：退订名单与频次判定必须在各自系统内闭环 —— 如果同一个客户在总部被退订，分支那边不知道，就会再打一次。
选混合形态前必须先回答一个问题
这个问题是：「退订与频次的数据，是全局共享还是各管各的？」
如果各管各的，同一个客户可能今天被总部的 AI 打过、明天被分支的 AI 打过、 后天被某个业务员打过 —— 在客户看来这就是一家公司在骚扰他。
所以任何多实例部署的方案，都要先设计好退订名单与频次记录的同步机制， 哪怕同步的只是「号码摘要 + 退订标记」这两个字段。
验收清单
上线前逐项确认的十件事
这份清单来自项目复盘。任何一项没确认就全量上线，都会在两周内变成问题。
- 退订跨模块生效：在外呼模块登记的退订，接听模块与名单导入也能识别。
- 频次四个窗口都在生效：日、24 小时、7 天、30 天各测一次，不只看日上限。
- 时段配置用真实时区：服务器的系统时区与业务时区一致，否则早晚会差几小时。
- 录音开关双向验证：开启时能录到，关闭时磁盘上确实没有文件、目录也不存在。
- 转人工真的有人接：找个人实际扮演坐席，走一遍交接流程。
- 知识库检索不到时的行为：确认是「明确说我确认一下」而不是编一个答案。
- 号码脱敏在每一处：列表、详情、导出、日志、报错信息里都不能有完整号码。
- 失败要有可见结果：故意让识别服务不可用，看批次是否被拒收而不是静默跳过。
- 审计能查到人：随便查看一条完整号码，看审计里有没有记录是谁看的。
- 导出能交给别人看：导出的取证包换个不懂系统的人也能看懂。