先说结论
Odoo CRM 里的 day_open 和 day_close，不是完整的销售效率仪表盘。
源码写得很直接：
date_open：第一次出现负责人 时记时间；day_open：创建时间到 date_open 的天数差；day_close：创建时间到 date_closed 的天数差。
所以它们回答的是两个很窄的问题：
- 这条线索多久才第一次有人接；
- 这条记录从创建到关闭，历时多少天。
它们不会自动告诉你：
- 中间是否多次换人；
- 是否跨 team 反复流转；
- 是否因为手工改概率而提前写了关闭时间；
- 是否只是丢单归档，而不是走完了完整销售过程。
一、date_open 不是“开始跟进时间”，而是“第一次被分配时间”
在 _compute_date_open() 里，判断条件非常克制：
- 只有
user_id出现时才写； - 而且只在原本
date_open为空时写入。
这意味着：
一条线索只要第一次被分配给销售，
date_open就定下来了。
后面再换负责人、再改 team、再补活动，都不会把它重新定义成“真正开始认真跟进”的时间。
所以很多团队看到“Days to Assign 很短”就以为响应效率很好，其实未必。系统只能证明这条记录很快被挂到了某个人名下，不能证明已经完成了有效触达。
二、day_open 统计的是创建到首次分配，不是创建到首次联系
_compute_day_open() 用的是 create_date 和 date_open 做绝对天数差。
注意几个边界：
1. 它按天差，不是精确工时
源码直接取 (date_open - create_date).days。
所以：
- 晚上 23:50 建线索；
- 第二天 00:10 才分配；
从业务上只差 20 分钟，按天差却可能已经跨天。
2. 没负责人就没有 day_open
如果你的流程把大量线索先放在 team 池里，等每日批量分配，day_open 会天然偏大。它反映的是“归属确定速度”，不是“线索进入系统速度”。
3. 清空负责人会把 date_open 清空
在 write() 里，如果 user_id=False，源码会把 date_open=False。这会让某些记录的分配统计被重置，看起来像“从未正式打开过”。
三、day_close 统计的是创建到关闭，不区分赢单还是丢单
_compute_day_close() 同样只看 create_date 与 date_closed。
而 date_closed 的来源比很多人想的更宽：
- 概率被写到
>=100； - 记录被置为
active=False； - 进入赢单阶段；
- 某些丢单动作把它归档并把概率置零。
也就是说，day_close 是记录关闭耗时，不是“成交耗时”。
如果你的漏斗里大量记录很早就被判 lost，平均 day_close 甚至会看起来“效率很高”，但这只是淘汰快，不等于销售好。
四、为什么有些数字会突然跳变
最常见的原因有四类。
1. 批量改负责人
会改写一批记录的 date_open。
2. 批量改阶段
如果新阶段是 is_won=True，源码会连带把概率拉到 100，并写 date_closed。
3. 把记录归档当作业务清理
在 CRM 里，归档常常带有 lost 语义，不只是“前台不显示”。
4. 手工写概率
probability >= 100 会触发关闭时间；probability > 0 又会把关闭时间清空；这会让一些记录在报表里前后反复。
五、正确的理解方式
如果你想把这三个字段拿来做运营判断，最好这样拆：
day_open：看分配机制是否拖延；day_close：看从进入系统到退出系统的周期；- 活动、会议、chatter：补足真实跟进强度；
- 阶段更新时间：补足过程推进节奏。
不要让 day_close 一个人承担“销售周期、跟进质量、赢单效率、线索卫生”四种解释。
六、排错顺序
看到指标不对时，按这个顺序查最快：
- 看
user_id是否被批量改过； - 看
date_open是否被清空或重写； - 看
date_closed是因赢单、丢单还是手工概率写入； - 看记录是否长期留在未分配池；
- 再去讨论 KPI 口径，而不是先怀疑报表组件。
一句话记忆
Odoo CRM 的
day_open统计“多久才第一次有人接”，day_close统计“多久退出漏斗”，它们都不是完整销售效率的全景答案。
DISCUSSION
评论区