刚接手一个销售团队的管理时我最大的痛点不是业绩而是客户信息全在销售个人的微信聊天记录和Excel表里。交接过客户的人都知道那叫一个惨不忍睹。后来我们自己花了两周时间基于一套开源骨架改出了一套内部系统也就是DeskcommCRM——一个围绕客户生命周期管理的轻量级业务系统不重、不贵但够用打单据、管跟进、看数据都顺手。这套系统彻底解决了我们客户跟到一半就断线的老毛病。写到这我决定把当时从设计到上线的完整过程整理出来包括数据模型怎么拆、权限怎么做、为什么我建议你用Docker Compose部署以及初始化配置里特别容易踩的坑。如果你也正在为小团队的客户流转头疼或者在找一套能拿来就用的CRM方案这篇文章应该能帮你省掉不少摸索时间。1. 为什么自己攒一套CRM而不是直接买现成的1.1 被现成CRM折磨的三个月先说背景。当时我们团队十五六个人一半是销售一半是服务和研发。团队不大但业务链条挺长市场线索进来销售跟进谈成之后转给服务团队交付交付完还要跟踪续费。这种多角色协作场景市面上主流CRM都覆盖但我实际试用了三款之后一个头两个大。不是说功能不够而是功能太多了。我之前试用的一款国际大厂产品光线索状态就预设了二十几个字段什么潜在客户已联系初步意向方案提交商务谈判赢单输单还没算各种自定义状态。对大型集团来说这套模型没问题但对十五人的团队来说光让销售搞明白状态怎么流转就得培训两星期。再算上每个账号每年上千块的订阅费算下来一年几万块砸进去只是为了让销售在一个复杂系统里点鼠标。后来我们团队的产品经理一句话说到点子上了我们需要的不是管理客户的软件而是帮我们记住客户跟到哪一步的工具。理念上的差别决定了这条路走不通。1.2 立项前的三条硬指标决定自己动手之后我先整理了三条硬指标后面所有的功能设计都以这三条为中心操作成本要低销售每天花在系统上的时间最多不超过10分钟主要是记录跟进内容、更新客户阶段然后该干嘛干嘛去。数据流转要透明一个客户从进入到成交再到服务所有过程记录要在系统里可查任何一个接手的人点开客户详情就能看到完整历史。部署和运维要省心团队里没有专职运维系统必须能在一个中等配置的云服务器上跑起来出了问题一个人能搞定。围绕这三条指标我又在技术选型上做了一轮筛选。当时手里有几个选择用现成的开源CRM改、用低代码平台搭、或者完全从零写。完全从零写不现实两周时间连基础框架都搭不完低代码平台试了一下灵活度确实高但数据导出的自由度不够后续做报表分析很容易被绑死。最后定了基于开源框架二次开发的路线也就是后来DeskcommCRM的雏形。提示如果你的团队超过50人或者有较强的定制化管理需求我仍然建议购买成熟的商业CRM。自研的性价比只在业务模式简单清晰、定制需求明确、团队规模不大这三个条件下才成立。1.3 技术栈选型的取舍DeskcommCRM最终确定的技术栈是前端Vue 3 Element Plus后端Spring Boot MyBatis-Plus数据库MySQL缓存Redis部署用Docker Compose包起来。这套组合现在是中小团队做内部系统的主流方案但它能跑得顺关键在于每一层都对应一个明确的团队能力Vue 3的组件化开发让小团队可以并行开工Element Plus的表单组件在后端管理类页面里是成熟可靠的可以省掉大量UI打磨时间。Spring Boot做业务API轻车熟路团队内部的人多少都写过一点出了问题能快速定位。MyBatis-Plus的好处是CRUD操作基本不用手写SQL对赶工期的项目帮助很大。Docker Compose负责把MySQL、Redis、后端、前端全部编排在一起一条命令启动整套环境省去了环境不一致的坑。这里面我其实做过一次取舍。起初有人建议用MongoDB存客户资料理由是数据结构灵活以后加字段不用改表结构。但最终我还是选了MySQL。原因是客户数据毕竟是强关系型数据客户、联系人、跟进记录、订单之间的关联查询非常频繁MySQL在事务和联合查询上的能力更可靠。灵活性的问题我用JSON字段来补后面讲字段扩展时会详细说。2. DeskcommCRM核心模块拆解从一张客户表到完整业务闭环2.1 客户-商机-跟进-订单的四层数据模型DeskcommCRM的数据模型是我整个设计里最满意的一环。我们没有按照传统CRM那样把客户、联系人、销售机会拆成三套独立系统而是把它们串成一条业务主线客户是顶层实体存放公司名称、行业、来源渠道、客户等级这些基本属性。联系人挂在客户下面一个客户可以有多位联系人。商机代表一个正在推进的销售机会挂在客户下面包含预计金额、预计成交时间、所处阶段。跟进记录则挂在商机下面每次电话、拜访、邮件沟通都记一条。这种四层结构一开始看起来有点绕但它解决了一个很实际的问题销售查看一个客户时不需要从一个功能跳到另一个功能打开客户详情页下面的关联列表就是完整的业务全貌。订单模块相对独立但它跟商机做了强关联。商机谈成之后可以一键转订单订单金额自动回写到客户的累计成交额字段上销售个人看板里的业绩数字也从这个汇总来。这样财务报表那边导出订单数据时可以直接按时间段和销售负责人过滤不用再找系统后台写SQL。2.2 权限模型的取舍用RBAC还是数据权限权限模型是CRM系统里一个绕不开的话题也是很多人在设计初期容易低估的环节。常见的做法有两种一种是基于角色的访问控制也就是RBAC控制谁能访问哪个菜单、哪个按钮另一种是数据权限控制谁能看到哪些客户数据。DeskcommCRM两者都在用但结合的方式比较特殊RBAC管菜单和操作按钮数据权限管客户归属。每个客户创建时设置一个初始负责人默认只有负责人本人、上级主管和系统管理员能看到。数据权限的实现我一开始想过用AOP切面在做每个查询的时候自动拼SQL条件但后来为了开发和排查方便选择了在当前用户的上下文里放一个数据范围对象查询客户列表时统一走一个条件构造器。这样写业务代码的时候不会被权限逻辑打扰出问题也只需要检查一个地方。这里我特别想提醒一下不要一上来就把客户分给整个部门或整个小组可见。我的经验是先按私有为主、共享为辅来设计后续真有跨团队协作的场景再单独做客户共享功能把指定客户开放给指定团队。如果一开始就全公开大概率会有人钻空子也容易造成撞单纠纷。2.3 外部接口与遗留系统的对接思路就算是从零做系统也不可能把公司所有数据都装进去。客户资料可能散落在老Excel里产品数据在另一个仓库系统里财务走的是专有的财务软件。DeskcommCRM在设计时留了足够的集成接口。首批对接的有三个方面从旧Excel导入历史客户和跟进记录避免换系统导致客户历史丢失。对接企业微信的消息通知商机阶段变更或客户分配时自动给对应人员推提醒。从官网表单的提交接口接收市场线索进入CRM后自动分配给当班销售。对接的思路统一走REST API外面传JSON进来系统内部先做字段映射再走一个统一的消息队列处理。这么做的好处是就算外部系统的数据格式一直在变也不会直接影响到主数据库的写入逻辑。3. 部署与初始化配置我把踩过的坑都写在这里3.1 服务器规划和Docker Compose编排DeskcommCRM的部署并没有想象中复杂一台8核16G的云服务器完全跑得动整套环境高峰期同时在线五六十人压力也不大。服务器上只需要装好Docker和Docker Compose然后通过一个编排文件把后端、前端、MySQL、Redis全部拉起来。编排文件的思路是这样后端和前端各自打包成镜像用Dockerfile构建MySQL和Redis用官方镜像挂载本地数据卷持久化外面再挂一层Nginx作为统一入口处理前端静态资源再把API请求反向代理到后端容器。这里有个细节要注意MySQL容器里的时区默认是UTC而CRM的时间记录如果差8个小时跟进记录和到期提醒全乱套。我是在启动命令里通过环境变量把时区固定成了Asia/Shanghai后端应用里也统一指定了时区两边的基准对齐之后才没有继续出现时间错乱的问题。3.2 初始化配置里最容易忽略的三件事部署成功只是第一步真正决定这个系统能不能用起来的是初始化配置。我在这块踩过不少坑挑最典型的三个说一下。第一件事是管理员首次登录后的账号体系初始化。系统默认的管理员账号密码一定要第一时间改掉并且强制要求填写手机号和邮箱方便做密码找回。这个如果不做等系统用起来之后管理员的手机号还是演示环境里的那个后面团队扩大再改就很麻烦。第二件事是客户编号规则。客户列表里每一个客户都有唯一的客户编号默认策略是日期自增数字比如CRM20250601001。这个策略尽量在导入历史数据前定好不然导入之后编号重复或格式混乱再改就要动数据库了。第三件事是字典项配置。客户来源、行业类型、跟进方式、商机阶段这些看起来不起眼的下拉选项其实是整个系统业务逻辑的底层支撑。我建议一次性把所有可能用得上的字典项都维护好宁可比现在需要的多一些也不要后期频繁去后台加选项因为已存在的数据不会自动关联新加入的选项。3.3 备份策略的落地备份这个事我发现很多自建系统都没有认真对待都是系统跑挂了才想起来。DeskcommCRM上线当天我就把备份机制接通了靠的是Linux的crontab定时任务加mysqldump命令每天凌晨两点对MySQL做全量备份保留最近七天。有人可能觉得全量备份占空间但对DeskcommCRM这个体量来说数据库撑死也就几个GB全量备份完全不是问题关键是恢复简单——直接一条mysql命令导入就能用。更复杂的增量备份和binlog备份对内部系统来说有点过重了真到了需要那种防护等级的阶段大概率早就该换商业方案了。另外提一句备份文件不能存在同一台服务器上。我一开始备份到本机磁盘后来一次磁盘满的事故让我差点翻车从那以后备份目录改成了挂载到对象存储的路径每天自动同步一次双保险在手才睡得踏实。4. 二开实录字段扩展、审批流与批量导入4.1 自定义字段设计时留好JSON扩展位CRM系统里一个永远避不开的需求就是加个字段。销售今天说要加一个客户预算范围明天服务团队说要加一个交付周期如果每次都改表结构加列数据库很快就变得臃肿而且改表有风险万一线上数据量大了一个ALTER TABLE可能把数据库锁半天。DeskcommCRM的解决方案是在客户表、商机表、订单表三张核心表上都加了一个名为extra_info的JSON字段用来存放各团队自定义的属性。需要加字段时后台管理页里配置一下字段名称、字段类型、是否必填前台表单就会自动多出一个输入组件数据统一写进JSON里。JSON字段的代价是没法直接用普通的WHERE条件做范围查询不过在内部管理场景下针对这个字段的筛选需求基本都能落到标签这种方式来做相关需求量和复杂度都在可控范围内。4.2 审批流的实现一张状态机表CRM里面有一套普遍需要的审批场景折扣审批、订单审核、客户转交、合同归档都需要走提交-审批-通过/驳回的流程。一开始我想引入现成的工作流引擎但评估下来觉得对这套轻量系统来说太重了。DeskcommCRM最终用一个状态机表解决了这个问题。核心设计是process_instance表记录一条审批实例的类型、发起人、当前状态、关联业务IDprocess_log表记录每一步操作的时间、操作人、动作和意见。业务上需要审批时系统自动创建一条审批实例并且把业务单据的状态改成待审批审批通过后再回写主表状态。状态流转的核心逻辑其实就是一段链式的if-else判断每一种业务类型对应一套合法的状态转换路径。它不够通用但足够直接新加一种审批类型只需要在配置类里加一条规则不用去理解复杂的工作流概念。4.3 批量导入的十万行数据踩坑系统刚上线的时候要把散落在各个Excel表里的历史客户数据导入进去。我们摸了一下家底大概有十万行客户加跟进记录数量不算多但踩了一个大坑。第一次我直接用后端API一条一条插入结果跑了十分钟还没跑完观察了一下发现是每条插入都走了一次完整的MyBatis插入加索引更新效率极低而且中途一旦网络抖动还会中断没有任何断点续传机制。后来我改成批量插入的方式用MyBatis-Plus的saveBatch方法每次提交五百条同时在插入前先对重复手机号做去重速度从几十秒降到了两三秒一天就把全部历史数据导入完了。另外批量导入请一定要在测试环境先跑一遍把字段映射关系确认好。我第一次导入时把Excel里的最后跟进时间列读成了字符串写入数据库后日期全变成了0000-00-00后面排查了很久。这类数据清洗的问题在生产环境里排查的代价比测试环境大一倍不止。5. 运营三个月后的真实反馈与调优清单5.1 销售真正在用的是哪几个功能系统上线三个月后我拉过后台的使用统计发现一个有意思的现象功能菜单有四十多个但销售日常高频使用的功能只有四个——今日待办、客户列表、跟进记录、商机看板。像合同管理、产品库这些模块使用频率低得几乎可以忽略。这个结果倒不是说明这些模块没必要做而是说明对于一线销售来说CRM的核心价值就是两件事一是让我知道今天要干嘛二是让我快速地记下刚刚沟通了什么。今日待办里聚合了今日待跟进的客户和即将到期的商机销售每天早上一打开系统看到待办列表就可以开始工作了这比再华丽的仪表盘都管用。另外移动端的使用比例比我想象的高得多。很多销售白天在外跑客户回到电脑前根本不想打开系统都是在手机上通过企业微信里的H5入口快速记一条跟进记录。所以如果你们团队有移动办公需求H5版本的适配优先级建议放高一点。5.2 性能调优索引、缓存与慢查询DeskcommCRM在一开始并没有性能问题毕竟数据量就那么大。但随着历史数据导入完毕系统开始卡顿第一个症状是客户列表打开要三秒多有时候甚至超时。排查链路是这样的先在MySQL里开了慢查询日志发现主要瓶颈是一条对跟进记录表的COUNT聚合查询每次打开客户列表都要统计这个客户的跟进次数。数据量到七万条之后这个查询开始变慢因为用在WHERE条件的字段没有走索引。解决方法有两个在跟进记录表的customer_id和deleted字段上建立了联合索引查询时间从接近一秒降到了几十毫秒。客户列表页的跟进次数列改成懒加载模式只有展开客户详情时才去实时查询列表页只展示客户基础字段。查询逻辑没变但响应速度的变化是天壤之别。第二个优化是Redis缓存的使用。客户的字典项、销售团队的组织架构这类不经常变化的基础数据在首次读取后直接放进Redis设置十分钟过期时间数据库的压力明显小了很多。5.3 后续迭代方向系统稳定运行三个月后团队提了不少新需求其中有三个方向我比较认可也计划放到后续迭代里。一是增加客户风险预警。如果一个高等级客户连续三十天没有跟进记录系统自动推送给主管。这对防止客户流失有实际价值。二是增加销售漏斗分析。通过商机阶段的历史流转数据分析每个阶段的转化率和平均停留时间帮助管理者发现销售卡在哪个环节。三是订阅消息的外部触达。客户如果长时间没有互动可以自动给客户发送一条微信模板消息提醒近期有优惠活动等于把CRM从管理工具升级成营销工具。这些方向现在还在规划阶段。老实说做内部系统最大的好处就是可以快速试错不需要走复杂的评审流程觉得有价值就开发一版上了线看数据说话。DeskcommCRM的价值不在于它用到了多前沿的技术而在于它跟团队的日常工作流程长在了一起这个才是它能存活下来的根本原因。我自己在跑这套系统的过程中最大的体会是小团队做内部工具先解决最痛的点把基础数据管好比什么都重要。不要一开始就追求大而全不然最后很可能得到一个谁都不想用的完美系统。另外无论用什么技术栈备份和数据安全一定不能省系统可以坏数据不能丢这是我这两年踩过最深的坑之后得出的结论。