自研CRM系统从0到1实战复盘：客户管理、销售流程与权限设计全解析

1. 项目复盘为什么业务团队总抱怨“客户跟着销售跑了”做DeskcommCRM这个项目之前我在一家成长型公司负责业务系统的技术选型和落地。当时的现状是销售手里攒着一堆微信好友和Excel表格客户信息全凭个人记忆管理层想统计线索转化率只能靠销售周报里自己填的数字售后和销售各自为战同一个客户被重复跟进报价口径还不一致。这种状态撑到第50个销售时基本就失控了。所以我立项做DeskcommCRM目标非常明确把客户资产从个人手里收归企业把跟进过程从口头汇报变成结构化记录把管理决策从凭感觉变成看数据。它不是一个追求大而全的通用CRM而是围绕“线索—商机—合同—回款—售后”这条主业务线做深做透的销售管理工具。这篇文章适合谁看如果你正打算自研CRM、选型CRM系统或者已经上了CRM但用不起来想把系统真正落到业务里那这篇复盘应该能给你不少参考。我会把DeskcommCRM从需求梳理、架构设计、模块实现到上线推广的完整过程拆开讲包括踩过的坑和最后沉淀下来的经验。2. 需求梳理与方案选型先搞明白你要解决谁的问题2.1 走访销售、管理、售后后形成的核心需求清单做CRM最忌讳的就是产品经理坐在办公室里凭空画原型。我一开始花了整整两周时间访谈了三类角色一线销售、销售主管、售后客服外加财务和运营负责人。每一轮访谈都带着同一个问题“你每天最烦的事情是什么”。访谈下来痛点高度集中在四个方面销售烦的是手动录入信息太麻烦客户跟进记录经常忘填换手机或离职时客户资料丢失。销售主管烦的是无法实时掌握团队项目进度不知道哪些商机快要丢单只能靠开会一个个问。售后烦的是客户历史信息太分散接手时要从聊天记录、邮件、表格里翻旧账。管理层烦的是数据口径不统一周报月报人工统计慢转化率、回款周期这些指标完全没有沉淀。基于这些反馈我把DeskcommCRM的一期需求收敛成五个核心模块线索管理、客户管理、商机与跟进、合同回款、数据看板。同时定下三条设计原则录入要轻、查询要快、数据要实。这三条原则贯穿了后续所有的功能和交互设计。2.2 自研还是买现成为什么最后我自己攒了一套当时市面上不是没有现成的CRMSalesforce、纷享销客、销售易这些都是成熟产品。我为什么没有直接选一家采购而是自研了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一定不是技术最炫的而是最能理解用户的。最后再分享一个小技巧搭建任何业务系统先别急着写代码花三天时间把关键用户访谈清楚画出简单的流程图和字段清单拿纸面原型去让用户确认。这个习惯帮我避开了至少一半的返工也让我在所有同事眼里留下了“这个开发靠谱”的印象。做系统就是做人信任感建立了后面什么需求都好谈。