4
0### p01 企业买 FDE 服务，该为什么付费？
企业买FDE服务，到底该为什么付费？关键是流程有没有改善，以及交付后留下了什么能力。FDE不是一种统一的收费模式，更不是高收益的保证。今天从采购和验收的角度，讲清楚企业怎样把这笔钱算明白。
### p02 企业愿意付费的，是落地中的缺口
企业往往不是没有工具，而是工具和日常工作之间还有一段缺口。模型会写跟进记录，却不知道线索由谁接手。系统能识别发票，却不清楚例外由谁批准。这些问题涉及业务规则、数据口径和系统协同。能把它们接通的人，才有值得付费的交付价值。这里讨论的是价值逻辑，不是市场需求增长的统计。
### p03 别只问上线了没有，要问改善了什么
拿售后工单做一个示意。过去只验收能不能分类，现在要看整条流程：信息是否齐全，分派是否正确，复杂问题有没有人工处理路径，解决后能否更新知识。上线一个分类功能不等于完成了改进。把处理周期、返工和质量放在一起看，企业才知道这个项目是否真正有用。
### p04 先定义基线，再讨论收益
我建议先定义基线，再讨论收益。改造之前记录业务量、处理成本和质量，改造之后用相同口径继续记录。同时把部署、模型调用、维护和人工复核等新增成本算进去。还有一点很容易忽略：省下时间，可能只是释放了产能，不一定立刻减少现金支出。两者都可能有价值，但不能混着算。
### p05 付费方式，按项目条件选择
付费方式并没有唯一答案。范围明确的项目，可以按阶段和交付物验收。需要长期维护的，可以采购持续服务。结果可衡量、责任边界也清楚时，可以把部分费用和业务改善挂钩。但不能说所有FDE都应该按降本分成。结果如果受销量、人员和其他系统影响，先把归因机制讨论清楚，比谈一个分成比例更重要。
### p06 项目结束后，要留下可运行的能力
除了项目效果，我还会追问交付后留下什么。至少要有能运行的流程，能解释的数据和规则，能维护的接口与权限，以及清楚的文档和责任人。企业要知道，项目团队撤出之后谁来维护，规则变了谁来改。否则，这一次看起来成功，下一次改动又只能重新找人从头做。
### p07 今天先写一页采购需求
今天可以选一个重复、费人力、又有明确负责人 的流程，写一页需求。写清现在怎么做，问题在哪里，用什么基线和口径验收，项目结束后谁维护。再拿这页纸向不同服务方询问方案。你会更容易看出，报价里买到的究竟是一次交付，还是一套能持续使用的能力。关注AI落地实践，也欢迎告诉我你最想改造的流程。
