采购语音 AI 前要问的 30 个问题
每场演示听起来都不错。让每家供应商接受同一批取自您线路的来电测试，再用同一套权重给回答打分，真正的差别才会显现出来。
简单说，每家供应商都考同一套题
语音 AI 的演示没法直接比较。每家供应商都用自己挑的脚本、自己准备的干净测试数据，再找一个很配合的来电者。最光鲜的演示往往胜出，哪怕它并不适合您的来电。
解决办法有三点。用书面形式给每家供应商发同样的问题，让每家都跑同一个取自您线路的测试场景，再用第一场演示之前就定好的权重给回答打分。这份模板三样都给您备好了。它的前提是您已经决定采购；如果还没决定，可以先看我们的自建还是采购的决策框架。
每个回答怎么打分
在第二次会面之前把 30 个问题发过去，要求每个回答都附上证据：一份文档、一条样例记录、一项合同条款，或一次现场实测。请两个人分别打分，一位来自运营，一位来自采购或 IT。两人分数相差 2 分及以上的问题，拿出来单独讨论。
| 分数 | 供应商给了您什么 |
|---|---|
| 0 | 没有回答，或者只说“这个我们能做”，拿不出任何依据 |
| 1 | 口头回答清楚，但还没有证据 |
| 2 | 书面回答、一份文档，或部分演示 |
| 3 | 在统一测试场景中演示过，或已写进方案书或合同 |
1. 报价覆盖范围
两份报价只有覆盖同样的工作，才有可比性。这些问题把一个价格还原成具体的工作范围。
| # | 问题 | 怎样才能得 3 分 |
|---|---|---|
| 1 | 报价覆盖哪些电话、意图、语言和渠道？哪些不包括？ | 方案书里有书面的范围内和范围外清单，并且与您真实的来电构成一致。 |
| 2 | 计费单位是什么？如何计量、如何取整？ | 明确的单一计费单位、取整规则，以及一通典型电话的账单明细样例。 |
| 3 | 哪些费用不在报价里？ | 电话线路、号码、模型用量、集成和上线后的改动，每一项都写明价格或费率。 |
| 4 | 用量高于或低于计划时怎么办？ | 超额用量和未用余额的规则写成书面条款，并按您预计用量的 50% 和 150% 各算出一份账单示例。 |
| 5 | 谁负责搭建和维护智能体？上线后哪些改动包含在内？ | 提示词、测试和集成都有明确的负责人；哪些改动包含在内、哪些另行报价，有书面规则。 |
2. 数据归属、隐私与退出
每通电话都会产生录音、转写文本，以及关于您客户的各类字段。这些数据由谁控制，要在试点之前谈定，不要拖到续约时。要求对方拿出经过测试的管控措施，而不只是一纸声明。DRING 的安全标准页面展示了一种呈现方式。
| # | 问题 | 怎样才能得 3 分 |
|---|---|---|
| 6 | 录音、转写文本、摘要和提取出的字段归谁所有？ | 合同写明归您所有，并规定供应商只能为向您提供服务而使用这些数据。 |
| 7 | 我们的数据会不会用来训练服务其他客户的模型？ | 书面明确答复“不会”，或在合同中写明您可以拒绝这种用途，而且同样约束供应商所用的模型服务商。 |
| 8 | 数据在哪里处理和存储？哪些子处理方会接触到？ | 写明具体区域，并提供最新的子处理方清单，注明每家服务商的角色。 |
| 9 | 能否按数据类型设置保留期限？能否查到谁访问过某条通话记录？ | 录音、转写文本和字段可以分别设置保留期限，访问日志可以按需调取。 |
| 10 | 如果我们不再合作，能带走什么？什么格式？多快能拿到？ | 一份书面的退出清单：您会拿到哪些数据、什么格式、截止时间，以及哪些数据留在供应商那里。 |
3. 系统对接与回写
集成页面上的一个 Logo，只说明可以对接，并不说明在您使用的版本里，智能体能读取或修改哪些字段。请对方提供字段映射表，再到测试场景里核对。
| # | 问题 | 怎样才能得 3 分 |
|---|---|---|
| 11 | 智能体会从我们的哪些系统读取数据，又会写入哪些系统？ | 每个系统一份字段级映射表（对象、字段、读或写），并已对照您的版本和权限核实。 |
| 12 | 一通电话结束后，我们的 CRM 或工单系统里具体会多出什么？能否加上我们自己的字段？ | 一条来自您测试场景的样例记录，包含处理结果、摘要、下一步动作和您的自定义字段。 |
| 13 | 通话中写入失败或系统宕机，会发生什么？ | 来电者听到如实的下一步安排，写入操作自动重试且不产生重复记录，同时有人收到提醒。 |
| 14 | 我们自己的系统如何发起通话、读取通话结果？ | 有文档说明的接口，可以发起通话、查询状态和获取结果，另有 Webhook 和测试环境。 |
| 15 | 哪些操作智能体可以不经人工确认直接执行？ | 一份逐项列明操作权限的书面清单，所有写入操作都要经您签字确认后才开启。 |
4. 转人工与控制权
转人工是设计的一部分，不是失败。要确认同事接手后，来电者不用从头再讲；也要确认您的团队能随时叫停智能体。
| # | 问题 | 怎样才能得 3 分 |
|---|---|---|
| 16 | 智能体什么时候转人工？规则由谁定？ | 书面写明、您可以修改的触发条件，包括来电者要求转人工、身份核验失败和超出政策范围的请求。 |
| 17 | 转接那一刻，我们的同事能看到什么？ | 来电者身份、来电原因、已完成的步骤和待解决的问题，在同事开口之前就能看到。 |
| 18 | 团队里没人能接，怎么办？ | 自动生成一条回电任务或工单，有负责人、有时间，并已在测试场景中演示过。 |
| 19 | 我们能自己暂停智能体吗？ | 一个经过测试的操作，一步就能停掉自动化、把电话转给您的团队，您指定的操作人员可以直接使用。 |
| 20 | 事后如何报告转人工情况？ | 按意图统计转人工率和原因，并说明接手的同事是否解决了问题。 |
5. 质量测试与版本发布
第一场演示做得好，说明不了第一百次改动会怎样。问清楚供应商如何证明智能体已经可以上线，又如何证明一次改动没有弄坏任何东西。DRING 把自己的测试流程一步步写了出来；您也可以请每家供应商讲讲他们的流程。
| # | 问题 | 怎样才能得 3 分 |
|---|---|---|
| 21 | 第一通真实电话之前测试什么？用什么材料测试？ | 用您的来电、文档和政策构建测试集，测试集规模、通过标准和结果都与您共享。 |
| 22 | 测试对话由谁打分？评分人意见不一致时怎么办？ | 有书面标准，有不止一位评估人，每一处分歧都有人复核。 |
| 23 | 改动如何测试和发布？能否回滚？ | 每次改动都重跑完整测试集，经您批准才发布，并且可以恢复到上一个版本。 |
| 24 | 上线后如何监控线上质量？ | 说明多大比例的线上通话会按处理结果和政策合规打分，并按固定周期与您一起复盘。 |
| 25 | 供应商更换智能体所用的模型或语音服务商时，会怎样？ | 提前通知您；智能体先在新配置上重跑您的测试集，然后才接听线上电话。 |
6. 电话线路、服务等级与故障
浏览器里的演示，跳过了运营商、电话音频和您现有的交换机。电话线路层要作为单独一项来比较。
| # | 问题 | 怎样才能得 3 分 |
|---|---|---|
| 26 | 能否保留我们的号码和现有的交换机？ | 明确的接入方式（呼叫转移、SIP 接入或号码携转），已在您的运营商线路上测试过，并以您现有的流程作为兜底。 |
| 27 | 最多能同时接多少通电话？再打进来的来电者会听到什么？ | 写明并发上限，并演示溢出路径：排队、回电或转给您的团队。 |
| 28 | 智能体在电话线路上的响应有多快？怎么测出来的？ | 在真实电话上、用您的语言端到端测得的数字，并说明测量方法。 |
| 29 | 通话中某个组件出故障，会发生什么？ | 经过测试的故障切换路径，能有序地结束或转接通话，绝不会让来电者对着沉默干等。 |
| 30 | 合同里写了哪些服务等级？没达到怎么办？ | 可用性、支持响应时间和故障通知时间都有书面约定，并写明补救措施和指定联系人。 |
用自己的来电搭一个测试场景
问题看的是供应商怎么说，场景看的是智能体怎么做。先从最近的来电里取一批样本，比如最近 50 通，挑出最常见的请求，再加上容易出问题的环节。在 CRM 或工单系统的沙盒环境里建好测试记录，字段与生产环境保持一致。
把大纲同时发给每家供应商：意图、系统和测试记录。来电者的具体台词留在自己手里，这样谁也没法照着脚本去调智能体。
| 环节 | 怎么安排 | 通过标准 |
|---|---|---|
| 常规来电 | 您最常见的请求，使用一条真实存在的测试记录 | 回答与记录一致，处理结果出现在测试系统里 |
| 打断 | 智能体话说到一半，来电者插话并改了请求 | 智能体停下来，接住新的请求，不会从头再念一遍脚本 |
| 查无记录 | 来电者报出一个不存在的订单号或账号 | 智能体如实告知，再问一次，然后给出下一步；绝不编造状态 |
| 来电者生气或说不清楚 | 来电者反复说同一件事、提高嗓门，或把两个问题搅在一起 | 智能体先回应对方反映的问题，一次只处理一件事，到了您规则里该转人工的时候主动提出 |
| 转人工 | 来电者要求转人工；测试队列有人值守时跑一次，没人可接时再跑一次 | 同事不用再问就能看到原因；没人可接时，生成一条有负责人的回电任务 |
| 回写检查 | 所有电话打完后，打开测试系统查看 | 每通电话都有正确的处理结果、摘要和下一步动作，没有重复记录；查询失败的那一通标记为失败 |
在真实电话线路上跑一遍
- 用手机拨打一个真实号码，不要用浏览器标签页，请您团队里的一位同事扮演来电者。
- 征得同意后录下整个过程，根据录音打分，不要凭记忆。
- 统计来电者有几次不得不重复，并给智能体每次回复前的停顿计时。
- 第一轮跑完后，提出一项改动，比如一条新的政策规则，然后把场景再跑一遍。
供应商如何测试和发布这一项改动，比任何幻灯片都更能回答第 23 题。这个场景还能为第 12、17、18 和 28 题的 3 分提供证据。
用同一套权重汇总分数
权重要在第一场演示之前定好，免得有人为了心仪的供应商去调整。下表的分配只是示例；哪个维度出问题对您的业务伤害最大，就把分数往哪里倾斜。
| 维度 | 示例权重 |
|---|---|
| 1. 报价覆盖范围 | 15 |
| 2. 数据归属、隐私与退出 | 15 |
| 3. 系统对接与回写 | 20 |
| 4. 转人工与控制权 | 15 |
| 5. 质量测试与版本发布 | 20 |
| 6. 电话线路、服务等级与故障 | 15 |
| 合计 | 100 |
维度得分 =（该维度原始分 / 15）× 维度权重。15 是每个维度的满分：5 个问题，每题 3 分。六个维度的得分相加，就是满分 100 的总分。
打分之前，先标出 3 到 5 个必过项，比如第 6、13 和 17 题。只要在任何一个必过项上得 0 或 1 分，无论总分多高，这家供应商都直接出局。
一个算例
下面的分数是为演示计算方法虚构的。供应商 A 的演示最流畅；供应商 B 听起来平淡一些，但在测试场景里展示了自己的回写和测试流程。
| 维度（权重） | 供应商 A 原始分 | 供应商 A 加权分 | 供应商 B 原始分 | 供应商 B 加权分 |
|---|---|---|---|---|
| 报价范围（15） | 12 | 12.0 | 10 | 10.0 |
| 数据与退出（15） | 9 | 9.0 | 12 | 12.0 |
| 系统对接（20） | 6 | 8.0 | 12 | 16.0 |
| 转人工（15） | 8 | 8.0 | 11 | 11.0 |
| 质量（20） | 7 | 9.3 | 12 | 16.0 |
| 电话线路（15） | 12 | 12.0 | 10 | 10.0 |
| 合计 | 54 | 58.3 | 67 | 75.0 |
此外，供应商 A 在必过项第 13 题上只得了 1 分，所以无论总分多少都要出局。它的演示强在对话本身，弱在对话之后的事：记录、故障路径和下一次版本发布。
回答里的危险信号
- “我们什么系统都能对接”，却拿不出针对您系统的字段级映射表。
- 问到“系统宕机时，来电者会听到什么？”，对方答不上来。
- 所谓转人工，只是把电话转到一个号码上，您的同事拿不到任何上下文。
- 测试结果只报一个总体百分比，没有方法，也没有样本量。
- 改动或模型更新未经您批准、也不通知您就上线。
- 退出条款只写数据“可以提供”，没有格式，也没有期限。
出现一个危险信号，就值得再用书面形式问一次。同一个维度里出现好几个，说明真正的工作最后会落到您的团队身上。
DRING 如何回答这些问题
这份模板同样适用于 DRING。有些问题，我们现在就能给出书面回答：
- 第 21 题：每个 DRING 智能体在接第一通真实电话之前，都会跑 1,000 至 10,000 次专为您企业生成的模拟对话。这些对话根据您的业务流程、文档和通话录音生成，不是通用的基准测试集。
- 第 11、12 题：HubSpot 是有文档支持的参考实现，覆盖选择拨打对象、执行通话和回写结果。Connect 按同样的条件对接 Salesforce、Freshdesk 等主流 CRM 和工单系统；具体的对象、权限、自定义字段和操作，在上线实施阶段确认。额外的分析字段也可以定义，并以同样的方式通过 API、CRM、数据看板和报表返回。
- 第 14 题：在约定范围内的业务流程中，发起通话、查询状态和获取结果的接口，以及生命周期和结果 Webhook，都是标准配置。
- 第 1、27 题：DRING 按预计用量、并发通话容量、智能体类型数量、渠道、实时转人工需求、支持级别和集成深度来推荐套餐。语言方面，可用语言 62 种，目前 10 种已上线；您的语言会在上线前完成验证。
DRING 一开始可能得分偏低的地方：小众或深度定制的 CRM 要单独评估，之后才会对非标准开发报价。评估完成之前，第 11 题可能停在 2 分。不在已上线范围内的语言，在您的场景用它跑过之前，对您的线路来说都应视为尚未验证。
签约之后，评分表继续用
得了 3 分的回答，就是试点的验收标准。这个六环节的场景，就成了第一套回归测试，之后的每一次改动，都要用当初决定这笔采购的那些电话来检验。