小团队用 CRM 时，很多规则可以靠人记。谁在跟哪个客户，哪个线索应该优先处理，哪个客户已经很久没联系，主管问一圈大概就能知道。

团队变大以后，这套方式很快失效。线索数量上来，客户经理变多，主管要看的不再是单个客户，而是整个过程有没有被执行。这个时候 CRM 最先暴露出来的，往往不是页面不够多，而是分配、流转和统计口径不够清楚。

线索池不能只是一个列表

我早期对线索池的理解很简单：先把广告和渠道进来的线索集中起来，再分给客户经理。但真正跑起来以后，会发现线索池不是一个静态列表，而是一套业务调度机制。

它要知道线索从哪里来，是否重复，是否已经有人处理，多久没有跟进，是否应该回收，主管能不能看到团队整体状态。列表只是表现形式，背后是规则。

如果这些规则不进入系统，分配就会越来越依赖人工判断。人少时可以，人多时会变成争议和低效。

客户经理需要明确的拥有关系

CRM 里最重要的关系之一，是客户和客户经理之间的拥有关系。

这个关系看起来简单，但它会影响很多后续问题：谁能看客户详情，谁能写跟进，谁负责转化，主管统计归到谁，客户长期未跟进后是否回到公海。

我会尽量避免让“客户归属”只停留在口头或 Excel 里。只要团队开始扩大，归属关系就应该进入系统，并且能被权限、列表、统计和回收规则使用。

主管视图不是多一个页面

团队变大以后，主管需要的不是把客户经理页面复制一份，而是另一种视角。

客户经理关心自己今天要跟进谁，主管关心哪些线索没有被处理、哪些人跟进效率低、哪些渠道质量好、哪些阶段卡住。两个视角都来自同一批数据，但问题完全不同。

所以我在设计 CRM 时，会把执行视图和管理视图区分开。执行视图强调下一步动作，管理视图强调过程是否健康。只有这样，系统才不会只服务录入，也能服务管理。

统计口径要早一点稳定

CRM 的统计如果只在后期补，很容易出现口径不一致。

比如一条线索什么时候算有效，什么时候算已跟进，重复手机号要不要算进新增，回收客户算不算新分配，渠道质量看提交量还是有效量。这些问题如果系统早期没有记录基础字段，后面很难补。

我不认为早期统计要很复杂，但基础口径要尽量稳。否则团队越大，大家越容易围绕数字争论，而不是围绕业务动作改进。

增长会把系统边界推出来

这类 CRM 演进让我意识到，团队规模变化会把很多原本隐藏的系统边界推出来。人少时靠沟通能解决的问题，人多以后必须变成规则、权限、状态和数据。

我现在看 CRM，不会只看它能不能录客户、写跟进，而会看它能不能承受团队变大后的管理压力。线索池、客户归属、分配规则、主管视图和统计口径，这些东西不一定一开始都很完整，但方向必须提前想清楚。