先把 POC 缩成一个可判断的业务任务
POC 应选择规则相对明确、通话量可估、结果能从后台核对，且发生错误后可以补救的任务。例如搜集维修资料后建立工单，比「处理所有客服问题」更适合验证。开始前要写清楚通话入口、必要栏位、可执行动作、禁止动作、人工接手条件，以及企业 API 和测试环境由谁提供。范围若无法画出边界，验收就只会变成主观试听。
AI 语音客服 POC 怎么验收？测试情境、指标与上线门槛
AI 语音客服 POC 的目的不是录出一段顺利 Demo，而是用有限范围回答三件事：真实来电能否完成指定任务、失败时能否被发现与接手、整体成本是否值得进入正式建置。只验收声音自然或回答流畅，无法证明系统能正确建立工单、查询状态或保护重要资料。
蔡翊廉｜全端工程师・数位产品开发者 发布2026-08-30
本文章节
- ·先锁定任务
- ·建立测试案例
- ·定义指标
- ·设定门槛
- ·失败情境
- ·GoGoCha 证据边界
- ·正式上线
先保存人工流程基准，再谈 AI 改善
没有基准值就无法判断 POC 是否改善。至少记录目前任务由谁处理、成功如何定义、常见错误、尖峰等待、需要重新输入的资料，以及人工如何补救。基准不一定要是漂亮的 KPI；一小批经确认的实际案件，也比供应商自行假设合理。正式比较时要使用相同任务、相近来电条件与一致的成功定义。
黄金测试案例要包含正常、模糊与失败路径
先由业务、客服与系统负责人共同写出输入、预期追问、必要栏位、允许动作与最终状态，再交给系统重复测试。案例不能全部使用照稿念的标准句，应包含使用者改口、资料缺漏、同音字、背景噪音、沉默、插话、API 逾时及要求真人。涉及姓名、地址、金额或身分时，还要测试 AI 是否会重述确认，而不是只看逐字稿像不像。
| 情境 | 要观察什么 | 可核对的结果 |
|---|---|---|
| 正常完成 | 必要栏位、追问顺序与工具呼叫 | CRM／工单／派单状态与通话纪录一致 |
| 资料模糊或改口 | 是否重新确认并覆盖旧值 | 只保留最后确认资料，不重复建单 |
| 语音误解 | 低信心、重问与转人工条件 | 错误未被直接写入正式系统 |
| API 逾时或拒绝 | 回覆、重试、待办与幂等 | 不先宣称成功，后台可追踪最终状态 |
| 要求真人或高风险事项 | 转接路由与上下文交接 | 人工收到已确认栏位与未解问题 |
指标要对应任务，不要只看辨识率
语音辨识正确不代表任务成功，逐字稿有错也不一定影响结果。验收应同时看任务完成、必要栏位正确性、工具呼叫成功、误解或 fallback、计划性转接、异常升级、使用者放弃、回应延迟及人工修正量。每一项都要有明确分母与资料来源，例如以「符合范围的测试通话」为分母，并由电话纪录、模型事件、API log 与企业系统最终状态交叉核对。
| 指标 | 定义方式 | 避免的误判 |
|---|---|---|
| 任务完成率 | 符合范围且最终状态正确的通话占比 | 不能把只完成对话算成完成工单 |
| 必要栏位正确性 | 经确认栏位与真实答案相符程度 | 平均值不可掩盖地址、金额等关键栏位 |
| 工具执行成功 | API 动作成功且没有重复或错误副作用 | 网络逾时不能直接算失败或成功 |
| 误解与 fallback | 系统无法理解或进入重问的频率 | 要区分合理追问与无效循环 |
| 人工接手 | 计划转接、异常升级与使用者主动要求 | 转人工不是一律失败，要依原因分类 |
上线门槛必须依错误成本设定
没有一条及格线适用于所有 AI 电话。查询营业时间与修改付款资料的错误成本完全不同；同一个任务中，地址错一个字也可能比语气不自然严重。做法是先把错误分为可自动重试、需要人工覆核、不得自动执行三类，再为每类指定门槛与责任人。若样本不足，只能说 POC 尚未发现特定问题，不能推论正式环境一定达标。
POC 验收也要测失败后能不能运营
正式服务一定会遇到电信断线、模型逾时、企业 API 异常、人工席位满线及供应商维护。POC 应确认每种异常会回覆什么、资料停在哪个状态、谁会收到通知，以及恢复后能否安全重试。前端与运营后台要完整显示可理解的错误，不能把例外吞掉后让客服以为案件已成立。
GoGoCha 能作为架构证据，不是通用验收数据
GoGoCha 公开案例可证明隼讯做过 AI 电话入口、共用派单后端、伫列、即时通知，以及网站、LINE、App 与后台整合。案例没有公开辨识率、平均延迟、接通率、人力节省或正式通话 SLA，因此这些数字不能拿来替另一个企业设定门槛。新的 POC 仍要用该企业的电话环境、客群语言与任务资料重新验收。
从 POC 进正式版前要留下哪些交付物？
至少留下版本固定的测试案例、结果明细、未解风险、系统架构、资料流、权限、监控、人工接手与回复流程。正式版还要重新测尖峰并发、真实 PBX／SIP、备援、录音政策与运营权限。POC 通过只表示值得继续建置，不表示可以原封不动直接承担正式流量。
参考资料
- Evaluate agents with golden test cases and scenarios｜Google Cloud Documentation
- Voice virtual agent dashboard metrics｜Google Cloud Documentation｜2026-08-26
常见问题
AI 语音客服 POC 要测多少通才够？
没有通用数字。样本要覆盖主要意图、常见说法、重要失败路径与不同来电条件；高风险或低频例外不能只靠随机通话碰运气，必须刻意建立测试案例。
POC 能只用网页麦克风测试吗？
可以用来早期确认对话，但不能替代真实电话验收。正式 POC 至少要加入实际电话路由、音讯品质、转接与企业系统，否则会漏掉电信延迟、断线和 PBX 限制。
转人工很多就代表 POC 失败吗？
不一定。高风险事项的计划性转接可能正是正确设计；要分开看计划转接、使用者主动要求与系统误解造成的异常升级。
相关服务
公开案例与可验证证据
GoGoCha AI 电话与即时派单技术案例