自建CRM系统实战：从数据模型到权限与性能优化的完整指南

1. 从Excel到自建系统：DeskcommCRM立项时最关键的三个决定

1.1 为什么通用CRM在我们这里跑不起来

DeskcommCRM这个名字，是我和团队一年前定下来的。当时公司的销售团队还在用Excel管客户，几十个销售每人维护一份表格，撞单、漏跟、离职带走客户资源，几乎每周都在上演。我们也认真评估过几款现成的CRM系统，功能很全，价格也不便宜，但试用一段时间后发现问题不是功能不够，而是逻辑太僵化。

通用CRM最常见的一个问题，是销售团队根本不配合录入。系统要求把每一个客户塞进固定的漏斗阶段，字段不能改、流程不能调，表单还特别重。销售白天在外面跑客户，晚上回来还要花半小时填系统，填完又看不到对自己的好处，自然选择敷衍。数据没人录，系统就变成空壳，主管看着空荡荡的看板又开始逼着补录，最后陷入恶性循环。我们后来想明白一件事：CRM的核心痛点从来不是软件本身，而是销售愿不愿意用。如果一套系统不能让一线销售感觉到效率提升，那么功能再强大也都是白搭。

另一个潜在问题，是现成系统的后期改造成本。试用时感觉还可以，但真正接入公司业务后会发现，客户来源、商机阶段、审批链路都有行业特色。通用软件的扩展要通过配置或续费模块，有些逻辑甚至要联系服务商定制开发，周期按季度算。一个小团队根本耗不起这种节奏，这就是我们下定决心自建DeskcommCRM的直接原因。

1.2 三个决定：服务销售、先数据后管理、MVP边界

自建之前我拉着团队坐下来聊了几轮，最后定下三个关键决定，后来的开发一直沿着这三个方向走。

决定一，把“让销售少干活”作为第一设计原则。DeskcommCRM的第一批功能，不是给管理层做复杂的统计报表，而是先给销售提供明确的效率工具：自动算出下次跟进时间，一键查看某个客户的全部沟通历史，快速找到今天该联系但还没联系的人。这些功能让销售觉得系统是助理，而不是监控工具。观念转变之后，数据录入就不再是痛苦的任务，而是顺手操作的一部分。

决定二，先有数据再谈管理。上线初期我们只保留了公司名称、负责人、电话等几个基础必填项，行业、规模、来源这些字段一律允许为空。如果一开始就逼着销售把所有字段填齐，系统很快就会被抛弃。等到系统里积累了一定数据，再逐步引导销售补全，比如通过数据完整度评分和批量补录提醒来推动，效果比强制校验好得多。

决定三，MVP边界必须画清楚。第一版只做“录入客户、记录跟进、查看漏斗、基础提醒”这条闭环，报表、权限、批量导入、公海这些功能全部放到后面迭代。很多人一开始就想做全功能，结果一个模块都没做透。我们把主链路打磨顺畅后，再上权限和报表，反而推进得更快。

2. 数据模型才是CRM的灵魂：客户、联系人、跟进记录怎么建模

2.1 客户和联系人为什么要拆成两张表

DeskcommCRM第一版的数据模型，我花的时间比写接口还多。最核心的一个设计决策，是把客户和联系人拆成两张表。客户本质上是一个组织，联系人则是这个组织下具体的沟通对象，比如一家公司里可能有老板、采购负责人、技术对接人，他们之间的角色完全不同。如果不拆分，一张客户表里出现同一个公司的多条记录，统计客户总数时就会翻出大量脏数据。

商机也不应该直接挂在客户表上。一个客户可能同时在推进多个商机，金额、阶段、预计成交时间都不一样，如果在客户表里加一个“商机金额”字段，一客户多商机时数据就会互相覆盖。下面是我们当时实际落地的核心表结构，可以直接参考。

接触客户的第一个动作往往是加上联系方式，所以contact表里有一个is_primary字段，标记主要联系人。筛选客户列表时，默认展示主要联系人；没有标记时则选择最近创建的那一个。这个字段看起来很小，但直接影响列表页和信息卡的展示逻辑，后面很多功能都依赖它。

