上一篇我写了竹润相关项目里，从 WordPress 官网到产品展示和预约咨询系统的完整交付链路。那条链路更偏外部入口：客户从哪里看到信息，怎样提交咨询，业务方怎样接住。

这篇继续往内部走，写我当时怎么理解和拆解 CRM。

我以前接触和搭建 CRM 时，最容易看到的一种起步方式是：建一张客户表，做一个列表页，加几个筛选条件，再允许业务人员写跟进记录。这样的系统能解决“有地方记”的问题，但不一定能解决“业务能被管理”的问题。所以我后来越来越倾向于先想关系，再想页面。

客户是谁，来自哪里，归谁维护，属于哪个部门，联系过几次，持有哪些产品，跟哪些代销合作方有关，后续是否还有企业微信触点，这些问题如果我一开始没有给它们结构，后面页面再多也只是更复杂的表格。

客户不是一行资料

我当时没有把客户信息简单放进一张表里。对我来说，客户资料只是入口，真正要保留下来的是客户在业务过程中的变化。所以我把客户的类型、状态、来源、等级、机构、职务、联系方式、备注、负责人和部门先作为基础信息，再围绕客户拆出联系人、跟进记录、持仓记录等关系。

这里背后的判断很简单：客户不是一行资料，而是一个会不断产生上下文的对象。

一个客户刚进入系统时，可能只有姓名、机构和联系方式。业务人员接触几次之后，就会出现跟进记录、联系人补充、需求判断、产品兴趣、持仓变化和后续处理状态。系统如果只把这些东西写进备注，短期很快，长期很难查、很难统计，也很难交接。

所以我在设计这类 CRM 时，会优先把“客户资料”和“客户过程”拆开。资料描述客户当前是谁，过程描述系统如何理解这个客户、谁维护过、发生过什么、下一步应该怎样处理。

持仓是业务状态，不是备注

我做金融服务类 CRM 时，会特别注意客户持仓不能只作为跟进备注存在。

我当时把客户持仓、客户持仓记录、产品、产品销售和产品数据拆成了相对明确的模块。这样的拆分看起来比“在客户备注里写一句持有某产品”更麻烦，但它解决的是后续管理问题。

只要持仓被结构化，我就可以让系统围绕产品反查客户，围绕客户查看产品状态，围绕持仓变化补充跟进记录。业务人员看客户详情时，看到的就不只是联系方式，而是客户和产品之间的真实关系。

这些关系一旦进入结构化数据，我后续才有可能继续做统计、筛选、导入、复盘和权限控制。否则它们只是散落在不同人的聊天记录和个人表格里。

代销合作要有自己的对象

我还把代销合作单独拆成了一个模块，里面有代销对象和代销跟进记录。

这对我来说是一个小但重要的边界。代销合作方不是普通客户，也不完全等同于产品。它有自己的类型、状态、相似信息、备注、负责人和跟进过程。如果我为了省事把它硬塞进客户表，早期能少建几个页面，但后面会在字段含义和业务动作上越来越别扭。

我现在看这类系统，会更在意对象边界是否清楚。不是所有东西都应该拆成独立模块，但一旦我发现一个对象有独立生命周期、独立负责人、独立跟进方式，就会认真考虑给它自己的结构。

否则系统表面上简单，实际是把复杂度推给了使用者。

导入、权限和组织结构不是边角料

在我的经验里，CRM 真正上线后，最先暴露的问题往往不是页面，而是数据进入系统和人在系统里的边界。

我给客户和代销都保留了 Excel 导入入口。这个功能看起来普通，但对真实业务很关键。很多内部数据最初不会从一个完美系统里流入，而是来自历史表格、人工整理和阶段性迁移。导入能力不是高级功能，而是让系统能接住现实数据的入口。

权限和组织结构也一样。我把部门、用户、角色和权限作为内部系统的基础部分处理，并接入企业微信认证。对一个内部 CRM 来说，客户归属、部门边界、谁能看哪些数据、谁能维护哪些资料，都会直接影响业务安全感和使用意愿。

如果早期完全不考虑这些边界，后面很容易出现两个问题：要么所有人都能看到所有数据，业务方不敢把真实数据放进系统；要么权限临时补丁越来越多，维护成本很快超过功能本身。

仪表盘不是装饰，而是反馈

我也做了仪表盘，以及客户、直销、代销、目标进度相关的状态组件。对于内部系统，我不太喜欢把仪表盘做成纯展示页面。它应该回答一个更实际的问题：系统里沉淀的数据，能不能反过来帮助管理者和执行者看清状态。

客户有多少，来自哪里，跟进情况怎样，产品销售如何，代销合作推进到哪一步，这些信息如果只存在列表页里，管理者需要自己反复筛选。我做仪表盘时更看重的，是把常看的业务状态稳定地浮出来。

当然，我不认为早期仪表盘需要复杂。它更像是系统和业务之间的反馈回路：先把关键指标摆出来，再根据真实使用情况调整口径。只要数据结构是清楚的，这条反馈回路就能逐渐变好。

CRM 的核心不是“记录”，而是“可继续管理”

这类项目给我的长期影响，是让我更早意识到：CRM 的第一目标不是把信息记录下来，而是让信息在后续还能被管理。

如果客户资料、联系人、跟进、持仓、产品、代销、部门和权限都没有清晰关系，系统只能变成更正式的 Excel。它看起来是一个后台，实际仍然依赖人脑记忆和人工对照。

所以我判断一个 CRM 是否打好了基础，不会只看它一开始有多少功能，而会看几个关键问题有没有答案：

• 客户和业务过程是否拆开？
• 产品和持仓是否能被结构化查看？
• 代销合作是否有独立生命周期？
• 历史数据能否通过导入进入系统？
• 组织、角色和权限是否能支撑真实使用？
• 企业微信等外部触点是否有机会和客户记录连接？

这些问题决定了系统后续能不能从“可记录”走向“可管理”。回头看，这个 CRM 给我留下的不是某个后台页面的实现细节，而是一个更稳定的判断：真实项目里决定系统寿命的，往往不是页面数量，而是客户、产品、组织和触点这些关系有没有在一开始被认真对待。