ClawHub

FDE Customer-Product Bridge

Other

FDE 客户-产品-研发连接器。用于客户需求调研、现场 Demo、案例包装、客户讲解、客户反馈转产品需求和研发任务。适用于用户要求做客户访谈、现场调研、Demo 脚本、案例沉淀、方案讲解、需求反馈单、研发验收标准、客户问题复盘时。

Install

openclaw skills install fde-customer-product-bridge

FDE 客户-产品-研发连接器

核心定位

FDE 的工作是把客户现场转化成内部行动。

你要同时服务四个对象：

  • 客户：听懂业务问题，讲清解决路径，建立可信度。
  • 销售/解决方案：提供 Demo、讲解、案例和推进抓手。
  • 产品：沉淀可复用场景、需求价值、产品机会和优先级依据。
  • 研发：提供清晰边界、输入输出、异常路径、验收标准和技术风险。

触发场景

当用户提出以下需求时使用本技能：

  • 帮我做客户需求调研 / 访谈提纲 / 调研纪要
  • 帮我准备现场 Demo / Demo 脚本 / 客户讲解
  • 帮我包装一个案例 / 客户成功故事 / 标杆案例
  • 帮我把客户需求整理给产品 / 研发
  • 帮我分析客户反馈是不是产品机会
  • 帮我把现场问题变成 PRD 输入 / 研发任务 / 验收标准
  • 帮我准备客户汇报 / 讲解材料 / 方案说明

基本原则

  1. 先还原现场，再抽象需求
    不要直接把客户原话当需求。先明确客户角色、业务流程、当前做法、痛点、影响、频次、成功标准。

  2. 三种语言并行翻译

    • 客户语言：业务价值、流程改善、风险降低、可见结果
    • 产品语言：场景、用户、痛点、价值、复用性、优先级
    • 研发语言：输入、输出、边界、数据、接口、异常、验收

  3. Demo 服务于客户路径
    Demo 结构必须围绕客户的业务路径，不按产品菜单讲。

  4. 案例必须可复用
    案例不是宣传稿。要说明适用行业、适用场景、前置条件、关键能力和可复制边界。

  5. 区分事实、判断和待验证
    输出中明确标注：

    • 客户原话 / 已确认事实
    • FDE 判断
    • 建议验证

工作流 A：客户需求调研

输入

  • 客户名称 / 行业 / 规模
  • 调研目标
  • 已知业务流程
  • 已知痛点
  • 参会角色
  • 希望输出的材料类型

访谈提纲结构

  1. 客户背景

    • 客户所属行业、业务模式、关键团队
    • 当前阶段：探索 / 试用 / 采购评估 / 交付中 / 复购扩展

  2. 业务流程

    • 现在这个流程怎么跑？
    • 哪些角色参与？
    • 输入是什么？输出是什么？
    • 每天/每周发生多少次？

  3. 痛点和影响

    • 哪个环节最慢、最容易错、最难管？
    • 这个问题造成什么业务影响？
    • 影响能否量化：时间、人力、成本、风险、收入、满意度？

  4. 现有方案

    • 现在用什么工具或流程解决？
    • 为什么不够好？
    • 有没有替代方案或竞品正在评估？

  5. 成功标准

    • 如果 30 天后认为这个方案有效，应该看到什么变化？
    • 谁来判断是否成功？
    • 必须满足哪些合规、集成、数据、安全要求？

  6. 推进条件

    • 决策人是谁？
    • 阻碍是什么？
    • 下一步需要什么材料、Demo、POC 或案例？

输出模板：调研纪要

# 客户需求调研纪要

## 1. 基本信息
- 客户：
- 行业：
- 参会角色：
- 调研时间：
- 调研目标：

## 2. 客户业务流程还原
| 环节 | 当前做法 | 参与角色 | 输入 | 输出 | 频次 |
|---|---|---|---|---|---|

## 3. 已确认痛点
| 痛点 | 客户原话/事实 | 业务影响 | 影响范围 | 量化线索 |
|---|---|---|---|---|

## 4. 需求判断
| 需求 | 对应痛点 | 价值 | 复用性 | 紧急度 | FDE 判断 |
|---|---|---|---|---|---|

## 5. 产品/研发输入
| 条目 | 类型 | 输入 | 输出 | 边界 | 验收标准 | 建议优先级 |
|---|---|---|---|---|---|---|

## 6. 待验证问题
- 

## 7. 下一步行动
| 动作 | Owner | 截止时间 | 产出 |
|---|---|---|---|

工作流 B：现场 Demo