2.2 跟进记录：时间线不是一句日志那么简单

跟进记录是CRM里数据量增长最快、也最容易设计失误的一张表。DeskcommCRM的跟进记录表叫follow_up，核心字段包括：id, customer_id, contact_id, user_id, content, action_type, next_follow_at, created_at。content用纯文本存储，不做富文本。富文本虽然在展示上好看，但会引入XSS风险，而且全文搜索和导出都很麻烦。分析沟通内容时，纯文本加简单的结构化标签比富文本可靠得多。

action_type用代码字符串表示，比如call、meeting、wechat、email，不在数据库里用enum枚举。因为业务阶段一定会调整，数据库enum类型改起来成本太高，字符串加代码维护就灵活得多。时间线查询优化经验也很关键：按customer_id和created_at建联合索引，列表页按时间倒序一次只加载20条，滚动到底再加载更多。不要试图在客户详情页一次性加载全部跟进记录，数据量上来之后接口会直接卡死。

还有一个在真实使用中暴露出来的问题，跟进记录和商机的关系不能做成必填。第一版我们要求销售每次跟进必须勾选关联的商机，结果数据一塌糊涂，销售随便选一个。后来改成系统根据该客户当前正在推进的商机给出推荐，销售确认就行，错误率大幅下降。关联错了，漏斗数据分析就会失真，这是CRM准确性的大敌。

2.3 软删除与归档：删除客户不是真删除

DeskcommCRM一开始就在客户表里预留了deleted_at字段，但真正把软删除贯彻到位，是在一次误删事故之后，后面第6章会详细复盘。现在所有业务表的删除操作都默认标记deleted_at，查询统一带过滤条件，用数据库视图或者ORM全局作用域来保证不会漏写。

用户端多了一个回收站入口，管理员可以在30天内恢复被删除的客户。对于已经有跟进记录、商机数据或历史成交的客户，系统不允许物理删除，只允许标记为“弃用”，避免破坏历史关联和统计口径。

归档逻辑也需要提前设计。我们定义了一个规则：客户超过180天没有跟进记录、没有进行中商机、也没有未完成任务，自动进入归档视图，不再出现在销售的主列表里。这样主列表不会越积越大，销售每天处理的数据都是活跃客户，系统查询性能也更稳定。归档不是删除，只是给它一个更靠后的默认排序，数据永远可以回溯到。

3. 技术选型复盘：这组技术栈是怎么定下来的

3.1 后端：NestJS + PostgreSQL，而不是Java或Go

技术选型这件事，团队成熟度比技术流行度重要得多。我们团队当时最熟悉的是TypeScript，所以后端直接用NestJS，开发效率高，前后端语言统一，沟通成本低。Java Spring功能确实强大，但团队里没有深度掌握的人，学习成本和项目周期都不可控。Go写网络服务性能很好，但做CRM这种围绕业务CRUD的系统，开发效率和生态成熟度反而不如Node.js体系。

很多朋友问我为什么不做微服务。CRM是典型的业务管理系统，核心挑战在流程梳理和数据建模，不在高并发。我们的使用规模就是几百个内部用户，单体应用配清晰模块边界完全能撑住。微服务带来的部署复杂度和调试成本，在团队规模不大的时候是纯负担。NestJS的模块化结构让我们在单体内部也能保持边界清晰，比如客户模块、跟进模块、权限模块各自独立，后面拆服务也有基础。

ORM方面，第一版选了TypeORM，因为NestJS官方生态对它的支持最好。但用下来发现TypeORM在某些复杂查询上很别扭，后期统计分析很多都直接用QueryBuilder或原生SQL。如果让我重新选一次，会更关注Prisma这类类型安全更强的方案，写复杂业务查询时的体验好很多。

3.2 前端和桌面端：Deskcomm的“桌面沟通”如何落地

Web端用了Vue3加TypeScript加Element Plus，没有特别新潮，但非常稳。选定这套组合的核心原因是团队对Vue最熟悉，组件库成熟，遇到问题搜得到答案。前端界面上我们刻意控制复杂度，没有引入太重的状态管理方案，业务数据基本在页面级别流转，配合Pinia管理用户状态和权限信息就够了。

