Odoo CRM 预测报表为什么不能只看 expected revenue：prorated revenue、lost reason 与 Pipeline Analysis 口径讲透
很多团队拿 Odoo CRM 报表时只盯着 expected revenue，结果越看越乱。官方报表真正更依赖的是 stage、deadline、prorated revenue、won_status 与 lost reason 这些维度；如果你不先分清预测值和原值，漏斗、forecast 与丢单复盘都会失真。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo CRM 跟进节奏为什么不能只看“下一活动”：mail.activity plan、会议接力与活动报表链路讲透
很多人把 Odoo CRM 的活动机制理解成一个 next activity 提醒器，但源码已经给出更完整的节奏设计：先用 activity plan 标准化动作，再把会议从商机上下文接过去，最后用 CRM activity report 回看执行质量。
Odoo CRM 线索为什么还在堆积：Pause Assignment、空 quota 与成员 domain 漏斗的排查顺序
很多团队看到 CRM 里未分配线索堆积，会先怀疑 cron 没跑。基于 Odoo 官方源码，这篇文章按真正执行顺序拆开：team 是否参与分配、线索是否进入候选池、成员 quota 是否已空、preferred domain 与 assignment domain 是否把候选漏掉，以及为什么命不中成员时系统根本不会转商机。
Odoo CRM 的 pipeline 为什么会‘发霉’：rotting threshold、最后阶段更新时间和漏斗卫生
很多销售团队会说‘这批商机卡住了’，但 Odoo CRM 在源码里并不只把它当主观感受。系统专门用 rotting threshold、date_last_stage_update 和 won_status/type 组合，判断哪些机会是真的在漏斗里放坏了。
Odoo CRM 里的 Lost 为什么不是一个普通阶段：archive、restore、date_closed 和 lost reason 边界
很多人会把‘丢单’理解成把商机拖到一个 Lost 阶段，但 Odoo CRM 的源码语义并不是这样。真正的 lost 更接近 archive + probability=0，再加上 lost reason、date_closed 和 restore 时的概率回滚逻辑。
Odoo CRM 为什么有些商机会排到前面：next activity、my_activity_date_deadline 和 meeting 信号
很多人觉得 Odoo CRM 的列表排序有点‘聪明得过头’，明明机会金额不大，却总排在前面。源码里这不是玄学，而是 activity 截止日期、my_activity_date_deadline、meeting_display 和日历入口在一起塑造出来的跟进信号。
Odoo CRM 自动分配为什么不是‘平均发线索’：team 容量、成员 quota 和 preferred domain 讲透
很多团队以为 Odoo 的自动分配就是轮流把 lead 派给销售。源码其实复杂得多：先按 team 容量做分桶，再按成员 quota、domain 和 preferred domain 做二次分配，还会顺手 deduplicate。