让不会用App的人自己办业务 - 拆解

原文链接：https://mp.weixin.qq.com/s/N208p7iWGQnxICBO6G6Ilg

核心观点

1. 任务完成比单次识别更重要：语音 AI 的价值不在于“听懂一句话”，而在于用户能否独立完成一笔真实业务。
2. 多模态引导优于纯语音或纯聊天：语音、图示、固定入口和明确步骤共同降低数字使用门槛。
3. 有限对话必须接入确定流程：语音可以帮用户找功能、理解要求，账户、转账和权限等动作仍需规则化控制。
4. 真实业务数据比下载量更有解释力：交易、还款、存款和重复使用能证明产品进入工作流，但不能替代任务完成率和用户独立性。
5. 首次教学与产品本身同等重要：银行网点、合作方和一线人员承担第一次安装、示范、答疑和问题回收。

方法链

1
2
3
4
5
6
7
用户目标
  → 语音/图示识别入口
  → 固定业务流程
  → 关键步骤的逐屏解释
  → 规则校验与安全确认
  → 真实业务完成
  → 失败位置、求助次数和复用数据回收

七个分析角度与 21 个开头钩子

1. 用户问题

• 手机会用，为什么银行 App 仍然不会用？
• 把文字翻译成本地语言，为什么仍解决不了操作困难？
• 用户知道要还款，却为什么找不到入口、看不懂步骤、无法确认结果？

2. 产品形态

• 语音助手不一定要变成一个无边界聊天机器人。
• 一张熟悉的图标，有时比一段更长的说明更容易被认出来。
• 好的引导不是替用户做决定，而是让用户知道下一步该做什么。

3. 可用性指标

• 下载 130 万次，能否证明用户真的完成过业务？
• 69 亿卢比交易额能说明什么，又不能说明什么？
• 一次识别成功和长期独立使用之间，隔着哪些漏斗？

4. 交付与推广

• 为什么产品发布不能只发一个下载链接？
• 合作银行的网点和员工，如何变成 AI 产品的首次使用入口？
• 谁教会用户、谁收集问题、谁负责出错后的处理，必须提前分工。

5. 语音工程

• 一个产品名、数字和专有词，为什么值得单独做热词处理？
• 用户一句话没说完时，系统应如何处理部分结果和最终结果？
• 语音模型的“听懂”与业务系统的“可执行”之间需要哪些中间状态？

6. 企业价值

• 同一段声音，客户要完成交易，员工要理解来电，目标完全不同。
• 实时语音和录音分析可以是两条产品线，不必一次性绑定。
• AI 的价值要落到具体工作：还款、转账、查余额、接听、归因和跟进。

7. Seetong 迁移

• Seetong 的 Agent 应该验证“用户是否看到了首帧”，还是“用户是否完成了看视频的任务”？
• 设备名、通道名、时间和告警类型，是否有自己的语音热词表？
• 设备离线、权限不足和网络恢复时，语音/图示引导是否能把用户带到可恢复状态？

对 Seetong 的最小落地

1. 将预览、回放、告警处理和设备分享定义为“任务完成”场景，记录入口、关键步骤、完成证据和求助点。
2. 在页面地图和 agent-device Flow 中增加语音/图示提示的可观测字段，验证提示出现、用户动作和业务结果的顺序。
3. 建立设备名、通道名、型号、时间表达、告警类型和错误码的热词与别名表，避免把识别问题误判为业务问题。
4. 将自由语音限制在找入口、解释状态和触发有限动作；权限、删除、分享、付费和设备控制仍走确定性确认。
5. 为网络断开、首帧超时、低功耗唤醒和权限不足增加“部分输入/重试/恢复/人工接管”状态，而不是只记录一次失败。
6. 评估指标从“生成多少用例”扩展为任务完成率、首屏到成功耗时、重试率、求助率、重复使用率和失败归因覆盖率。

证据边界

• 文章中的融资额、下载量、交易额、用户结构和网点/员工数字来自 Navana、Ujjivan、ThePrint 等公开材料的文章转述，本文未独立审计。
• “真实交易说明产品已经被使用”是合理推断，不等于所有用户都能独立完成全部流程。
• 对 Seetong 的建议是迁移推导，不是 Navana 或 Ujjivan 已验证的监控产品实践。