CRM 项目失败，往往不是败在功能，是败在口径

在一个连锁医疗客户的项目里，我们花了整整两周没写一行代码，只做一件事：把每个业务指标的定义讨论清楚。

客户一开始觉得慢。但调研时我们发现，40 家门店对"成交"的理解有四个版本：有的算签约，有的算首次付款，有的算全款到账，有的算完成首次服务。

系统不能解决定义问题

如果这四个版本的理解带进系统，结果是每家店的数字都"对"，但汇总起来毫无意义。这不是技术问题，加多少字段都解决不了。

更麻烦的是，这类问题在上线后才暴露。那时数据已经录了几个月，要改口径就得回溯清洗。

口径文档先于数据模型

我们现在的固定流程是：调研之后先出一份指标口径文档，逐条列出每个指标的定义、计算方式和例外情况，由业务方书面确认。

这份文档后来成了数据模型的直接依据，也成了验收时的对账基准。

这件事必须由业务方拍板

技术团队可以主持讨论、可以指出矛盾，但不能替业务方决定"成交"是什么意思。我们见过太多项目里，因为业务方不愿意做这个决定，最后由开发凭感觉定了，然后所有人都不满意。

把决定权还给该决定的人，是这一步最重要的部分。