先说结论
Odoo CRM 自动分配不是“给每个销售写一个每天上限”。
源码把容量拆成三层：
assignment_max：成员30 天平均容量；lead_day_count：最近 24 小时 已分到多少；_get_assignment_quota()：把前两者折算成这次还能不能继续分。
再加一个特例：
force_quota=True时，手工分配可以忽略今日已分量，直接按日配额满额发。
所以它设计的不是“绝对限流器”，而是平滑投放机制。
一、assignment_max 不是“今天最多几条”
crm.team.member.assignment_max 的字段说明写得很清楚：
Average Leads Capacity (on 30 days)
也就是说，它描述的是一个成员在 30 天尺度上的平均承载能力。
随后 _get_assignment_quota() 会把它除以 30，再做四舍五入，得到每天大致可接量。
所以如果你把 assignment_max=60，系统更接近理解成：
- 平均每天 2 条；
- 而不是“某一天可以一次性塞 60 条”。
二、为什么看的是最近 24 小时，不是自然日
lead_day_count 用的是“当前时间往前 24 小时”的窗口。
这比按自然日更真实，也更连续。
好处是：
- 不会因为刚过午夜就瞬间清零；
- cron 一天跑多次时，不会把同一天的负载假装成多天；
- 更适合滚动式分配。
代价是业务上会出现一种体感：
昨晚分过很多，今天上午看起来“今天还没开始”，但系统仍认为你很忙。
这不是 bug，而是滚动窗口语义。
三、30 天统计的作用，不是直接限流，而是给管理层看节奏
lead_month_count 统计的是最近 30 天已分配数量。
它主要用于：
- 让 team 看成员长期接单量；
- 判断 team 总分配量是否超过总容量；
- 形成
lead_all_assigned_month_exceeded这类管理信号。
所以 24 小时计数更偏即时节流，30 天计数更偏中期容量观察。
四、为什么还要保留 force_quota
源码在 _cron_assign_leads() 和 action_assign_leads() 里故意分了两种场景：
- cron 场景：默认考虑今天已经分了多少；
- 手工分配：常带
force_quota=True，允许这次把额度补满。
这很符合实际运营。
因为管理员手工点“现在就分配”，往往是在处理积压，不希望系统再说： “抱歉，这个人过去 24 小时已经接过两条了，所以今天先不派。”
五、最常见的误解
1. 把 assignment_max 当作今日上限
错，它本质是 30 天平均能力。
2. 以为零点后额度会重置
错，窗口是滚动 24 小时。
3. 以为手工分配和自动 cron 口径完全一样
错，force_quota 会改变行为。
4. 以为“月度超额”一定代表今天不能再分
也不对。月度超额更多是管理提醒，不等同于即时硬阻断。
六、排错顺序
当你发现“为什么这个销售今天还没接单却不给他分”时，先查：
- 最近 24 小时内是否已大量分配；
assignment_max是否太低；- 是否走的是 cron 而不是手工强制分配；
- 该成员有没有
assignment_optout或 domain 限制； - team 总容量是否已被其他成员吃掉。
一句话记忆
Odoo CRM 的自动分配不是按自然日清零的日上限，而是用“30 天平均能力 + 近 24 小时已接量”来做平滑投放。
DISCUSSION
评论区