DeskcommCRM 这个项目最开始就是一张越用越卡的 Excel 客户表。做销售管理的朋友应该都懂客户线索、跟进记录、商机预测全堆在表格里协作全靠互相问数据完全靠人肉维护。后来我把它做成了一套真正可用的 CRM 系统从需求梳理、数据建模到权限控制、数据看板再到容器化部署前后踩了不少坑。这篇博文就把整个项目从零到一的完整过程拆开讲一遍包括每个环节为什么这么做、核心功能怎么落地、上线后常见问题怎么排查。适合准备自建 CRM 的中小团队也适合想系统了解 CRM 后端设计的工程师参考。先说清楚项目本身没有用太花哨的架构技术栈就是 Spring Boot MySQL Redis Vue 3核心是把销售业务逻辑理清楚让系统真正能被团队日常用起来。1. 项目定位与整体设计思路1.1 为什么中小团队更需要一套“够用”的 CRM市面上现成的 CRM 产品不少但价格和复杂度往往超过中小团队的承受范围。Salesforce 一类国际大厂的产品功能全可配置项多到让人无从下手实施周期动辄半年费用对多数团队来说更是不小的负担。国内的一些 SaaS CRM 虽然上手快但业务流程是固定的销售阶段、字段、权限模型全按通用模板走团队一旦有自己的打法反而不容易适配。DeskcommCRM 的定位就是解决这个问题以 B2B 销售跟进为主线覆盖线索、客户、联系人、商机、合同、回款的基础闭环再配合跟进记录、日程提醒、数据看板这些日常高频功能。系统不追求大而全但要把销售团队每天真正在用的功能做扎实。比如销售打开系统能快速看到今天要跟进的客户点进客户详情能看全所有联系记录和商机进展月底报表自动算好每个人的转化率这就已经能替代 Excel 和一堆聊天记录里的零散信息了。自研 CRM 的好处不止是省钱。团队的业务流程可以完全按照自己的销售方法论来设计销售阶段叫什么名字、多少概率、跟进节奏怎么定都由自己说了算。系统内部的数据口径统一后续想接财务系统、企业微信、短信平台也方便。当然自研也要付出维护成本所以这个方案更适合技术团队有一定开发能力、而且销售流程相对稳定的组织。如果团队连需求都说不清楚建议先花一个月把现有销售动作盘清楚再动手。1.2 系统边界与核心模块划分项目启动第一步不是写代码而是把系统的边界画出来。CRM 最忌讳一开始就把进销存、客服工单、财务核算全塞进来会让整个系统的复杂度和风险急剧上升。我按“最小可用闭环”的原则把 DeskcommCRM 分成了七个核心模块模块核心功能主要使用角色线索管理线索导入、分配、转客户市场、销售客户管理客户档案、360度视图、共享协作销售、管理者联系人管理联系人维护、角色识别、关联商机销售商机管理销售阶段推进、预计金额、赢单输单销售、管理者跟进记录电话/拜访/微信等跟进留痕销售合同回款合同登记、回款计划与实收销售、财务数据看板个人/团队业绩、转化漏斗、预测管理者模块划分清楚后表结构、权限边界、接口范围才会跟着清晰。比如线索和客户是两套概念线索是未验证的潜在客户经过跟进确认后可以一键转换成客户商机挂在客户下但可以关联多个联系人这就构成了最基本的数据关系骨架。我在这部分最想提醒的一点是先不要急着把“工单”和“售后”加进去。CRM 的核心服务对象是销售过程售后的场景通常伴随工单状态流转、SLA 时效、客服分配等机制跟销售跟进逻辑差异明显。硬塞进一个系统会让数据库和权限模型都变得异常复杂不如后续做成独立模块或独立服务来扩展。2. 数据模型与业务实体设计2.1 客户、联系人、商机的建模要点颜色越深的坑往往是设计阶段留下的。DeskcommCRM 的数据模型我实际上重构过两轮第一轮的问题就是把所有字段塞一张宽表结果客户有20多个字段大部分还都用不上。后来才想明白CRM 的核心实体应当是“客户、联系人、商机”三者分离组合起来描述整个销售对象。客户表保存组织级信息客户名称、行业、规模、来源渠道、客户状态、所属行业、地址、负责销售、创建时间等。每个客户可以有多个联系人联系人表保存姓名、职位、手机、微信、邮箱、是否关键决策人、生日等信息。商机表则保存一笔可能的交易关联客户 ID记录预计成交金额、销售阶段、成交概率、预计成交日期、竞争对手、输单原因等字段。三者是典型的一对多关系一个客户有多个联系人和多笔商机。这里有个设计细节容易被忽略商机与联系人之间也有关联。一个商机的报价过程可能会涉及客户的采购经理、技术负责人、老板等多个人。为了支持这个问题我建立了一张关联表 sans tu 闾即商机联系人关系表记录某个商机涉及哪些联系人以及联系人在商机中的角色。这样在做商机详情页时就能直接展示“联系人参与矩阵”报价发给了谁、谁拍板一目了然。字段类型上建议提前规划公共字段主键统一用 bigint 自增 ID业务编号比如客户编号可以另外生成创建时间和更新时间由数据库统一维护逻辑删除标志位用 deleted 字段避免物理删除带来历史和关联问题。自定义字段是后话但数据表设计时需要预留方案我放在下一节单独讲。2.2 跟进记录与阶段转换的状态机设计销售CRM里最容易被做成一锅粥的就是“跟进”和“商机阶段”。很多团队一开始只用文本框记录“今天跟客户聊了啥”结果想在系统里查“上周所有打了电话但没写内容概要的跟进”完全捞不出来。所以在 DeskcommCRM 里跟进记录被设计成结构化数据跟进类型电话/拜访/微信/邮件/其他、跟进时间、跟进对象客户或商机、跟进内容摘要、下次跟进时间。这些字段共同支持后续的列表筛选、日程提醒、统计报表。商机阶段则要设计成状态机而不是一列字符串。阶段字段定义在枚举或字典表里比如“初步接触 - 需求调研 - 方案报价 - 商务谈判 - 赢单/输单”。每个阶段可以配置允许转换到哪些阶段比如只有进入“方案报价”阶段才能点击“赢单”已经输单的记录不能再直接变回“初步接触”。这样能避免销售把商机阶段改来改去数据失真。阶段转换还需要记录历史和原因。转换历史表包含商机 ID、从哪个阶段到哪个阶段、操作人、操作时间、备注。备注可以是“客户预算不足”或“竞争对手降价”等。这部分数据对后面分析赢单率、平均成交周期、输单原因分布非常重要。很多团队只关注结果表忽略了这种过程数据后面做报表时才发现缺料。我的经验是状态机定义要用独立配置表而不是硬编码在前端下拉框里。因为销售策略一变阶段可能从五个变成六个硬编码就意味着改代码发版。配置化之后管理员在后端界面改字典前端自然跟着变。这是 CRM 这种业务迭代频繁的系统里很关键的设计。2.3 字段扩展性配置化而不是频繁改表CRM 系统最烦人的需求之一就是“给客户加一个字段”。如果每次加字段都改数据库表、改后端实体、改前端表单开发效率会被拖垮。我在 DeskcommCRM 里采用了一种轻量级扩展方案每张主表额外包含一个ext_json字段用来存业务自定义字段的 JSON 对象。前端表单根据字段配置动态渲染后端只负责把 JSON 原样存取。具体做法是维护一张custom_field_config配置表每行定义字段所属对象类型客户/联系人/商机、显示名称、字段编码、字段类型文本/数字/下拉/日期、是否必填、下拉选项 JSON、排序号。前端加载配置后在表单区动态生成对应的输入组件值统一放入表单对象的customValues里提交时序列化成 JSON 存入ext_json。列表页如果要按自定义字段筛选则通过特殊查询条件在 JSON 里用 JSON_CONTAINS 或索引生成列来处理MySQL 5.7 以上都能支持。这个方案有几个明显的好处加字段不出代码、不同行业可以用一套系统容纳不同模型、字段流转不会因为结构硬编码而出错。但也有边界——它不适合需要频繁聚合统计的关键业务字段比如“客户成交金额”这种必须参与报表计算的字段还是应该建独立列并加索引。折中做法是把少数核心字段显式建模如状态、金额、时间把大多数非结构化信息丢进扩展 JSON。这样平衡了灵活性和查询性能。3. 关键功能落地与实操3.1 客户 360 度视图一个页面看清所有信息销售每天打开客户详情最烦的就是在十几个页面之间跳来跳去找信息。DeskcommCRM 上线后的第一个重点功能就是客户 360 度视图目标是一屏展示客户全貌基本信息、联系人列表、商机列表、跟进记录、待办任务、合同回款记录、操作日志。接口设计上我一开始采用单接口串行查询结果客户数据多的时候响应时间到了 4 秒以上很卡。后来改成并行查询后端用一个聚合服务同时发起客户信息、联系人列表、商机列表、跟进记录等多个查询等所有结果返回后组装成一个大对象返回前端。Java 里用 CompletableFuture 或者简单用线程池并行MySQL 查询本地库本身很快瓶颈主要在串行 IO 和网络等待并行后接口响应稳定在 800 毫秒左右。前端页面则用 Tab 来组织信息块默认展示概览点击“商机”切到商机列表。Tab 的好处是首屏加载快不需要一次渲染所有信息配合懒加载用户点哪个 Tab 才请求对应接口体验比一次返回全部数据流畅得多。为了加快速度客户概览里只显示最新三条跟进记录想看完整历史再到“跟进记录”Tab 里分页加载。这条经验很值得提360度视图不是简单堆接口而是要考虑“用户第一步想看什么”。销售第一眼看的一定是客户状态和跟进时间然后才是商机和联系人。所以我把“最近跟进时间”“下次跟进时间”“商机总金额”这种摘要字段放在顶部卡片区由聚合 SQL 直接计算返回不用前端逐个加总数据更一致。3.2 跟进日志与日程提醒让销售不靠脑子记事情“跟进记录”只是事后留痕真正的效率提升在于“下次跟进时间”的提醒。销售每天上班打开 DeskcommCRM首页就显示今天到期和已逾期的跟进任务这才是系统粘性的关键。为此我设计了三个相互配合的机制记录跟进时填写下次跟进时间、定时任务扫描生成待办、消息中心集中推送提醒。待办任务的实现不复杂但容易做臭。我先建了一张待办表包含待办类型跟进客户/联系电话/拜访商机、关联对象 ID、计划时间、负责人 ID、状态。当销售在跟进记录中设置“下次跟进时间为明天上午”时系统立即写入一条待办记录状态为 pending。定时任务每分钟扫描一次查到计划时间在当天且状态是 pending 的待办就进入消息中心推送提醒。到了计划时间超过 24 小时仍没完成待办自动升级为逾期在首页用红色高亮。消息推送我使用了站内信和邮件两种通道没有接短信和企微原因是成本和维护复杂度。站内信用一张消息表推送给用户后在系统右上角弹未读数邮件则是一个定时任务每早 8 点把当天待办汇总发给用户用 JavaMail 发送测试时容易被当成垃圾邮件需要配置好 SPF 和 DKIM 记录。记住不要在每次生成待办时立刻发邮件否则一天下来邮件轰炸谁也受不了。这个模块最容易踩的坑是“重复待办”。举个例子跟进记录保存两次或是同一商机被多个人同时跟进会导致同一条业务数据生成多个待办。解决办法是生成待办前先按“负责人关联对象待办类型计划日期”查重如果已存在同样待办就跳过。还有就是要允许用户手工完成任务并填写实际完成时间辅助后续分析销售的执行力和响应周期。3.3 数据权限模型谁能看到哪些客户CRM 的权限设计是整个项目里最难的部分我记得当时光是权限就改了四轮。核心问题是销售经理既要看全团队的客户又不能直接改普通销售的客户普通销售手里的客户需要可以指定给同事协作者查看但默认不能让全公司看。这个需求映射到系统里就是数据权限范围。我采用的方案是“角色 数据范围”的组合模型。系统内置五类角色超级管理员、销售总监、部门经理、普通销售、只读运营。每个角色定义一个数据范围枚举全部数据、本部门数据、仅本人数据、自定义数据。超级管理员和最顶层管理者能看到全部数据部门经理只能看本部门普通销售只能看自己负责的客户。但光有角色还不够实际业务里销售 A 需要临时把某个客户共享给销售 B 协作。我在客户表上设计了owner_id负责人、team_id所属团队和一张共享关系表。共享关系表记录客户 ID、共享给的用户 ID、共享权限只读/读写、共享截止时间。查询数据时SQL 动态拼接条件(owner_id 当前用户 OR 当前用户在共享关系表中 OR 当前用户的数据范围包含该客户所在部门)。所有的列表查询统一走这个逻辑避免每个接口自己写权限判断。这个设计里特别容易出问题的是“详情接口”和“导出功能”。列表页做权限控制还不够如果销售直接拼一个客户 ID 调详情接口就能看到别人客户的详细信息这就是越权漏洞。我在所有详情和操作接口的 service 层都加了一个校验方法先查询当前用户对该客户是否有权限无权限直接抛异常。导出功能也复用同样的权限条件否则从列表导出可能绕过前端过滤。上线前我还特意用低权限账号做了越权测试逐个接口检查这种事不能偷懒。3.4 报表与看板的统计口径先定规则再写 SQL很多 CRM 报表最终让人觉得“数据不准”根本不是 SQL 写错了而是统计口径没定义清楚。比如“成交金额”到底是合同签了就算成交还是回款到账才算如果团队里有人按签合同报业绩有人按回款报业绩报表就永远对不上。我在 DeskcommCRM 里用一张文档明确了所有核心指标口径指标统计口径成交金额以合同签订日期为准合同状态为已生效回款金额以实际到账日期为准关联回款记录商机转化率赢单商机数 / 商机总数剔除未跟进平均成交周期从商机创建到赢单日期的自然日平均值线索转化率转为客户的线索数 / 线索总数跟进次数每个客户在一定时间内的跟进记录条数报表页我分了两层个人看板和管理者看板。个人看板展示本人负责客户的商机总数、预计成交金额、本月回款、到期跟进任务管理者看板展示团队整体业绩、各销售排名、阶段漏斗、线索来源分析。这两层看板的数据统计方式相同只是过滤范围不同底层统一使用一个查询服务传入数据权限范围即可。数据存储上我没有直接在报表页面实时聚合大表。销售数据一旦有几万条商机和几十万条跟进记录实时 COUNT 和 SUM 会变慢。我的方案是每天晚上定时任务把当天的关键指标计算好写入日汇总表报表页只查汇总表。日汇总表设计成明细粒度到“销售负责人 业务对象 日期”可以灵活支撑日、周、月、季度的聚合而且不容易出现数据膨胀。实时查询的兜底逻辑只在当天数据变动需要秒级刷新时启用比如“今日新增客户数”。4. 技术架构与部署实践4.1 技术选型用成熟方案而不是追逐新技术DeskcommCRM 的技术栈没有用微服务就是经典的单体应用加分层结构Spring Boot 负责后端 APIMySQL 存业务数据Redis 做缓存和分布式锁前端用 Vue 3 Element Plus文件存储用了 MinIO。这套组合在中小团队里成熟度最高招聘也好招人运行起来稳定性有保障。为什么会选单体而不是微服务CRM 这类业务系统核心复杂度在业务逻辑和数据关系不在并发规模。几百人同时在线单体能扛得住拆成微服务反而带来服务间调用、分布式事务、链路追踪这些额外成本。等真正出现了独立的高性能模块比如售后工单系统需要大量并发再单独拆分也不晚。这个道理我在项目开始时反复跟团队强调先解决业务问题再考虑架构扩张。数据库连接池我用了 HikariCP默认配置足够支撑常规业务。Redis 主要用来缓存用户权限和登录状态也用来做客户编辑的分布式锁防止多人同时编辑一个客户导致数据覆盖。缓存策略我选择“删除缓存”而不是“更新缓存”因为 CRM 数据更新频繁更新缓存容易产生不一致删除后由下次查询重建缓存更安全。4.2 数据统计查询的性能优化系统上线三个月后客户和跟进记录量上来了列表页开始出现慢查询。最典型的是商机列表按“更新时间”倒序分页当偏移量达到几万条时查询时间直接飙到两秒以上。MySQL 的深分页问题是老熟人LIMIT offset, size需要扫描 offset 加 size 行然后丢弃 offset 行越往后越慢。我的优化方案是改成游标分页。以商机列表为例前端不再传 pageNum而是传最后一个商机的updatedTime和id或直接用唯一排序键SQL 写成WHERE updated_time ? OR (updated_time ? AND id ?) ORDER BY updated_time DESC, id DESC LIMIT 20。这样每次查询走联合索引扫描行数固定性能非常稳定。代价是失去了随意跳页的能力但对 CRM 这种以滚动加载为主的列表来说完全够用用户也很少真的需要跳到第 100 页。另一个性能问题是报表统计前面已经提过用日汇总表解决。还有一个很容易忽略的坑没有给外键字段建索引。比如商机表的customer_id如果没加索引客户详情页查询商机列表时就会全表扫。我专门做了一次索引审查把所有常用查询条件涉及到的字段和组合都建了索引。特别提醒组合索引顺序要遵循最左前缀原则比如查询高频是“负责人 状态 创建时间”就应该建(owner_id, status, create_time)联合索引。4.3 容器化部署与备份策略部署环节我一开始直接在服务器上手动安装 Java、MySQL、Redis后来升级环境才发现太痛苦于是切换成 Docker Compose 编排。整个系统分为四个容器backendJava 应用、frontendNginx 托管 Vue 静态文件、mysql、redis外加一个 minio 做文件存储。docker-compose.yml 里统一管理网络和数据卷MySQL 数据挂载到宿主机目录这样重建容器不会丢数据。构建发布我用 GitLab CI 配合 Docker Registry。代码提交到 main 分支后CI 自动执行测试、构建镜像、推送到私有仓库然后在服务器上拉取镜像并滚动更新。滚动更新时先启动新容器健康检查通过后再停止旧容器避免中断正在使用的请求。数据库表结构变更则单独走 Flyway 迁移脚本每次发版前执行完成后再启动新版本后端防止代码和表结构不匹配。备份是 CRM 系统里千万不能省的一块。MySQL 每天凌晨全量备份binlog 开启增量备份保留最近30天的备份文件同时用脚本定期同步到另一台服务器或对象存储。恢复演练我做过一次虽然繁琐但发现备份恢复流程里有不少细节没打通比如备份验证脚本没检查表数量、binlog 恢复时没有指定起始位置这些在真出事故时都要命。建议每个季度做一次恢复演练别等硬盘挂了才后悔。5. 常见问题与排查实录5.1 权限越权漏洞低权限账号看到了不该看的客户上线两周后运营同事反馈用只读账号访问某个客户详情接口竟然能看到其他部门客户的数据。我排查定位到原因列表接口已经做了数据权限过滤但详情接口只校验了登录态没有校验当前用户对这个客户是否有权限。问题出在我当时的校验逻辑只覆盖了列表查询遗漏了详情查询。修复方式是在所有涉及客户、联系人、商机的详情和操作接口里统一调用一个权限校验方法。这个方法接收当前用户和业务对象 ID先判断用户是否管理员或数据范围是否覆盖该对象再判断是否负责人或共享人。不满足条件直接抛出“无权限操作”异常。为了防止以后再犯我还加了一个全局过滤切面对所有标注了 RequiresDataPermission 注解的接口自动执行权限拦截新代码就算忘了写也会被兜底挡住。这里还有一个容易忽略的点共享表里的截止时间。共享权限如果到期了系统要自动回收。我用定时任务每小时扫描一次到期共享记录把状态改为失效。如果只在查询时判断当前时间也算一种方案但会出现共享过期后仍有缓存残留的风险定时失效更干净。5.2 并发操作两个销售同时编辑同一客户导致数据覆盖销售 A 和销售 B 同属一个部门客户通过共享关系连接到了 B。两个人同时打开同一个客户详情页A 修改了客户地址B 修改了行业分类本来应该是两条修改都保留结果后提交的 B 把 A 的改动整个覆盖了。根因是客户更新时直接按主键 UPDATE 整行记录没有做冲突检测。我先用乐观锁解决客户表增加version字段更新时SET version version 1 WHERE id ? AND version ?如果影响行数为 0说明版本已变化提示用户“该客户已被他人修改请刷新后再操作”。这个方案实现简单缺点是不够友好用户正在填的内容会被直接丢弃。后来我改成字段级合并更新前查出现有记录跟提交的数据逐字段对比只更新有变化的字段并把变更日志记录到操作日志表。这样 A 和 B 各自修改的字段都能保留。更进一步的优化是用 Redis 分布式锁同一个客户 ID 加一个锁只有拿到锁的用户才能进入编辑模式。编辑模式下前端自动保存草稿其他用户即使打开客户详情也看到“当前有同事正在编辑”的提示。这个机制对防止正式编辑冲突很有效适合对数据一致性要求比较高的团队。不过要注意锁的过期时间不能太长一般设定为 5 分钟避免用户忘记关页面导致其他同事无法操作。5.3 导出和报表慢从分钟级优化到秒级一次导出全公司客户数据到 Excel竟然跑了三分钟才出文件直接把接口超时时间打穿。排查发现导出逻辑是前端发起请求后端先查询所有符合条件的客户数据再一行行写入 Excel 文件。几万条客户加十几万条跟进记录不仅内存占用大写入还慢。优化方案分三步第一步导出改成异步任务。前端点击导出后先创建一条导出任务记录后端线程池处理完生成 Excel 文件后存到 MinIO再通过站内信通知用户下载链接。下载链接设置有效期过期后需要重新生成。第二步查询语句优化原来导出时把所有关联表 JOIN 后一次性 SELECT改成先查出主表 ID 列表再分批次取详情避免大 JOIN 造成临时表爆掉。第三步Excel 写入用流式 APIApache POI 的 SXSSFWorkbook 支持低内存写入几万条数据能稳定在一秒左右生成文件加上网络传输时间用户实际体验是十几秒就能拿到下载链接。报表慢的优化前面已经说了汇总表是关键。但这里还有一个容易踩的坑汇总表是按日生成的如果当天数据发生了变动比如销售补录了一笔昨天的回款日汇总表里昨天的数据就是错的。解决办法是汇总任务不仅定时跑还要在数据变更时触发一次“增量重算”只重算受影响的那个销售负责人加日期的汇总值。财务报表准确性的优先级高于性能不能用“大概差不多”糊弄。5.4 提醒消息重复与丢失消息队列也没能解决一切消息中心一开始直接用同步调用来写跟进记录保存成功后立刻插待办、发邮件。结果有一次邮件服务响应慢导致整个请求超时前端提示保存失败但数据库里跟进记录已经写进去了待办却没有生成。这就是典型的分布式一致性问题。后来我把消息推送改成监听 MySQL binlog 或用事务消息表的方式。具体做法是业务表更新和待办消息写入放在同一个本地事务里业务表插入记录的同时插入一条 outbox 消息消息状态是 pending。后台单独有个线程轮询 outbox 表把 pending 状态的消息发送到 Redis 队列再由消费者真正执行消息推送写站内信、发邮件发送成功后才把 outbox 状态改为 done。这样业务操作和消息生成强一致消息发送是异步的不会阻塞主流程发送失败也能重试。这套方案实现成本不高但能稳稳解决消息丢失和超时回滚的问题。如果团队已经引入了 RocketMQ 或 RabbitMQ也可以直接用 MQ 做但别忘了保障 binlog 解析的可靠性。我用的是 Spring 自带的事务同步加异步发送简单直接后续如果想扩展再引入消息队列也不晚。最后再分享一点个人体会项目从梳理需求到上线前后用了大概两个多月。最大的体会是 CRM 系统的核心不是技术而是对销售业务的理解。数据模型、状态机、权限规则每一样都映射着真实的管理逻辑技术选型反而可以保守一点Spring Boot Vue MySQL 这一套就足够支撑中小团队跑很久。如果非要说一条最值得提前做好的事那就是把权限模型设计成插件式的并且从第一行代码就开始统一执行。越权漏洞、报表数据串部门、多人协作冲突几乎都能从权限设计上找到根子。另一个小技巧是给所有关键操作都留下操作日志包括谁在什么时候改了哪个字段、从哪里改成了哪里这在后续排查问题和做审计时价值巨大。DeskcommCRM 走到这一步也只是解决了一个阶段的问题。后面如果团队规模扩大业务线变多可能还要考虑更细的销售流程编排、多币种报价、合同电子签甚至是智能化线索评分。但基础的客户管理闭环打扎实了后面再长出来的功能都不会让系统伤筋动骨。这就是我个人最满意的地方。