1. 为什么做DeskcommCRM：客户信息不该散落在Excel和个人微信里
1.1 坐席场景下的三大痛点
DeskcommCRM这个项目名字，拆开来看是Desk（工作台）+ Comm（通信）+ CRM（客户关系管理），它是我在带团队做客户系统时定下来的设计方向：把坐席人员日常发生的所有客户沟通动作，统一收敛到一个工作台里完成。说白了，销售不用再切工具，客服不用再翻聊天记录，系统自动把客户、对话、跟进状态串成一条线。
做这个项目之前，我们团队也经历过一段“原始社会”阶段。销售手里握着Excel表格登记客户，跟进情况写在个人笔记里，客户打来电话就靠脑子记，回头再补录。那时候最头疼的问题有三个：第一，客户数据不统一，同一个客户可能被登记成“张三”“张先生”“Zhang San”三个版本，内部撞单频繁；第二，沟通记录丢失，打电话说了什么、微信里答应过什么，离职员工一走，这些信息全带走了；第三，管理层看不到过程，只知道销售报了结果，中间环节有没有跟进、客户卡在哪个阶段，全是黑盒。
这三个问题的本质，并不是大家不认真，而是工具链条断裂。CRM如果只做“建客户、写跟进”两张表格，根本解决不了沟通留痕这件事。所以DeskcommCRM从一开始就定了原则：客户管理是底座，通信整合是灵魂，工作台是唯一的交互入口。这个定位决定了后面很多设计取舍，比如为什么要把电话、邮件、站内信全部接入，为什么工作台要常驻侧边栏，为什么每一次状态变更都要推送到前端。
1.2 DeskcommCRM要解决的核心问题
DeskcommCRM要解决的核心问题，一句话就能概括：让客户信息从“个人资产”变成“公司资产”，让每一段沟通都有据可查。具体拆开来看，有四个要达成的目标：
- 客户数据统一：同一客户去重合并，跟进记录沉淀到系统里，不再依赖个人记忆。
- 沟通留痕自动化：电话录音、聊天消息、邮件往来，自动关联到客户档案。
- 过程可追踪：每一个商机阶段、每一次跟进提醒、每一张工单，都有时间线和责任人。
- 权限可控：销售只能看自己的客户，管理者能看到团队全景，敏感字段按角色脱敏。
这四个目标听起来不复杂，但真正落地时要处理的问题非常琐碎。就拿“沟通记录完整”这一点来说，电话录音要解决对象存储和生命周期管理，聊天记录要解决WebSocket消息推送的可靠性，邮件要解决收件箱和客户档案的自动关联，任何一个环节断了，“完整留痕”都是空话。后面我会按照系统落地顺序，从架构、选型、数据模型、权限、部署再到问题排查，把整个实践过程完整记录下来。
2. DeskcommCRM整体设计与技术选型
2.1 系统架构：工作台、通信网关、数据中枢三件套
DeskcommCRM在整体架构上分成三个逻辑层：接入层、业务层、数据层。接入层负责通信渠道的接入，包括电话网关（SIP对接）、邮件服务、WebSocket长连接；业务层负责客户管理、商机、工单、坐席工作台、报表这些核心模块；数据层用MySQL存业务数据、Redis做缓存和分布式锁、Elasticsearch做全文检索、对象存储存录音和附件。
我第一次画这个架构图的时候，其实走过弯路。最早的版本想做一个“超级后台”，把所有功能都塞进一个单体应用里，但后来发现通信模块和业务模块的故障隔离要求完全不一样：电话网关如果崩了，不应该影响坐席正常写跟进记录；报表的慢查询也不应该拖慢实时操作。所以最终把通信网关单独拆成服务，业务服务保留单体但按模块做了分库分表，报表走独立的只读库。
这个设计带来的直接好处是，坐席打电话时即使通信服务短暂抖动，客户资料和工作台依旧能用；高峰期间报表的批量统计任务也不会和在线操作抢占数据库连接池。对于中小团队的人力来说，这种“大单体+独立通信网关+只读报表库”的拆分，比一上来就上微服务要务实得多。如果你团队只有两三个人，我不建议照搬这套架构，先把单体跑通、数据和流程走顺更现实。
2.2 技术栈选型背后的取舍
技术选型这块，我直接说一下最终定下来、并且实际验证过的组合：后端Java Spring Boot，前端Vue3加Element Plus，数据库MySQL 8.0，缓存Redis 6.x，消息队列RocketMQ，检索引擎Elasticsearch 7.x，WebSocket用Spring原生支持的STOMP来承载工作台消息推送。
为什么选Java而不是Go或者Node？一个很现实的原因是团队当时的主力技术栈是Java，招聘和后续维护成本低。Spring Boot在权限、事务、定时任务这些企业级能力上非常成熟，配合MyBatis-Plus做数据层开发效率也不低。如果团队是Node强栈，用NestJS做这套系统后端也完全没问题，核心架构不受语言限制。顺手整理一张我当时做方案对比的表，供参考：
| 对比维度 | Java Spring Boot | Go | Node.js |
|---|---|---|---|
| 企业级生态成熟度 | 高，权限/事务/定时任务现成 | 中等，需自行组装 | 中等，生态偏Web |
| 团队招聘难度 | 低，候选人基数大 | 中等 | 中等 |
| 开发效率 | 中高，注解式开发 | 中，需要写更多样板 | 高，前端同学易上手 |
| 高并发处理能力 | 好，配合MQ和Redis够用 | 极好 | 尚可，但长任务处理需小心 |
前端选Vue3是因为组合式API在管理后台这类重交互场景下写起来比Vue2更清晰，Element Plus的表格、表单、抽屉组件能节省大量UI开发时间。这里提醒一句，工作台页面不要过度依赖第三方组件库的“高级表格”，尤其是树形表格和虚拟滚动，数据量一大就容易卡顿。我被Element Plus树表格坑过，渲染三千个客户节点后页面基本动不了，后来改成懒加载树才缓解。
2.3 为什么必须上WebSocket和消息队列
坐席工作台和普通后台管理系统最大的区别，在于它需要实时性。销售正在和客户打电话，同事在另外一台电脑上更新了这个客户的标签，销售端的界面就应该立刻出现变化；新消息进来，坐席不需要刷新页面就能看到。这就不能用传统的HTTP轮询解决，至少不是最优解。轮询的瓶颈很明显：查得太频繁，数据库和带宽扛不住；查得太慢，消息延迟又没法接受。
我们最终用WebSocket长连接作为工作台的前后端通信通道，后端收到新消息或状态变更事件后，通过STOMP推送到对应坐席的会话里。WebSocket断线重连是必须做的，不能指望浏览器替你维护长连接。前端每30秒发一次心跳，后端对连接做空闲超时检测；一旦断线，前端用指数退避策略重连，最大延迟60秒。这套机制跑了一年，稳定性不错。
消息队列RocketMQ则更偏向于削峰和异步解耦。比如电话网关每小时会产生大量通话记录，如果直接同步写入MySQL，高峰期数据库压力明显。我们的做法是网关先把通话记录投递到MQ，业务服务异步消费、写入数据库，消费失败的任务进入重试队列，保证最终一致性。报表统计也通过订阅MQ里的业务事件来触发增量汇总，避免每次统计都全表扫描。
3. 核心功能模块落地：从客户管理到坐席工作台
3.1 客户全生命周期数据模型
客户数据模型是CRM的地基，这一层设计不好，后面所有功能都别扭。DeskcommCRM里客户相关一共设计了五张核心表：客户主表、联系人表、线索表、商机表、跟进记录表。
客户主表存客户的基本信息，包括客户名称、行业、规模、来源渠道、所属销售、客户状态（潜在、跟进中、已成交、流失）。这里一个关键点：客户主表和联系人表分开，一个客户可以有多个联系人，联系人可能同时属于多个客户，这种多对多关系在真实业务里非常常见。比如一个集团客户，下面有三个子公司，每个子公司有独立的采购对接人，如果只把这三个人分别挂在三个客户下，管理层就无法看到集团全景。所以最终加了客户分组表，通过分组把多个客户关联到同一个上级组织。
线索表用来承接从市场活动、官网留资、地推收集到的原始信息。线索和客户最重要的区别在于：线索只是一个“可能合作的人”，客户是已经确认的合作对象。线索转客户是CRM里最经典的动作，我在设计时让这个动作支持合并操作——如果线索里的手机号和已有客户重复，系统自动提示并允许把线索信息并入现有客户，而不是新建一条脏数据。这个功能看似不起眼，实际使用频率非常高，直接减少大量重复客户。
跟进记录表记录坐席和客户的每一次交互，电话、聊天、线下拜访都统一落在这里。跟进记录不是纯文本，我设计成由“事件类型加文本备注加附件引用加关联商机/工单”组成，这样后续统计“这个月电话跟进了多少次”“哪些客户连续15天没跟进”就非常方便，不用去翻聊天流水或通话流水。
3.2 坐席工作台：让每一次沟通都自动留痕
坐席工作台是DeskcommCRM使用频率最高的界面，设计目标只有一个：让坐席在处理客户沟通时，尽量少切换页面。工作台主要分三个区域：左侧是客户列表，中间是会话与客户详情，右侧是快捷操作和知识库面板。
坐席发起外呼时，系统先查这个手机号是否已经关联客户。如果关联了，直接弹出客户档案，坐席能看到历史沟通记录；如果没有关联，自动创建一个临时线索，等通话结束后补充信息。这个设计最初被产品同事质疑，说“不就得手动查一下吗，能省几秒”，实际上线后外呼效率提升非常明显，坐席基本不用输入电话去搜索，系统自动匹配，误配率也低。
所有通话记录默认自动录音，并在通话结束后把记录写入数据库。录音文件上传到对象存储，数据库里只保存文件路径和通话时长。这里有个省钱的小技巧：对象存储可以配置生命周期规则，超过180天的录音自动转低频访问层，超过一年的自动删除，能省不少存储成本。当然，如果业务要求长期保留某些客户录音，可以单独对这些录音打标，跳过生命周期规则。
3.3 站内信与任务提醒的实时推送实现
工作台里除了被动查看，还有大量主动触达场景：跟进任务到期提醒、新线索分配通知、工单状态变化，这些都需要主动推送给对应坐席。DeskcommCRM的做法是，所有通知先落库，再通过WebSocket推送到在线坐席。落库是为了保证通知不丢，推送是为了提供实时体验，这是两个互相补充的动作，不能互相替代。
具体流程是：后端业务模块产生通知事件后，调用通知服务，先向MySQL的通知表插入一条记录，然后把消息投递到RocketMQ；通知消费服务拿到消息后，根据接收人ID去Redis里查该用户当前连接的WebSocket Session，查到了就通过STOMP推给前端。如果用户不在线，等下次登录时，前端会拉取未读通知列表补全，未读数角标就是从这里算出来的。
这个流程里最容易踩坑的是Redis里Session的存储结构。我们最初用Redis的Hash存储userId到Session的映射，但一台服务崩溃时，这些Session信息全部丢失，前端连接就成了“僵尸连接”。后来调整为Session信息存储到本机内存，Redis里只存当前用户连接到了哪台服务节点，前端重连时通过网关层的路由转发到正确的节点。这个改造在上线后帮了大忙，滚动发布时不会再出现“消息已推送但用户收不到”的投诉。
4. 权限体系与数据安全：让销售只看到自己该看的
4.1 RBAC角色权限模型的落地
DeskcommCRM的权限模型没有搞花活，就是标准的RBAC基于角色的访问控制，但落地时做了几层细化。
第一层是功能权限，控制谁能用哪个菜单、哪个按钮。系统初始化了四个角色：超级管理员、销售主管、销售坐席、客服坐席。超级管理员拥有全部权限，销售主管可以查看团队客户的统计页和导出功能，销售坐席只能操作自己名下客户，客服坐席可以访问工单模块但不能看商机金额。
第二层是数据权限。这块比功能权限复杂得多，因为一个销售主管既要能看到团队所有客户，又不能看到其他团队的客户。我采用的是“数据归属维度”方案：每一条客户数据都记录owner_id和team_id，查询SQL自动带上当前用户的team_id条件。这个逻辑不能靠前端隐藏按钮实现，必须在后端MyBatis-Plus的拦截器里统一拼SQL条件，否则绕过前端就能越权查看数据。我给这个拦截器写了不少单元测试，专测各种角色组合下的查询隔离，这块值得花时间，权限漏洞出一次就是大事故。
4.2 字段级权限与数据脱敏
系统里有些字段比较敏感，比如客户的联系电话、合同金额、身份证号。如果销售主管和销售坐席看到的内容完全一样，其实不合理。DeskcommCRM对敏感字段做了字段级权限控制，后端在返回数据时根据当前用户角色动态决定是否脱敏。电话号码脱敏成中间四位打星号，合同金额只有销售主管及以上角色可见。这个功能在合规审计时是加分项，也减少了不少内部隐私纠纷。
脱敏实现上我用了一个简单方式：在实体类字段上标记@Desensitize(type = "phone")，序列化的时候通过AOP切面判断当前用户角色，决定是否做脱敏替换。这个方案写起来简单，效果直观。但要注意，脱敏只能发生在传输层，数据库里存的还是原始数据，所以数据库账号权限要严格控制，运维脚本和数据分析任务不能直接用业务账号连接MySQL，最好单独申请只读账号，用完之后回收权限。
5. 部署与配置实录：从零到可用的关键步骤
5.1 数据库初始化和核心表结构
部署第一步是初始化数据库。以客户主表为例，我贴一下建表SQL，顺便解释几个容易写错的地方。
CREATE TABLE `customer` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '客户ID', `customer_no` varchar(32) NOT NULL COMMENT '客户编号', `name` varchar(128) NOT NULL COMMENT '客户名称', `phone` varchar(32) DEFAULT NULL COMMENT '联系电话', `industry` varchar(32) DEFAULT NULL COMMENT '所属行业', `source` varchar(32) DEFAULT NULL COMMENT '来源渠道', `status` tinyint NOT NULL DEFAULT '0' COMMENT '状态：0潜在 1跟进中 2已成交 3流失', `owner_id` bigint NOT NULL COMMENT '所属坐席ID', `team_id` bigint NOT NULL COMMENT '所属团队ID', `version` int NOT NULL DEFAULT '0' COMMENT '乐观锁版本号', `deleted` tinyint NOT NULL DEFAULT '0' COMMENT '逻辑删除标记', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_customer_no` (`customer_no`), KEY `idx_owner_status` (`owner_id`, `status`), KEY `idx_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='客户主表';这里几个细节要提醒。customer_no一定不要用自增ID直接充当业务编号，公司内部流转、跨系统对接时，客户编号最好是类似“CU-2025-000123”这种有规则的格式，所以我单独建了一个编号生成服务。version字段加得很有价值，后面解决并发更新冲突全靠它。deleted逻辑删除字段让回收站功能变得简单，但所有查询都要带上deleted=0条件，MyBatis-Plus的@TableLogic注解可以自动拼上，不用手写。
5.2 后端服务配置要点
后端服务是Spring Boot应用，配置文件的几个关键项值得说一下。数据库连接池用的HikariCP，最大连接数设为50，最小空闲连接10。这个数值是根据团队规模（当时大概40个坐席）和接口平均耗时估算出来的，高峰期每坐席同时会有三四个连接占用来支撑页面查询。如果你的团队规模更大，连接池要按“最大并发请求数约等于坐席数乘以5”来预估，别盲目调大，连接池过大会直接拖垮数据库。
Redis主要做三件事：会话Session、分布式锁、WebSocket连接映射。Redis的连接池参数同样需要关注，默认lettuce的线程数在并发高时容易成为瓶颈，我直接把common-pool2的max-total调到了100。下面这段是application.yml里比较关键的一部分：
spring: datasource: url: jdbc:mysql://localhost:3306/deskcomm_crm?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: crm_app password: ${DB_PASSWORD} hikari: maximum-pool-size: 50 minimum-idle: 10 connection-timeout: 30000 redis: host: ${REDIS_HOST} port: 6379 lettuce: pool: max-active: 100 max-idle: 30 min-idle: 5密码我特意用了环境变量${DB_PASSWORD}，生产环境的数据库密码和Redis密码绝对不能硬编码到配置文件里，这是最基本的安全底线。时区参数serverTimezone=Asia/Shanghai一定要加，我之前遇到过因为服务器默认UTC时区导致所有时间字段自动偏移8小时的故障，排查了整整一个下午才定位到。
5.3 消息可靠性：消费幂等和WebSocket重连
消息队列使用过程中最容易出现的就是重复消费。RocketMQ默认是至少投递一次语义，网络抖动、消费超时都可能触发消息重投。如果消费逻辑不是幂等的，就会出现同一通电话的记录写入两次、同一条通知推送两次的情况。
DeskcommCRM的解决方案是给每条消息设置全局唯一的消息ID，消费者在消费前先查Redis的去重表，如果这个ID已经处理过，直接跳过。代码逻辑不复杂，但要注意去重键要设置过期时间，不然去重表会无限增长。我们设置的7天过期，超过这个时间的重复消息在实际业务中几乎不会出现。
WebSocket重连在前端实现时，我建议直接用stompjs配合sockjs-client，常规的重连和心跳配置就够用了。如果确实要自己写，核心点只有两个：心跳间隔不要小于服务端空闲超时时间的一半，重连策略采用指数退避加最大次数限制。我见过有的项目重连逻辑写成了死循环，服务端一重启，前端就连不上，前端就疯狂发请求，直接把服务器打挂。
6. 上线后遇到的坑：问题排查与避坑指南
6.1 聊天消息偶发丢失
上线第一周，客服组长反馈：客户发来的消息偶尔会收不到，刷新页面之后才能看到。初步排查发现这不是消息没写入数据库，而是WebSocket推送没有到达前端。为什么推送会丢？最典型的原因是服务端群发时用了错误的Session对象。
从问题入手分析：客户消息进来以后，MQ消费服务把推送任务交给消息推送服务，推送服务从Redis取到坐席的Session然后调用session.send()。正常情况下没问题，但如果这个Session对应的连接已经断开而Redis里的映射还没及时清除，send()就会抛异常，被消费方当成失败重试。重试又生成新的推送任务，但Session还是那个失效的Session，于是消息一直推送失败，直到坐席刷新页面重新建立连接。
解决方案分两步：第一步，推送失败时立刻从Redis删除失效映射，并通知前端重连；第二步，消费逻辑里加上session状态判断，如果socket不是OPEN状态就不推送，只落库，等前端下一次拉取补齐。这两步做完，消息丢失问题基本消失。
6.2 多个坐席同时跟进同一客户的冲突
第二个高频问题是：两个销售同时跟进同一个客户，A把客户状态从“跟进中”改成“已成交”，B在不知情的情况下又把状态改回“跟进中”，最后系统里客户状态是错的。这类问题本质是并发的丢失更新。
DeskcommCRM的做法是使用乐观锁。在更新语句里带上version条件：
UPDATE customer SET name = #{name}, status = #{status}, version = version + 1 WHERE id = #{id} AND version = #{version}如果更新影响行数为0，说明数据已经被别人改过，前端就提示“该客户信息已被同事更新，请刷新后重试”。这个方法简单可靠，业务场景完全够用。需要注意的是，乐观锁适合更新冲突不那么频繁的场景，如果冲突率非常高，可以考虑用Redis分布式锁，但那样会增加复杂度，CRM里其实用乐观锁的场景占绝大多数。
6.3 报表数据对不上
最后一个是报表数据对不上的问题。CRM的报表模块统计“本周新增客户数”，开发发现报表数字和客户列表搜索出来的数字不一致，差的还不少。排查了很久，发现是统计口径的问题：报表里统计的是客户主表的创建时间，而客户列表默认搜索条件下把“线索转客户”产生的数据也算进去了，但线索转客户那一刻创建时间被重新刷新了，导致时间窗口数据错位。
这个问题的解法是建立“统计口径字典”，在报表模块的开发规范里明确每一个指标的统计SQL和过滤条件，同时把线索转客户后的创建时间保留原值，另外增加一个convert_time字段来记录转换时间。这样“新增客户数”统一按create_time统计，“线索转化数”按convert_time统计，两组数字就能对得上了。
除此外，我还遇到过时区导致报表差8小时的坑，这个在上面配置部分说过了。每当有同事问我“报表怎么又不对”，我的第一个问题永远是：先看时间过滤条件，再看时区，最后才去看SQL逻辑。这个排查顺序帮我省了大量时间。
做DeskcommCRM这半年多，我最大的感受是：CRM系统难的不是技术，而是业务建模时的取舍。很多看似细小的决定，比如客户和联系人要不要分表、线索转客户要不要支持合并、会话消息要不要先落库再推送，都会在后续使用中被无数次放大。所以在动手写代码之前，花大量时间把业务规则梳理清楚，比什么都重要。
如果你也在做类似的项目，建议先别急着上微服务，把单体架构跑通、把核心模块的边界划清楚，再根据实际瓶颈扩展。系统的价值不在于用了多新的技术，而在于它到底帮业务省了多少时间、沉淀了多少数据资产。DeskcommCRM到现在还在持续迭代，我下一步打算把AI辅助坐席的意图识别、自动填单加进来，让工作台再“聪明”一点。但无论功能怎么演进，那句老话一直管用：让每一次沟通都有迹可循，让每一个客户都被认真对待。
