用失败请求报告优化IVR提示词，少转人工

大多数小企业的 IVR（Interactive Voice Response，语音交互式应答）并不是“听不懂”，而是没把“听不懂”当成数据资产。结果就是：客户说了两遍、三遍，系统还在重复“请再说一遍”；最后只能转人工。你的客服成本上去了，客户情绪也下去了。

更现实的问题在于：同一个意图，用户表达方式远比你在脚本里写的多。你写的是“查询余额”，客户说的可能是“我卡里还剩多少”“账户还有钱吗”“我想看看余额”。当这些表达没被命中，IVR 的“重试率”（retry rate）就会上升。

这篇文章把 Deepgram 原文里的思路扩展成一套更适合小企业的实践：用自定义报告收集“失败请求→成功请求”的链路，反推用户真正想做什么，再把这些发现接入自动化工作流（工单、CRM、知识库、内容推荐/脚本更新），把“转人工”留给真正需要的人。作为「人工智能在媒体与内容产业」系列的一部分，我们也会把它放到“内容与交互脚本如何持续迭代”这个更大的主题里看。

失败请求报告到底解决什么问题？

答案很直接：它能把 IVR 的模糊问题变成可操作的改进清单。

传统优化方式通常靠两种：

• 运营/客服“听录音”找问题（慢、主观、覆盖率低）
• 扩充意图库/训练集（方向可能错，改完未必有效）

失败请求报告的核心价值是：它记录用户在同一次任务里，先说了哪些“没被识别/没被命中”的话，最后又说了哪一句“被命中”的话。如果我们假设用户在重试时大概率没换目标（多数场景成立，尤其是查询、缴费、预约这类任务），那么这些失败短语就是最真实的“触发词缺口”。

一句可以直接写进团队 SOP 的话： “每一条失败请求，都是用户在教你怎么写提示词和触发词。”

对小企业来说，这意味着：你不需要先做一个很重的语义理解项目，也能从“部分匹配 + 报告”开始持续变好。

用实时转录搭一个最小可用的采集器（MVP）

答案：先做一个能跑起来的浏览器采集页，实时转录、实时匹配、实时记录失败链路。

Deepgram 原文演示用 JavaScript 在浏览器里做实时转录（WebSocket + MediaRecorder）。它的意义不在于“浏览器最好”，而在于：

• 上手快，10 分钟就能跑
• 你可以用它验证“失败→成功”链路是不是稳定
• 后续容易迁移到服务器、呼叫中心或自动化平台

1）实时转录：把音频变成可处理的文本流

关键机制：

• getUserMedia 获取麦克风
• MediaRecorder 每 250ms 切一段音频
• WebSocket 把音频发给转录服务
• onmessage 收到转录结果后进入你的业务逻辑

原文的最小代码就能把用户说的话打印出来。到了这里，你已经拥有了“可观察性”：IVR 里发生的一切不再是黑盒。

2）意图（Intents）最简模型：触发词 + 响应

原文用一个简化的 intents 数组：

• intent: 意图名
• triggers: 触发词列表（用 includes 做部分匹配）
• response: 命中后系统说什么

这套极简结构的优点是：先解决 80% 的可用性，再逐步升级到更精细的 NLU。小企业做自动化最怕一步到位搞“大而全”，最后没人维护。

3）记录重试链路：真正有用的“自定义报告”

核心数据结构：

• current: 当前这次尝试过程中积累的失败短语
• report: 每次成功命中时，把失败短语 + 成功意图打包存起来

当用户说了几句没匹配上、最后命中了某个 intent，report 里就会多一条记录。例如：

• retries: [“我想查一下卡里还剩多少”, “帮我看看账户余额”]
• intent: “balance”

这就是你下一轮优化的“金矿”。

把“失败请求”变成可落地的 IVR 优化动作

答案：把报告拆成三类任务——改提示词、补触发词、改流程。

很多团队拿到失败语句会下意识“加更多触发词”。我不反对，但只做这个通常不够。更有效的顺序是：

1）先改提示词（Prompt），再谈识别

IVR 的提示词不是播报稿，它是用户行为的“扶手”。提示词写得好，失败率会显著下降。

你可以从报告里找出高频失败表达，反推提示词问题：

• 用户反复说“我要人工”但你在提示里没给出口 → 增加清晰的转人工路径（反而会减少情绪性转人工）
• 用户说“退款/取消”但系统只给“订单查询/物流” → 提示词选项不完整
• 用户说“我想改地址”但系统只问“订单号是多少” → 流程顺序不对

可操作的提示词模板（更适合小企业）：

• “你可以说：查余额、转账、人工。”（给 3 个最常用选项，别给 10 个）
• “如果你要找人工，直接说‘人工’。”（减少用户试错）