“Deskcomm”这个名字当初定下时，本身就有“桌面上保持沟通”的意味。产品稳定后，我们把Web端用Tauri包了一层桌面工作台，因为销售和客服需要长时间开着系统，浏览器标签页一多就很容易误关，而且系统级提醒和托盘数字角标体验也比浏览器通知好很多。Tauri比Electron轻非常多，安装包体积小，内存占用低，对老电脑很友好。但当时Tauri生态还在早期，系统通知、自动更新这些能力踩了不少兼容性坑。

经验是：没有Rust背景的团队，第一版别直接上桌面端，先做Web加浏览器通知就够。桌面端只承担导航、通知、本地缓存和托盘功能，所有业务逻辑还是走Web API，这样即便桌面端出问题也不影响核心数据。

3.3 PostgreSQL比MySQL更适合CRM的几个理由

数据库选型是DeskcommCRM里争议最大的决策。之前团队默认用MySQL，后来我坚持换成了PostgreSQL，用下来觉得这是CRM场景下最正确的选择之一。

PostgreSQL的JSONB类型帮了大忙。客户的自定义字段、联系人扩展属性、还有各种配置信息，都可以在JSONB里存，业务加字段不用频繁改表结构。数组类型也实用，给客户打标签时直接用数组存，SQL里用操作符判断包含关系，比另建关联表简单很多。窗口函数在销售排名和漏斗转化率统计上几乎是刚需，一句ROW_NUMBER() OVER就能搞定复杂排名。

更关键的是行级安全（RLS），这一项直接决定了数据隔离方案。CRM里销售只能看自己的客户是很基本的要求，RLS可以在数据库层强制实现，应用层就算出现越权Bug也不会把全公司客户泄露出去。再加上pg_trgm扩展实现高效模糊搜索，PostgreSQL在CRM这个场景的综合匹配度确实比MySQL高。MySQL很多功能要用拼接字符串或额外表来实现，维护成本会随着业务复杂度快速上升。

4. 销售漏斗、跟进提醒、数据看板：三个功能落地的关键细节

4.1 销售漏斗的阶段设计与统计口径

DeskcommCRM的商机阶段，从第一版的4个扩展到了现在的6个：新建、跟进、方案报价、谈判、成交、输单。阶段数量不建议超过6个，太细的颗粒度只会增加销售录数据的负担，对管理分析没有实质帮助。一个重要的技术决策是，stage_code用字符串代码再加order排序字段，不要用数据库enum。业务阶段一定会调整，比如后来加了“暂缓”，如果用enum就要改表结构，生产环境风险大，字符串代码只需要在配置里加一行。

漏斗转化率的统计口径，是很多所谓CRM系统做得最粗糙的地方。很多人直接把当前各阶段商机的数量画成漏斗，这只能表示存量分布，不能表示转化率。真正的转化率应该这样算：进入“报价”阶段的所有商机中，最终成交的比例是多少。要支持这样的分析，必须有stage_change_history表，记录每次商机阶段变更的时间、操作人、旧值和新值。有了这个历史表，才能计算每个阶段的转化率和平均停留时长，也才能回答“商机在谈判阶段卡了多久”这类问题。

商机金额字段要区分“合同金额”和“预期金额”。销售在早期阶段填的往往是预期金额，水分较大；成交之后回填的合同金额才是财务口径。主管看板上应该同时展示这两个数字，差距太大就说明销售对商机判断过于乐观。我们还在商机表里加了一个赢单率字段，按阶段预置参考值，但允许销售根据实际情况调整，这也是经验之谈：不要被系统预设绑架。

4.2 跟进提醒：让销售少干活，而不是多填表

跟进提醒功能，第一版设计得过于理想化，险些成了摆设。最初的方案是完全自动：每天扫描客户资料里的“预计下次跟进日期”，生成待办并推送。问题在于这个日期不能凭空产生，它必须来自某次跟进动作。第一版把“设置下次跟进时间”做成跟进记录里的一个可选字段，销售经常不填，结果到了第二天提醒里空空如也，整个功能形同虚设。