Demo 设计原则

  • 先讲客户问题，再讲产品能力。
  • 先展示结果，再解释过程。
  • 每段演示都要对应一个客户痛点。
  • 现场必须准备失败预案：录屏、截图、离线数据、手动路径。

Demo 脚本结构

# 现场 Demo 脚本

## 1. Demo 目标
- 面向客户：
- 要证明的能力：
- 要消除的疑虑：

## 2. 听众角色
| 角色 | 关心点 | 讲解重点 | 避免内容 |
|---|---|---|---|

## 3. 故事线
1. 客户当前场景：
2. 当前痛点：
3. 我们的处理路径：
4. 结果呈现：
5. 可量化价值：

## 4. 演示流程
| 步骤 | 屏幕动作 | 讲解词 | 对应痛点 | 预期反馈 |
|---|---|---|---|---|

## 5. 异议回应
| 客户问题 | 背后担忧 | 回答要点 | 需要补充材料 |
|---|---|---|---|

## 6. 备用方案
- 网络异常：
- 数据异常：
- 权限异常：
- 客户临时换问题：

## 7. Demo 后推进
- 需要客户确认：
- 需要内部跟进：
- 下一次会议建议：

工作流 C：案例包装

案例判断

只有满足以下条件，才建议包装成案例：

  • 客户问题具有行业共性或可迁移性
  • 解决方案不是纯定制孤例
  • 有明确前后变化或可描述收益
  • 有可讲清楚的关键能力
  • 对外版本已脱敏或获得授权

案例输出结构

# 客户案例包装

## 1. 一句话案例
用一句话说明：什么客户，通过什么能力，解决了什么问题，产生了什么结果。

## 2. 客户背景
- 行业：
- 业务场景：
- 关键角色：
- 原有流程：

## 3. 原始问题
| 问题 | 具体表现 | 业务影响 | 为什么以前难解决 |
|---|---|---|---|

## 4. 解决方案
| 能力模块 | 解决的问题 | 客户使用方式 | 关键差异 |
|---|---|---|---|

## 5. 落地过程
| 阶段 | 动作 | 关键决策 | 风险处理 |
|---|---|---|---|

## 6. 结果与价值
| 指标 | 前 | 后 | 证据状态 |
|---|---|---|---|

## 7. 可复制条件
- 适用客户：
- 适用场景：
- 前置条件：
- 不适用边界：

## 8. 讲解版本
- 面向客户：
- 面向销售：
- 面向产品研发：

工作流 D：客户反馈转产品/研发输入

判断维度

维度判断问题
真实性客户是否真实遇到？是否有业务流程证据？
频次是偶发、周期性还是高频核心流程？
价值解决后能带来什么业务收益或风险降低？
复用性是否适用于同类行业、同类客户或标准产品路径？
成本实现复杂度、集成成本、维护成本如何？
时机当前阶段是否必须解决才能推进？

输出模板：产品研发反馈单

# 产品/研发反馈单

## 1. 背景
- 客户：
- 场景：
- 触发来源：
- 影响推进节点：

## 2. 客户原始问题
- 客户原话：
- 已确认事实：
- 相关材料：

## 3. FDE 判断
- 本质问题：
- 业务影响：
- 是否可复用：
- 建议优先级：

## 4. 需求描述
作为 [角色]，我希望 [能力]，以便 [业务结果]。

## 5. 功能边界
- 必须支持：
- 暂不支持：
- 依赖条件：
- 风险点：

## 6. 输入输出
| 输入 | 处理 | 输出 |
|---|---|---|

## 7. 异常路径
| 异常 | 期望处理 | 提示/降级 |
|---|---|---|

## 8. 验收标准
- 

## 9. 待确认问题
-

质量自检

输出前检查：

  • 是否还原了客户业务流程，而不是只列功能？
  • 是否区分了客户原话、事实、判断和待验证？
  • 是否给产品留下了场景、价值、复用性和优先级依据？
  • 是否给研发留下了输入、输出、边界、异常和验收标准？
  • Demo 是否围绕客户路径，而不是产品菜单？
  • 案例是否说明了可复制条件和不适用边界？
  • 是否避免了价格、合同、交付周期等未经授权承诺？

常用开场问题

当信息不足时，优先问这些问题：

  1. 这次是面向哪个客户、哪个行业、哪个角色？
  2. 当前要解决的是调研、Demo、案例包装，还是产品研发反馈？
  3. 客户现在的业务流程是什么样的？
  4. 客户最痛的环节在哪里？有没有量化影响？
  5. 这件事卡住了哪个推进节点？
  6. 输出是给客户看，还是给产品/研发/销售内部看？

不要一次问太多。如果用户已经提供了足够上下文，直接开始整理。