1. 项目复盘：为什么业务团队总抱怨“客户跟着销售跑了”
做DeskcommCRM这个项目之前，我在一家成长型公司负责业务系统的技术选型和落地。当时的现状是：销售手里攒着一堆微信好友和Excel表格，客户信息全凭个人记忆；管理层想统计线索转化率，只能靠销售周报里自己填的数字；售后和销售各自为战，同一个客户被重复跟进，报价口径还不一致。这种状态撑到第50个销售时基本就失控了。
所以我立项做DeskcommCRM，目标非常明确：把客户资产从个人手里收归企业，把跟进过程从口头汇报变成结构化记录，把管理决策从凭感觉变成看数据。它不是一个追求大而全的通用CRM，而是围绕“线索—商机—合同—回款—售后”这条主业务线，做深做透的销售管理工具。
这篇文章适合谁看？如果你正打算自研CRM、选型CRM系统，或者已经上了CRM但用不起来，想把系统真正落到业务里，那这篇复盘应该能给你不少参考。我会把DeskcommCRM从需求梳理、架构设计、模块实现到上线推广的完整过程拆开讲，包括踩过的坑和最后沉淀下来的经验。
2. 需求梳理与方案选型：先搞明白你要解决谁的问题
2.1 走访销售、管理、售后后形成的核心需求清单
做CRM最忌讳的就是产品经理坐在办公室里凭空画原型。我一开始花了整整两周时间，访谈了三类角色：一线销售、销售主管、售后客服，外加财务和运营负责人。每一轮访谈都带着同一个问题：“你每天最烦的事情是什么？”。
访谈下来，痛点高度集中在四个方面：
- 销售烦的是：手动录入信息太麻烦，客户跟进记录经常忘填，换手机或离职时客户资料丢失。
- 销售主管烦的是：无法实时掌握团队项目进度，不知道哪些商机快要丢单，只能靠开会一个个问。
- 售后烦的是：客户历史信息太分散，接手时要从聊天记录、邮件、表格里翻旧账。
- 管理层烦的是：数据口径不统一，周报月报人工统计慢，转化率、回款周期这些指标完全没有沉淀。
基于这些反馈，我把DeskcommCRM的一期需求收敛成五个核心模块：线索管理、客户管理、商机与跟进、合同回款、数据看板。同时定下三条设计原则：录入要轻、查询要快、数据要实。这三条原则贯穿了后续所有的功能和交互设计。
2.2 自研还是买现成：为什么最后我自己攒了一套
当时市面上不是没有现成的CRM，Salesforce、纷享销客、销售易这些都是成熟产品。我为什么没有直接选一家采购，而是自研了DeskcommCRM？原因有三个。
第一，定制成本。公司的业务流程非常个性化：报价单要按客户等级走不同的审批流，回款要跟项目验收节点绑定，现有竞品在这些细节上要么做不了，要么需要高价定制。第二，数据打通。DeskcommCRM需要和企业内部的ERP、OA、企业微信做深度集成，业务字段和权限模型都要跟着内部管理规范走，SaaS产品很难完全适配。第三，成本账。按当时的坐席数和定制需求，三年订阅费加实施费，足够支撑自研团队的大部分成本了，而且自研的资产是沉淀在自己手里的。
当然，自研也意味着你放弃了成熟的权限体系、稳定的运维保障和持续的版本迭代。这个风险我是掂量过的。我的建议是：如果你公司人数少于30人、业务流程简单且短期不会大变，直接买现成SaaS更划算；但如果你的公司到了需要“系统适配业务”而不是“业务迁就系统”的阶段，自研的长期收益会更大。
工具选型上，没有使用太重的东西。后端一水的Java Spring Boot，前端Vue，数据库MySQL加Redis，部署在腾讯云上一台8核16G的服务器。为什么选这套组合？团队熟悉度是第一位的，项目不等人，没人愿意学一门新语言来做一个管理系统。MySQL在这个数据量级下完全够用，Redis只用来做登录会话和验证码缓存，没有引入一堆中间件，尽量降低运维成本。
3. 核心模块设计与实操细节：每一块都不简单
3.1 客户数据模型：你的字段设计决定了系统的上限
客户表是DeskcommCRM的核心，字段设计我前后改了三版，第一版太简单，只有公司名、联系人、电话，结果根本支撑不了后续的分类统计；第二版又搞了30多个字段，销售录入时直接骂娘。最后落地的版本把字段分成四组：基础信息、工商信息、跟进状态、自定义扩展。
基础信息就是客户名称、所属行业、规模、来源渠道这些常规字段。工商信息通过接口自动填充，包括统一社会信用代码、注册地址、经营范围，这样销售不需要手动敲键盘。跟进状态是一个关键设计，把客户分成“新客户、跟进中、已签约、已流失、暂不合作”五个状态，每个状态都有对应的颜色和操作按钮，视觉上一眼能看出客户处于哪个阶段。自定义扩展用JSON字段存储，满足不同业务线的个性化需求，比如电商部要填店铺链接、渠道部要填代理等级，这样就不用频繁改表结构了。
这里我要强调一个关于唯一性的细节。客户表的唯一键我没有用自增ID，而是用了客户名称加统一社会信用代码的组合唯一索引。为什么？因为系统要和企业微信的外部联系人做匹配，客户名称一样但其实是两家公司的情况很常见，不加这个唯一索引，数据重复率会迅速飙升，后面再做数据清洗就非常痛苦。
还有一个设计是客户归属人字段。客户创建后默认归属创建者，但支持转移；转移时如果客户名下有未关闭的商机，需要主管权限才能操作。这个限制很关键，否则销售离职后客户被随意转走，扯皮纠纷能影响整个团队的信任度。
3.2 跟进记录与动态时间线：让协作有迹可循
跟进记录是CRM使用频率最高的功能，但也是销售最不爱录的功能。很多CRM的死法就是倒在录入成本上——要求销售每天写一篇小作文式的跟进记录，结果没坚持两周就谁也不写了。DeskcommCRM的做法是把跟进记录模板化、选项化，降低表达成本。
跟进方式的类型包括电话、微信、上门拜访、邮件、线下会议，每种方式都有对应的快速标签。比如电话跟进，可以勾选“已接通、未接通、约了下次时间、客户意向明确”；上门拜访则还能定位打卡并上传现场照片。销售只需要点几次屏幕就能形成一条有效记录，而不是逐字敲键盘。时间线的聚合逻辑是按客户聚合全部关联跟进记录、订单状态变化、合同到期提醒，按时间倒序排列，所有有权限的人都能看到，彻底解决了“这个客户之前聊到哪了”的信息断点问题。
同时我设置了“跟进强制提醒”规则。如果一个客户超过7天没有新纪录，系统自动给负责销售发一条企业微信提醒；连续14天无跟进，提醒会升级到销售主管。这个机制上线初期被一片骂声，说公司监控太严。但运行两个月后，团队自己发现很多原本快死的商机又被重新激活了，流失预警的作用慢慢被接受，销售主管也开始主动利用这个规则做团队管理。
3.3 商机阶段管理与销售漏斗：别追求好看，要追求真实
商机模块我参考了经典的Pipeline管理思想，把商机过程拆成“初步接洽—需求确认—方案报价—商务谈判—赢单/输单”五个阶段。每个阶段都定义了可验证的进入条件和退出条件。比如“初步接洽”到“需求确认”的条件，是销售必须上传客户签字的《需求调研表》；从“需求确认”到“方案报价”的条件，是至少有三个字段被填写完整：预算规模、决策链条、交付时间。
这套条件的价值在于，销售不能随手把一个只聊过两句的客户拖进“商务谈判”阶段，系统会拒绝操作并提示缺什么资料。一开始销售觉得繁琐，觉得是在“逼自己做作业”。但实际跑通一个季度后，管理层对销售漏斗的预测准确率大幅提升，主管能过滤掉大量虚假乐观的单子，决策节奏也更快了。
漏斗报表的数据口径必须严格统一：阶段按商机当前所在阶段统计，金额按商机的“预计成交金额”字段求和，赢单率用历史赢单数除以同期商机总数。这个口径我在指标配置文档里写死了，不然不同部门看周报时各说各话，会吵到产品经理怀疑人生。
3.4 权限模型：一套RBAC加数据范围的双层控制
权限设计是CRM里最容易出安全事故的模块，千万不能大意。DeskcommCRM的权限体系分两层：第一层是功能权限，用RBAC模型，角色划分为超级管理员、销售主管、普通销售、售后、财务、运营，每个角色能看到的菜单和能执行的操作都不同。第二层是数据权限，这个更重要，控制的是“你能看到哪些客户的数据”。
我把数据范围分为五种：仅本人、本部门、本部门及下属部门、全部数据、自定义（按指定成员或指定标签）。普通销售默认仅本人；主管默认本部门及下属部门；财务和运营默认全部数据。这个模型解决了一个核心问题：销售之间不能互相看到对方客户，杜绝撬单；高层能看全部数据，方便全局决策；财务和售后看到的是脱敏后的客户信息，手机号中间四位打码，但导出时会对操作行为留痕。
这个双层权限的代码实现上用AOP切面做数据权限过滤，在查询客户列表的SQL里动态拼接数据范围条件，避免业务代码里到处写权限判断逻辑。同时我在日志里记录了所有导出操作，后来有一次客户信息疑似泄露时能快速定位到责任人，这个功能算是意外之喜。
4. 实操过程与核心环节实现：从编码到上线的完整记录
4.1 环境准备与搭建步骤
DeskcommCRM的开发环境比较简单，我列出具体的搭建过程供参考。后端使用JDK 1.8 + Maven 3.6，前端是Node.js 14加上Vue CLI 4。数据库用MySQL 8.0，字符集统一utf8mb4，为了避免中文乱码和emoji存储问题，这个细节我特意标注了。
服务端框架的核心依赖包括：Spring Boot 2.5、MyBatis-Plus 3.4、Sa-Token做权限认证、Hutool做工具集。前端是纯Vue 2 + Element UI，因为团队最熟这套组合，没有引入太新潮的技术栈。
部署时我用了Docker Compose编排，一个Nginx容器做反向代理和前端静态资源服务，一个Java应用容器，一个MySQL容器，一个Redis容器。服务器配置是2核4G起步，实际上线约40人使用时资源占用大概在30%，后面如果加到100人可以考虑升配。
关键的启动顺序要注意：先启动MySQL和Redis，等数据库初始化完成后再启动Java应用，否则应用启动时会报连接超时。刚开始上线时我图省事把所有容器一句docker-compose up全拉起来，结果Java启动比MySQL快，数据库连接池初始化失败，整个系统反复重启，折腾了半天才发现是这个顺序问题。
4.2 一个关键流程的完整实现：客户导入去重
导入功能是所有CRM的刚需，因为销售手里存了大量Excel客户资料，如果让他们一条条手动录入，项目上线第一天就会被喷走。但导入功能做好了也不难，真正难的是“去重”。我以客户批量导入为例，展示一下完整的处理逻辑。
第一步是模板解析。用户下载系统提供的Excel模板，按字段填写后上传。后端用EasyExcel解析，校验每一行的必填项和格式。第二步是去重判断。这一行客户的公司名如果和库里的客户名称完全一致，或统一社会信用代码一致，就标记为“重复”；如果相似度较高，比如“北京字节跳动科技有限公司”和“字节跳动有限公司”，用字符串相似度算法算出来高于阈值，就标记为“疑似重复”，需要人工确认。第三步是结果反馈。系统生成一张导入结果表，标注每一行是“成功、失败、重复跳过、疑似需要确认”。用户下载结果表后可以修正再重新提交。
这个功能上线后，第一次导入5000行历史客户数据，去重识别出327条重复记录，几十条疑似重复。如果没有这层处理，光是数据清洗就够忙活一周。经验就是：功能不能只做“导入成功”，必须把导入中出现的所有情况反馈给用户，让人能闭环处理，这才是能用的导入。
4.3 数据看板实现：几个核心指标的计算逻辑
看板是整个系统给管理层用的核心模块。一开始我只做了几张图表，后被管理层嫌弃“看了一堆数字不知道下一步干什么”。后来我明确了看板必须回答三件事：整体业绩情况怎么样、哪些环节在漏客户、团队里谁最需要帮助。
指标计算逻辑上，有几个值得说的点：
- 线索转客户率：某段时间内新增客户数除以新增线索数。这里的口径是线索转成客户必须满足“完成首次有效跟进”这个条件，而不是只要创建了客户就算。
- 商机赢单率：赢单商机数除以关闭的商机总数（赢单+输单）。这个指标我特意排除了“未关闭”和“跟进中”的商机，否则算出来的比例虚高，没有参考意义。
- 平均成交周期：从商机创建到赢单的时间差，取近30天赢单商机的平均值。这个指标能帮助企业判断整体销售节奏。
- 回款及时率：实际回款日期在合同约定日期之内的订单占比。这个指标对接财务的口径，是后期对接ERP时加上去的。
看板展示上做了一个趋势折线图和漏斗图，按周刷新。数据不实时，但业务上足够了，因为销售漏斗本身就不是一个实时变化的东西，按小时刷新反而制造焦虑。
5. 上线推广与常见问题排查：真实环境里的血泪经验
5.1 上线后最容易出的三类问题及排查思路
系统上线第一个月，问题集中在三类：登录态丢失、数据查询慢、导出乱码。
登录态丢失的原因最初排查了很久。现象是用户访问一段时间后页面就跳回登录页，日志里发现是Sa-Token的Token有效期设置得太短，只有30分钟，而销售写一条跟进记录可能要十几分钟，写完后Token过期了，一保存就掉线。解决方法是把Token有效期调到12小时，并加上“最后活跃时间”续期逻辑，用户只要在操作，就一直续期，连续2小时不操作才强制重新登录。
数据查询慢主要是客户列表页在跨表关联的时候用了太多子查询，尤其是有数据权限过滤条件时，SQL执行计划走了全表扫描。我在排查时用explain命令检查执行计划，发现联合索引没有建好，后来给客户表的归属人、更新时间、状态三个字段建了联合索引，查询速度从原来的2秒以上降到了100毫秒以内。这条经验提醒我，后面所有列表页开发之前必须先根据查询条件设计索引，不要等线上慢了再补救。
导出乱码的经典问题。Excel导出时如果文件头没有加BOM，用Excel打开中文就会乱成一团。解决办法是在导出文件流开头写三个字节的UTF-8 BOM标记，这么简单的问题当时却折腾了好几个小时。
5.2 数据质量维护：一次彻底的“数据洗澡”
系统上线两星期后，我通过一次全量数据扫描发现，客户表里出现了大量脏数据：联系电话写成了备注文字、公司名为空、建档日期异常。这些问题大多来自导入阶段。我组织了一次专门的数据清洗行动。
清洗规则包括：电话字段只保留11位数字，多余字符删除；公司名不能为空，空值则用联系人邮箱前缀补全；统一社会信用代码为空并不影响建档，但会标记为“待完善客户”；更新时间超过90天且状态为“跟进中”的客户，自动流转到“已流失”状态。
这套规则跑完，数据质量有了明显改观。更重要的是，我写了一个每天凌晨执行的定时任务，自动扫描数据质量指标并推送报告给运维群。从那以后，脏数据再也没有大面积爆发过。数据质量维护是一个持续动作，不是你上线时清洗一次就完事儿的。
5.3 推广落地与用户习惯培养
系统做完了没人用，是自研项目最尴尬的结局。为了不让DeskcommCRM变成摆设，我在推广上做了一些“小心机”。
第一是把系统和企业微信深度绑定。审批通知、跟进提醒、日报提醒全部推送到企业微信，销售不用记着去登录网页，光靠聊天框里的卡片提醒就能完成任务。这样一来系统的触达频率高了很多。第二是制定了一个“退出机制”：任何新客户创建后，如果两周内没有录入有效跟进记录，系统自动把负责人标记为“闲置客户”，主管可重新分配。这个机制让销售不敢把客户占着不分，也倒逼他们养成了及时录入的习惯。第三是建立了一个奖励规则，每个月数据录入完整度最高的销售会获得一个公开表扬，表面上是荣誉激励，实际是让全公司意识到，系统里的数据是有价值的。
三个月后，系统的周活率稳定在85%以上，一线销售每天平均录入跟进记录1.8条，管理层看板的使用频率远远超过预期。这个成绩说明，CRM成功的因素里，产品设计占四成，推广运营占六成。
6. 一段值得写下来的体会
DeskcommCRM从立项到稳定运行，前后大约半年时间。如果让我总结这个项目最大的收获，不是学会了多少技术，而是我深刻理解了一个道理：一个看起来“只是管理系统”的CRM，本质上是公司管理理念的数字化投射。系统设计成什么样，公司就会慢慢长成什么样。你设计为“方便老板看数据”，团队就会应付数据；你设计为“帮助销售赢单”，团队才会把系统当成自己的武器。
所以如果你正在做类似的系统，我建议你的角色定位别只是“产品经理”或“程序员”，而是“业务流程顾问”。多花时间跟业务同事泡在一起，听他们吐槽，看他们干活，在细节里发现真实需求的微光。那些能落地的CRM，一定不是技术最炫的，而是最能理解用户的。
最后再分享一个小技巧：搭建任何业务系统，先别急着写代码，花三天时间把关键用户访谈清楚，画出简单的流程图和字段清单，拿纸面原型去让用户确认。这个习惯帮我避开了至少一半的返工，也让我在所有同事眼里留下了“这个开发靠谱”的印象。做系统就是做人，信任感建立了，后面什么需求都好谈。