后来改成强制闭环：销售完成一条跟进记录后，弹窗要求选择下次跟进时间，不选就默认一周后。这个交互虽然多了一步，但数据准确率从不到三成提升到九成以上。经验就是：跟进完成之后再设置下次时间，远比事先让销售规划可靠，因为人的记忆点天然跟最近一次行动绑定，而不是跟日历绑定。

提醒推送通道，我们接入了企业微信应用消息和站内通知，没有做短信。短信成本高且容易打扰客户，销售也不喜欢。定时任务用node-cron每分钟跑一次，扫描next_follow_at在未来24小时内的记录，生成待办并推送。销售可以自己设置提醒时段，比如只在9点到20点之间接收，避免下班后被打扰。

4.3 数据看板：老板和销售看到的东西不一样

看板功能我们发现一个原则：角色不同，看的东西必须不同，不能用同一套指标全公司铺开。销售首页只显示个人的今日待跟进、本周新增客户数、我的商机总额；销售主管看团队漏斗、转化率、回款计划；管理层看整体趋势和目标完成度。这三个看板不是同一个页面的三个tab，而是三个独立接口，各自返回对应的指标字典，前端不需要把全部数据拉下来再按权限刷选。

统计性能上，有一个容易被忽视的问题：不要在主表上做实时count。客户量到5万、跟进记录到几十万之后，实时统计接口会拖慢整个系统。我们用物化视图每5分钟刷新一次统计结果，查询直接读物化视图，响应时间控制在100毫秒以内。对实时性要求高的只有“我的待办数”，这个单独走Redis计数，完全能扛住。

指标定义也必须在开发前明确清楚。平均成交周期的口径是：商机创建时间到状态变为“成交”的时间差，统计月维度时是按当月成交商机计算。销售如果修改历史商机的状态，看板数字会波动，所以阶段变更的审计日志必须保留。另一个要注意的，是漏斗转化率不要作为月度指标直接对比，因为商机周期可能横跨好几个月，对比意义会失真。

5. 权限与数据安全：小团队最容易糊弄的部分

5.1 用PostgreSQL行级安全实现销售数据隔离

DeskcommCRM的权限体系，靠的是数据库底层的行级安全。4种角色分别是超级管理员、销售主管、销售、只读访客。销售默认只能看到owner_id等于自己ID的客户，主管能看整个团队的数据，管理员和访客按模块单独授权。这个需求如果只靠后端代码实现，每一处查询都要手动拼接条件，很容易漏掉某个接口造成越权。

PostgreSQL RLS可以直接在数据库层做强制隔离，策略如下示例。启用之后，所有查询自动带上权限过滤，即便后端某个查询条件写漏，也不会把全公司客户暴露给普通销售。

CREATE POLICY customer_isolation ON customer USING ( owner_id = current_user_id() OR current_user_role_id() IN ('admin', 'manager') );

启用RLS后有一个开发期容易踩的坑：后台任务、定时任务也必须显式设置当前用户上下文，否则走数据库会话时默认拿不到user_id，后台会看到一片空白。我们后来写了一个统一的数据访问层，所有任务上下文自动带上系统用户，排查起来也方便。列级权限方面，销售列表页的手机号和微信号默认脱敏，显示成138****1234，导出需要主管审批。这个脱敏必须在后端做，不能只靠前端隐藏，因为浏览器调试工具一抓接口就能看到明文数据。

5.2 审计日志与导出追踪

审计日志是权限体系的另一半。DeskcommCRM的audit_log表结构很简单：id, user_id, action, resource_type, resource_id, before_data, after_data, ip, user_agent, created_at。before_data和after_data用JSONB字段存修改前后的行快照，查历史记录时可以直接对比。我们没做全量日志，因为全量记录数据量大、噪音多，只针对关键表和敏感字段记录：客户资料修改、商机金额修改、删除操作、导出操作、权限变更。这样既控制了存储成本，又覆盖了核心风险点。

