客户需求洞察 CI
客户需求洞察 CI (Customer Insight)
客户需求洞察是研发自己动手获取客户事实的方法：不靠转述、不靠猜测，而是到现场看客户怎么干活、在哪里卡住、为什么忍着。它的输出直接喂给 CPD，是 APD Gate 0 / Gate 1 的第一手输入。
客户不会告诉你要什么产品，但一定会展示他哪里疼。
一、CI 与 VOC 的关系
VOC 是组织级的客户声音收集体系（渠道、抽样、闭环），CI 是工程师层面的洞察动作。
| 维度 | VOC | CI（研发视角） |
|---|---|---|
| 主体 | 市场、客户成功、质量 | 研发工程师亲自参与 |
| 目的 | 建立持续听取机制 | 为具体设计决策取证 |
| 频率 | 制度化、周期性 | 项目驱动，立项前密集 |
| 输出 | 声音库、满意度、投诉闭环 | 可转成规格的工程结论 |
| 失败模式 | 有数据没人用 | 只听一家客户就当真理 |
两者必须打通：CI 的结论回写进 VOC 库，VOC 的异常数据触发新的 CI 走访。
二、研发不做 CI 的三个后果
- 需求靠转述，经过销售一层过滤后，痛点变成功能清单，工程师失去取舍依据。
- 规格反复改，因为没人见过真实使用场景，边界条件在设计中途才被发现。
- 做了没人付钱的功能，团队加班交付了一个客户不用的亮点。
判断你是否真的做过 CI：你能说出客户完成一次核心作业的步骤、耗时、失败点吗？说不出，就还没做。
三、五种一线可用的洞察方法
| 方法 | 什么时候用 | 准备什么 | 时长 | 输出物 |
|---|---|---|---|---|
| 现场观察（Gemba） | 立项前、痛点不清时 | 观察表、相机、秒表、安全许可 | 半天到一天 | 作业步骤与卡点记录 |
| 跟机 / 陪班 | 需要拿真实节拍与异常频次 | 记录表、允许拍照的授权 | 一个完整班次 | 节拍、异常次数、返工点 |
| 深度访谈 | 验证痛点优先级与付费意愿 | 访谈脚本、录音许可 | 45 到 60 分钟 | 痛点排序与量化影响 |
| 售后与投诉数据挖掘 | 想低成本找共性问题 | 近 12 个月工单、备件消耗 | 1 到 2 天 | Top 失效与成本分布 |
| 竞品拆解 Teardown | 定差异化与目标成本时 | 竞品实物、拆解台、BOM 模板 | 1 到 3 天 | 结构对标与成本估算 |
组合建议：先用售后数据找嫌疑，再到现场观察确认，最后用访谈确认优先级和付费意愿。单一方法容易被个别客户的偏好带偏。
一次合格的现场观察怎么做
- 提前说明目的：我们来看流程，不来考核人。
- 只看不指导，把改进冲动记在纸上，别在现场教客户怎么干。
- 记录三类事实：动作与耗时、临时变通（胶带、垫片、手写标签）、被容忍的异常。
- 现场变通是最强的需求信号，客户自己动手补的地方，就是设计缺口。
- 离场前用 5 分钟向客户复述你看到的，确认没理解错。
四、客户访谈脚本模板
【客户访谈脚本】
客户 / 角色： 日期： 访谈人：
一、开场（3 分钟）
- 说明目的：了解你们的作业流程，不推销产品
- 征得记录 / 拍照许可
二、作业还原（15 分钟，问事实不问观点）
- 请带我走一遍你昨天的完整流程
- 每一步大概花多久？谁来做？
- 上一次出问题是哪一步？多久发生一次？
- 出问题时你怎么应急？
三、痛点排序（15 分钟）
- 刚才这些问题里，最让你头疼的三个是哪些？
- 如果只能解决一个，你选哪个？为什么？
- 这个问题一年大概让你损失多少（时间 / 废品 / 停机 / 人力）？
四、替代与付费（10 分钟）
- 现在你怎么凑合解决的？
- 为什么没换掉现在的方案？
- 如果有方案能把这个指标改善一半，值多少钱？多久能决策？
五、收尾（5 分钟）
- 我理解的是……（复述确认）
- 还有什么我没问到但很重要的？
- 后续能否给我看一次实际作业 / 数据？
【禁止提问】
- 你想要什么功能？（客户会给你竞品功能表）
- 你觉得加个 XX 好不好？（诱导式，答案永远是好）
- 这个价格能接受吗？（在没有价值量化前问价，等于自杀）五、现场观察记录表
| 字段 | 记录要点 |
|---|---|
| 步骤编号与名称 | 客户口语命名，不用内部术语 |
| 耗时 | 实测秒 / 分，注明观察次数 |
| 操作者 | 岗位、技能等级、是否需老手 |
| 使用工具 | 含自制工装、非标夹具 |
| 卡点与变通 | 客户自己加的补丁，拍照编号 |
| 异常频次 | 每班 / 每周发生几次 |
| 影响 | 停机、返工、废品、安全 |
| 客户原话 | 引号原样记录，不做加工 |
六、从客户语言到工程参数
洞察的价值在转化。每条客户原话都要走完这三格，否则不算完成。
| 客户原话 | 工程参数（可判定） | 验证方法 |
|---|---|---|
| 换型太慢，每次都要叫师傅 | 单人换型时间 ≤ 15 分钟，无需专用工具 | 现场三次实测取上限 |
| 冬天早上老是启动不了 | 环境 -10℃ 冷启动成功率 100%（20 次） | 低温箱循环试验 |
| 这机器太吵，工人不愿意用 | 操作位 1 米 A 计权 ≤ 75 dB | 声级计三点测量 |
| 坏了没人会修 | 关键件 15 分钟内可单人更换，含诊断码指引 | 维修工时验证，非研发人员操作 |
| 精度飘，得天天校 | 连续 8 小时漂移 ≤ 满量程 0.3% | 恒温与变温两组对比 |
转化纪律：没有验收标准的需求不许进 CPD，因为它无法验证，最终会变成扯皮。
七、需求分级：Kano 加 MoSCoW
| Kano 类型 | 特征 | 研发含义 |
|---|---|---|
| 基本型 | 有不加分，没有就出局 | 必须达标，不投多余资源 |
| 期望型 | 越好越满意，与价格线性相关 | 差异化主战场，选 1 到 2 个做强 |
| 兴奋型 | 客户没想到，体验跃升 | 少而精，成本可控才做 |
| 无差异型 | 客户无感 | 直接砍，它只贡献成本 |
| 反向型 | 做了反而讨厌 | 明确写进不做清单 |
映射到 CPD 的 Must / Should / Could / Won't：基本型进 Must，期望型的头部进 Must，其余进 Should，兴奋型看资源，无差异与反向型进 Won't。
八、需求真伪判断：三个证伪问题
拿到一条需求，先用这三问过滤，再决定是否投入设计资源：
- 愿付钱吗：客户愿意为它多付多少，或愿意为它多等多久？说不出数字的通常是聊天。
- 已经凑合了吗：客户是否已用胶带、加人、加检验等方式自己解决？凑合成本越高，需求越真。
- 多久发生一次：一年一次的极端场景，不该驱动主结构设计，可用选配或服务方案覆盖。
三问都弱的需求，记进需求池观察，不进本版本范围。
九、洞察沉淀：需求池怎么维护
| 字段 | 说明 |
|---|---|
| 编号与来源 | 客户名、渠道、CI 活动编号 |
| 客户原话 | 原样引用 |
| 场景与频次 | 何时发生、多久一次 |
| 量化影响 | 时间 / 成本 / 风险 |
| 工程参数草案 | 转化后的可判定指标 |
| Kano 分类 | 基本 / 期望 / 兴奋 / 无差异 / 反向 |
| 三问结论 | 付费、凑合、频次 |
| 归属 | 平台级 / 机型级（链 PLP） |
| 状态 | 观察 / 进入 CPD / 已实现 / 关闭 |
维护节奏：产品负责人月度刷新一次，研发在每个项目立项前必须先检索需求池，避免重复走访客户问同样的问题。
十、研发的 CI 年度基本量
给自己定一个可执行的下限，否则永远排不上：
- 每季度至少一次客户现场，半天以上
- 每半年至少一次完整班次跟机
- 每年至少参与一次竞品拆解
- 每次走访后 3 个工作日内提交一页洞察纪要
- 每份纪要至少产出一条可判定的工程参数
常见误区
- 把客户的方案当需求：客户说要加个风扇，真实需求可能是温升过高，方案该由工程师给。
- 只访谈决策者：签单的人不操作设备，操作者才知道卡点在哪，两类人都要见。
- 样本偏置：只走访关系好的老客户，得到的是存量偏好，看不到流失原因。
- 走访后不转化：录音存了一堆，没有一条变成可判定参数，等于没做。
- 用洞察去证明既有方案：带着结论找证据，最容易的自欺形式。
本周就可以做的三件事
- 从近 12 个月售后工单里拉出 Top 5 失效，标出各自的年成本，形成走访假设。
- 用上文脚本约一位客户做 45 分钟访谈，不谈产品只谈流程。
- 挑三条你手上的模糊需求，用"客户语言到工程参数"表补齐验收标准与验证方法。