2）再补触发词：用“簇”而不是堆词

把失败短语按语义聚类（哪怕人工分组也行），每组提炼 1-3 个高覆盖触发词。不要把整句都塞进 triggers，否则你会得到一个难维护的词表。

一个实用方法：

• 对每个 intent，把 report 中的 retries 做词频统计
• 选出“强区分词”（例如“余额/剩/还剩”“转/打款/汇”）
• 每轮只加 5-10 个触发词，观察重试率是否下降

3）最后改流程：把“没听懂”变成自动化分流

当连续两次没命中，继续让用户重试通常只会更糟。更聪明的做法是：把失败当成路由信号。

例如：

• 连续失败 2 次 → 切换为“引导式菜单”（按键/短选项）
• 连续失败 2 次且出现“人工/客服/真人” → 直接转人工
• 连续失败 2 次但检测到“退款/投诉”关键词 → 走投诉工单自动创建

这就是“IVR 优化作为自动化工作流的一部分”：你不是在修一个语音入口，而是在优化整个客户交互链路。

把报告接进自动化工作流：小企业最划算的升级

答案：用失败报告驱动 4 条自动化链路：监控、训练、内容、运营。

很多公司把语音助手当成孤岛。更现实的做法是把它接到你已经在用的系统：CRM、工单、知识库、内容管理。

1）监控：把“重试率”当成核心运营指标

你至少要跟踪 3 个数字（按周/按月看趋势）：

1. Retry Rate（重试率）：每 100 次会话中出现“未命中”后再次尝试的次数
2. Fallback-to-Agent Rate（兜底转人工率）：失败后最终转人工的占比
3. Top Failed Phrases（高频失败表达）：前 20 个失败短语

这些指标一旦有了，你就能像运营内容推荐一样运营你的语音入口。

2）训练：用失败短语更新意图库/训练集

如果你后续升级到更强的 NLU（语义匹配/意图分类），失败短语天然是训练数据来源：

• retries 作为“同意图的弱表达”样本
• 成功命中的 intent 作为标签

这比“拍脑袋写同义句”更接近真实用户语言。

3）内容：在媒体与内容产业里，它是“脚本与知识的持续迭代”

在内容型业务（媒体会员、付费内容、广告投放、活动报名）里，用户来电/语音入口常见诉求是：

• 会员开通/取消
• 发票/退款
• 账号异常
• 活动规则

失败报告能告诉你：

• 用户怎么描述这些问题
• 哪些术语是用户常用而你内容里没有的
• 哪些政策条款需要“口语化改写”

你可以把高频失败表达自动同步给内容团队，作为 FAQ、知识库、脚本改版的输入。这和“AI 支持内容推荐、用户画像、智能创作”是同一条逻辑链：用数据驱动内容迭代。

4）运营：把失败当成分群信号

一个简单但有效的运营动作：

• 识别“新手型失败”（比如反复问“怎么用/怎么开通”）→ 推送入门引导内容
• 识别“高风险失败”（比如“投诉/诈骗/扣费”）→ 直接进高优先级工单

这比只看“通话时长”更能反映真实摩擦点。

落地时最容易踩的 5 个坑（以及我的建议）

答案：别急着追求全自动，先把数据质量、边界条件和隐私打牢。

1. 把“未命中”全当成识别问题：有些是流程问题（选项不全/顺序不对）。先改提示词，收益往往更大。
2. 忽略“用户会换意图”：确实会，尤其是失败后改说“人工”。建议记录“意图切换率”，并在第二次失败时优先提供人工出口。
3. 只存文本不存上下文：至少要存时间戳、会话 ID、失败次数、最终 intent。
4. 触发词无限膨胀：词表堆到 500 个后一定失控。用分组和阈值控制每轮增量。
5. 隐私合规没做好：语音转文本可能包含个人信息。建议做脱敏（手机号/身份证/地址）、最小化存储、设定保留周期。

你该从哪一步开始？（一个两周计划）

答案：两周足够跑出第一版“失败请求报告→优化→复盘”的闭环。

• 第 1-2 天：做浏览器 MVP，能实时转录、匹配、记录 report
• 第 3-5 天：接入你现有的 IVR 日志或测试话术，收集 200-500 条样本
• 第 6-7 天：人工分组失败短语，改 3 条提示词，补 10 个触发词
• 第 2 周：上线 A/B（或灰度），对比重试率与转人工率；把报告同步到内容/运营/客服

当你能每两周稳定迭代一次，IVR 就不再是一次性项目，而是持续增长的自动化渠道。

最后留一个更“内容产业视角”的问题：当语音入口的失败表达持续涌现时，你的知识库、脚本、内容策略是否也在同频更新？