导出操作追踪是审计体系里比较有意思的一个方案。导出的Excel文件会在隐藏单元格里写入当前操作者的user_id，字体颜色设为白色，一般人不注意根本看不到。一旦客户数据被泄露，拿到文件后一查文档属性或者扫描隐藏单元格，就能知道这份文件是谁在什么时候导出的。技术上不复杂，但威慑作用很实在，销售团队对客户数据的处理态度明显谨慎了很多。

5.3 备份与恢复演练：只备份不恢复等于没备份

数据安全领域有一句话我一直放在心上：只备份不恢复等于没备份。DeskcommCRM的备份策略是每天凌晨2点用pg_dump做全量备份，同时开启WAL归档，目标是能够恢复到任意时间点。备份文件上传到另一个存储空间，和主服务器物理隔离，防止服务器故障时备份也跟着丢。

更关键的是每个季度做一次恢复演练。把备份文件在一台临时实例上恢复，然后对比关键表的行数，确认临时库能正常启动和查询。第一次恢复演练我们就发现WAL归档配置少了一个参数，导致恢复只能恢复到昨天凌晨2点的全量，中间一天的增量数据全部丢失。这个问题如果发生在事故当天，损失和复现复杂度都会大得多。恢复演练不需要太频繁，一季度一次足够，但必须认真做、按真实事故的恢复流程做。

6. 从开发到上线的踩坑记录：数据恢复、Excel导入、慢查询

6.1 误删700条客户数据的事故复盘

DeskcommCRM上线一个多月后，发生过一次让我到现在都后怕的事故。当时运营同学在管理后台做测试数据清理，批量勾选了一批客户，点了“删除”，而当时的删除接口写得很粗暴，直接执行了物理DELETE。等发现问题时，已经有700多条真实客户记录从主表里消失了。

处理过程现在已经沉淀成标准流程：先停止所有写操作，避免数据状态继续变化；然后检查应用日志，确认所有删除都通过同一个接口、集中在某个时间段内；接着把最近一次全量备份恢复到临时库，找回删除前的完整数据；对于删除之后新录入或修改的数据，靠审计日志逐条补录。整个过程用了大约三个小时，因为刚好在当天凌晨做过全量备份，损失勉强可控，但过程相当紧张。

事故复盘后我们改了三个地方：所有业务表的删除操作全部改为软删除，查询默认过滤deleted_at；管理后台的删除按钮要求输入“确认删除”才能触发，增加操作门槛；删除操作强制写入审计日志。后来数据恢复也用到了回收站功能，能在界面上直接恢复出30天内删除的客户，不用再翻备份文件。

6.2 Excel导入：乱码、日期格式与科学计数法

Excel导入是CRM系统里看起来简单、实际坑特别多的模块。销售上传Excel时，中文乱码、日期字段被Excel自动转换、手机号显示成科学计数法、字段里夹着换行符和前后空格，这些问题我们第一版全踩了一遍。

解决办法分几层。第一层是强制模板，但模板不能保证所有销售都按规范填。第二层是代码容错：读取文件时自动识别编码，中文乱码的问题从源头解决；日期列统一解析为YYYY-MM-DD格式，如果遇到Excel数字型日期，比如45123这种代表某个日期的序列数，需要先转回日期再格式化；手机号统一按文本读取，去空格后只保留11位数字，避免科学计数法。前端预览环节会在导入前把校验结果展示出来，错误行号和原因直接告诉用户，而不是等导入到一半再回滚。

有一次导入800行客户数据，因为其中一行客户名里有非法控制字符导致整体回滚，用户非常崩溃。改成逐行校验和逐行写库之后，出错时只标记失败行，剩余数据正常导入，体验好很多。导入完成后还会展示一个摘要：成功数、失败数、重复数。重复客户默认跳过或用新数据补充，不会直接覆盖原有内容，避免误更新。

6.3 客户列表从1.8秒到80毫秒的调优过程

数据量到了5万条客户记录后，列表接口开始变慢，最典型的是客户名模糊搜索。用户在搜索框输入“华东”，SQL大概是WHERE company_name LIKE '%华东%'，这种写法走不了普通B-tree索引，只能全表扫描。5万行时勉强能忍，到20万行后接口直接卡到秒级。

