18 商业化交付、ROI、验收与变更管控

章节目标

掌握 FDE 项目商业化交付方法：范围锁定、工时评估、报价、ROI、验收指标和需求变更管控。

开篇案例：为什么“按人天报价”容易亏

一个团队按 20 人天报价做企业知识库 PoC。开始时范围只是制度问答，客户试用后不断追加：接入审批系统、支持多部门权限、增加 IM 入口、做后台配置页、导出使用报表。团队不好拒绝，因为合同只写了“完成智能问答系统”，没有写不做什么、验收样本和变更规则。

最后项目既超期又难验收。问题不在开发能力，而在商业化交付没有设计：FDE 项目必须把范围、里程碑、验收、变更池和客户成功指标写清楚。

AI 项目越不确定，商业边界越要明确。

咨询交付模式变化

最后核对：2026-07-11

企业 AI 咨询正从“报告交付”转向 联合编码、联合上线和联合运营：

FDE 型交付的核心卖点是：可运行系统 + 可验证指标 + 可交接运营机制，而不是更厚的咨询 deck。

报价层级

报价说明怎么写

## 本期范围

- 支持 1 个业务场景：客服售后政策工单。
- 接入 2 类知识资料：FAQ、SOP。
- 支持 1 个查询型工具：订单状态查询。
- 输出：分类、引用、回复草稿、转人工建议。

## 不在本期范围

- 不自动退款或赔付。
- 不接入全部历史系统。
- 不承诺替代人工坐席。
- 不覆盖所有产品线。

## 验收方式

- 30 条 Golden Dataset。
- 坐席试用 2 周。
- 指标：分类准确率、引用准确率、采纳率、高风险转人工准确率。

写清“不做什么”不是保守，而是为了让项目能交付。

范围锁定

项目范围必须写清：

• 做什么。
• 不做什么。
• 先做什么。
• 后做什么。
• 哪些假设成立才继续。

PoC 不应承诺全自动、替代专家判断或直接改核心系统。

工时评估

工时可拆成：

• 需求访谈。
• 资料准备。
• ETL。
• RAG。
• Agent / Workflow。
• 工具集成。
• 评估。
• 部署。
• 培训。
• 运营交接。

ROI 方案

ROI 要先写人工基线：

• 现在多少人参与。
• 每次多久。
• 每月多少频率。
• 错误、返工或延迟造成什么成本。
• 管理层最关心什么指标。

AI 改造收益可以来自节省人时、减少返工、缩短周期、提高转化、降低风险和提升满意度。

验收指标

常见指标：

• 准确率。
• 召回率。
• 引用准确率。
• 工具成功率。
• 生成时间。
• 人工采纳率。
• cost per task。

验收样本要在项目早期确定，避免上线前临时改变标准。

变更管控

每个变更都要判断是否新增：

• 数据源。
• 系统接口。
• 用户角色。
• 执行动作。
• 合规风险。
• 评估样本。

非关键需求放入变更池，不打断当前 PoC。

客户成功指标

商业化交付还要定义试用后的客户成功指标：

• 采用：活跃用户、任务频次、自助完成率。
• 信任：人工修改率、引用采纳率、投诉率。
• 效率：单次任务耗时、排队时长、首响时间。
• 经济：cost per task、节省人时、ROI 回收周期。
• 风险：高风险动作拦截率、审计通过率、回滚次数。

这些指标应写入合同附件或验收附录，避免“系统可用”式模糊承诺。

变更池样例

变更池让客户知道需求被记录了，但不会无声吞掉当前交付范围。

实操任务

为你的场景写一页商业方案：

• 人工基线。
• AI 改造收益。
• 范围边界。
• 工时假设。
• 验收指标。
• 变更规则。

交付物

• ROI 分析。
• 报价和工时假设。
• 验收标准。
• 变更管控表。

常见误区

• 只按开发人天报价。
• 验收指标写“系统可用”。
• 把不可控目标写进承诺。
• 不管理试用后的需求膨胀。

检查清单

• 是否写清不做什么？
• ROI 是否从人工基线开始？
• 验收是否有样本支撑？
• 变更是否评估数据、接口、权限和风险影响？