定位慢查询用的是PostgreSQL自带的pg_stat_statements扩展，把统计出来的TOP语句拉出来，第一名就是客户搜索。解法是给company_name建了pg_trgm的GIN索引，让模糊搜索从全表扫描变成索引扫描，响应时间一下子从秒级降到百毫秒级。如果用的是MySQL，这种场景要折腾全文索引或者另外接Elasticsearch，配置成本完全不一样。

列表分页方式也做了一次彻底改造，从OFFSET页码分页改成了游标分页。原来的分页在深翻页时会很慢，比如跳到第100页，数据库要先扫过前2000行再取目标数据。而且CRM列表的数据变动很频繁，用户A在翻页的同时用户B新增了一条记录，下一页就可能出现重复或漏行。游标分页用WHERE id < last_id ORDER BY id DESC LIMIT 20，每次只拿上一次返回的最后一条记录ID作为起点，性能稳定且不会出现翻页不一致的问题。优化后整个列表接口从1.8秒降到80毫秒，体感差别非常明显。

7. DeskcommCRM下一个版本：公海、RFM分层与自助报表

7.1 客户公海与分配机制

公海是一个偏向销售管理的功能。逻辑不复杂：客户连续N天没有跟进，或者商机全部输单，自动退回到公海；公海里的客户，销售可以主动领取。实现上容易踩的坑是并发领取。多个销售同时点击领取同一个客户，如果只是先查询再更新，两个请求都会判断“当前没人领”，结果同时更新成功，客户被重复分配给两个人。正确的做法是走数据库原子操作，例如UPDATE customer SET owner_id=当前用户 WHERE id=某客户 AND owner_id IS NULL，然后判断受影响行数，只有等于1才代表领取成功。

公海回收规则还应该支持按团队配置，不同行业的客户跟进周期差异很大。有些B2B业务客户跟进周期是两周，有些消费级业务三天不跟进就凉了。版本迭代时打算把N做成可配置项，由销售主管在自己的团队设置里调整。

7.2 RFM客户价值分层：给高价值客户更好的服务

RFM模型不是一个新鲜概念，但在CRM里落地价值很高。R代表最近一次成交时间，F代表成交频率，M代表成交金额。用SQL窗口函数可以对每个客户算出三个维度的分位，分成高、中、低三档，组合出8类客户。比如“重要价值客户”是R高、F高、M高的客户群体，“流失预警客户”可能是R低但历史M高的客户。

真正难的不是计算，而是业务动作跟上。系统给出分层之后，必须配套跟进策略模板和提醒规则，比如重要价值客户建议7天跟进一次，流失预警客户建议3天内主动联系一次。如果分层只是停留在标签上，销售看完也不会改变自己的行为，整个功能就变成了一场统计游戏。

7.3 自定义报表：用JSON配置驱动查询

报表需求是提不完的。今天要一个地区销售排名，明天要一个产品线成交对比，每个部门都有自己的口径。如果靠硬编码一个个做，开发资源根本排不过来。所以DeskcommCRM规划中的自定义报表模块，核心思想是用JSON配置驱动：每个报表就是一个JSON对象，里面定义数据源、筛选条件、分组维度、聚合字段、图表类型，后端根据JSON动态生成聚合查询，前端根据JSON渲染图表。这样新增一个报表不用发版，运营和主管自己拖拽配置就行。

配置化报表最需要小心的是查询安全性。动态SQL生成必须做严格的字段白名单校验，字段名、聚合函数、排序方向都要限制在允许的集合里，防止有人构造出恶意配置把整个数据库拖垮。计算类指标尽量复用物化视图，或者接受几分钟级别的数据延迟，不建议在报表查询里直接对千万级明细表做实时聚合。

如果现在让我重新设计一遍DeskcommCRM，我不会一开始就把看板模块做得那么重，而是会把更多精力放在让销售更愿意记录数据的交互细节上。一个系统最怕的不是功能少，而是没人用。DeskcommCRM这个名字一直在提醒我：客户管理的本质是沟通的沉淀，先把“沟通”这个动作做顺，数据自然会积累起来，后面的管理和分析才有意义。