DeskcommCRM这个项目是我在上一家公司从0到1主导建设的一套企业客户关系管理系统。项目名是内部起名阶段定的Desk代表工位comm是communication的缩写合在一起就是想表达“坐在工位上就能把客户沟通和业务推进全部管起来”。现在回头看这个名字恰好概括了这套系统的核心价值把散落在Excel、聊天记录、个人笔记本里的客户信息收拢到一套统一的流程里让销售、客服、管理者看到同一份数据减少撞单、丢单、跟不动的混乱。这套系统上线后覆盖了销售、售前、客服、运营四个部门核心解决了三个问题客户信息散落、跟进过程不透明、管理报表靠人工拼。这篇文章主要写给两类人看一类是正在考虑自建CRM或者做CRM选型的朋友另一类是刚接手CRM项目实施、想提前避坑的产品或技术人员。我会把需求调研、架构设计、数据模型、核心功能落地、数据迁移、真实问题排查整个链路都过一遍里面很多细节是常规文档不会写的全是从项目现场踩出来的经验。1. 立项背景与需求调研先把“为什么做”想清楚1.1 旧方式碰到的问题Excel和聊天记录撑不起客户管理当时公司销售团队不到30人用的工具是Excel加聊天软件。每个人维护一张客户表字段自己加格式每隔几个月就乱一次。管理层要看销售数据就让助理把所有表格收集起来合并合完以后字段对不上、客户名重复、金额口径不统一经常为了一个数字来回确认半天。这还只是数据层面的问题。更麻烦的是客户归属。有客户在A销售的表格里实际上却是B销售在跟进撞单以后只能靠聊天记录判断谁先联系效率低也伤团队感情。我当时访谈了一位干了七八年的销售主管他说的一句话我印象很深“客户放在Excel里其实就是放进自己口袋里公司根本不知道这个客户到底在谁手里。”后来公司又扩了客服和售后团队客户进来以后没人接、售后问题找不到历史记录事情越滚越大管理层才下定决心自己建一套CRM而不是直接用现成的SaaS。这里有个很现实的原因也要说一下市面上成熟的CRM产品功能很强但我们公司的业务链条比较特殊需要和内部的工单系统、企业微信消息记录做深度打通而且涉及大量历史客户数据的清洗和迁移现成产品改造成本并不低。综合评估之后自建反而成了当时最合理的选择。1.2 需求访谈的几个关键输入项目立项以后我第一件事不是画原型而是把五类人拉在一起做访谈销售、售前、客服、运营、财务。销售关心的是录入方不方便、客户好不好找、成交以后提成数据是不是清清楚楚客服关心的是客户进来以后历史记录能不能自动带上管理层关心的是线索有没有被跟进、商机到了哪个阶段、本月预测回款大概多少财务关心的是合同、回款、开票这些数据能不能和客户档案串起来。这个阶段有一个很重要的心得需求访谈不要只问“你要什么功能”更关键的是问“你现在哪里最痛”。销售不会说“我要一个公海池规则”他只会说“有个客户跟了一个月结果被同事拿走了领导还判定是同事的”。公海池、防撞单、归属保护这些功能都是听完痛点以后转换出来的需求。你先让他吐槽再从吐槽里提炼规则比直接拿一份功能清单去确认有效得多。1.3 两类需求的取舍销售要“快”管理要“严”访谈做完以后需求明显分成两派。销售要的是快打开页面就能录入最好填两三个字段就能建一个客户管理层要的是严要看到每一个节点的数据甚至想限制销售删客户的权限。这两类需求天然矛盾处理不好就会变成“系统太繁琐大家不想用”或者“系统太松散管理层不放心”。我的处理思路是提交流程尽量短审批和限制单独放。客户基础信息只需要公司名、手机号、来源三个字段就能提交剩下的信息允许后补。删除操作全部收紧物理删除只保留在管理员和回收站两个出口。这样录入的人不烦管理者也放心。还有一个细节新建客户的时候手机号和公司名并不是必填二选一而是要求至少填一个。因为有些ToB业务拿到的就是一个公司名有些ToC场景只有手机号要求太死就把数据挡在门外了。2. 整体架构与模块设计上线前把图纸画好2.1 模块划分客户、商机、工单、报表各管各的DeskcommCRM的功能模块我最终拆成了六块客户管理、线索管理、商机管理、工单售后、统计报表、系统管理。这个划分看起来常规但里面有一个容易踩坑的地方就是线索和客户的区别。线索和客户在CRM里经常被搞混我在这套系统里做了一个明确区分线索是没有经过确认的原始信息可能是展会拿到的名片、官网留资、市场活动导入的名单客户是已经确认过身份、至少有一条有效联系方式的组织或个人。线索可以一键转客户转过去以后同步创建第一条跟进记录。这种区分避免了一个经典问题数据一进来就进客户池占据名额结果公海池里全是没验证过的新线索销售懒得领领了也打不通整个池子就废了。商机则挂在客户下面一个客户可以同时有多个商机。商机有阶段、预计金额、预计成交日期、赢单率这几个关键字段。平时大家嘴里说的“这个客户快成了”在系统里就体现为商机阶段到了谈判阶段赢单率更新到80%。如果没有商机这个独立实体所有成交预测就只能拍脑袋。2.2 技术选型考虑团队能维护比技术新鲜更重要技术选型的核心原则不是追求新而是团队能长期维护。我们团队当时Spring Boot和Vue用得最熟数据库是MySQL缓存用Redis消息中间件用RabbitMQ定时任务用xxl-job。这套组合没有什么炫技的地方但招人、维护、排错都容易对中小规模CRM系统来说完全够用。选型时有一个细节我记得特别清楚权限模型没有用现成框架里自带的简单角色控制而是自己实现了基于角色的访问控制加数据范围控制。因为CRM的权限核心不在于“谁能点这个按钮”而在于“谁能看哪些客户”。如果这一步偷懒后面客户池、离职继承、跨部门共享全都做不干净。权限这种底层设计后期改造成本极高宁可在前期多花一周设计也不要在上线后花一个月返工。2.3 数据模型的核心一张客户主表带来的连锁设计核心业务表我列了六张客户主表、联系人表、跟进记录表、商机表、订单表、行为日志表。客户主表是几乎所有业务的入口所以字段设计要足够稳定后续加字段容易但改字段语义会牵扯很多地方。这里分享一个真实踩过的坑客户表中的归属人字段一开始只存了用户ID后面做离职继承时发现历史数据里有一批客户的归属人已经离职需要批量改成其他员工。如果只存用户ID离职后用户档案一旦禁用列表页就会出现一堆“未知用户”非常难看。后来我们把归属人的姓名冗余了一列虽然这不符合严格的范式设计但查询和展示的效率高很多也省掉了频繁联表。CRM这类业务系统适当冗余是值得的不用死守教科书。3. 核心功能落地客户池、去重、权限和漏斗的权衡3.1 客户公海池的分配与回收规则客户公海池是我认为整个系统里最需要业务规则支撑的功能。它解决两个问题一是没有跟进的客户白白占用资源二是跟不动的客户被一直攥在手里不放。规则设计上新客户默认进入公海池销售可以领取领取上限根据部门设置比如一线销售50个超过上限必须先释放已经有30天未跟进的客户。每次跟进会刷新“最近跟进时间”如果连续超过15天没有跟进记录系统自动把一个私海客户回收到公海池回收前三天提醒员工。这个逻辑听起来不复杂真正落地时有一个坎回收天数不能一刀切。大客户项目的销售周期动辄半年让一个做项目型销售的同事15天不联系客户就回收他会直接炸毛。后来我们把规则做成了可配置不同产品线不一样快消品线15天大客户项目线60天。回收前的提醒方式也可以选可以通知本人也可以同时通知直线主管。这样规则才是活的而不是系统强加给业务的铁律。3.2 重复客户识别把“容错”也写了进去重复客户是最伤害销售信任的功能点。销售最不能忍的是自己跟进很久的客户系统里显示另一个同事已经在跟了而且之前的历史记录自己完全看不到。所以去重必须做但做法有讲究。我设计了三个层次的去重策略。第一层是强校验企业客户的统一社会信用代码、个人客户的手机号在创建时直接做唯一校验重复就不让保存。第二层是模糊识别公司名称去掉“有限公司”“股份”“上海”这类词以后做精确匹配匹配到了就弹一个提示让用户自己判断。第三层是后台定期任务每周跑一遍比对把可能重复的客户挑出来由运营人员人工合并。这里有一个特别容易被忽略的细节手机号格式。一开始以为唯一校验最简单结果发现录入的数据五花八门有人写138-1234-5678有人写86 13812345678还有人写13812345678后面带个空格。如果不先做手机号归一化处理去重就是空的。我们的做法是保存之前统一清洗手机号只保留数字部分加了86和横线全部去掉身份证、信用代码也做类似处理。这些基础容错不做后面所有规则都不可靠。3.3 数据权限一套规则解决“谁看见谁”数据权限做了“数据范围”字段包括仅本人、本部门、全部数据、自定义指定部门四种。每个角色配置好范围以后查询时在SQL层自动追加过滤条件不是在应用层一边一边地判断。这样做的原因是性能可控而且不容易漏掉某个查询入口。这一块最容易出错的地方在部门树。部门要支持多级选择“本部门”时还要决定是否包含子部门。我的建议是默认包含不然子公司的人看不到子部门客户业务上会混乱。另外有一个统一原则必须守住导出的数据权限必须和列表查看权限一致。很多系统列表页只能看本人导出却能导全公司这个问题一旦被销售发现整个权限体系就失去了信任。3.4 销售漏斗阶段转换率和停留时长的计算口径销售漏斗是管理层最常用的报表但也是最容易被数据坑的地方。第一个坑是阶段定义。如果允许销售自己随便填阶段漏斗数据就是一堆垃圾。所以阶段做成系统预置不允许自定义新增只允许在预设的列表里选择。第二个坑是计算口径。漏斗图不是简单Count每个阶段的客户数而是同时看两个指标阶段转换率指的是从上一阶段进入本阶段并且已经流转到下一阶段的商机数除以上一阶段的全部商机数阶段停留时长指的是商机进入当前阶段到离开当前阶段的平均天数。算这两个指标时时间边界非常关键跨年、跨季度都要单独处理不然就会发现1月份的转化率和年报里的数字对不上。后来报表里专门加了一个“统计周期”维度所有数字都按周期单独计算才解决了这个对不上账的问题。4. 数据迁移与外部集成最容易被低估的环节4.1 Excel数据清洗源头脏系统就脏系统开发到70%的时候我就开始准备数据迁移了。原数据来源特别杂一部分在Excel一部分在旧工具导出还有一部分是从聊天记录里翻出来的。迁移顺序我定为先清洗、再试导入、最后核对数量一步都不能跳。清洗分成四步去空行空列、统一字段格式、去重、补全必要字段。统一格式是最繁琐的日期有2022/1/1、2022年1月1日、20220101三种格式手机号有各种加号空格横线金额有“1.2万”“3000元”这种直接写死文本的。我的建议是能在清洗脚本里处理的全在脚本里处理不要人工一条条改。人工改到第500条就开始出错这是必然的。4.2 企业微信和短信集成让跟进记录自动留下来CRM如果不和IM工具打通用一段时间就会变回第二个Excel。我们接入了企业微信的客户联系功能员工在企微里的聊天记录可以同步到CRM的跟进记录里。这样销售不需要特地去CRM写跟进只要日常沟通正常进行系统就会自动留下痕迹。这个设计很受销售欢迎因为对他们来说写周报的负担减轻了。这个集成要处理一个很麻烦的点消息去重。企业微信的webhook回调同一个事件可能推送多次如果每次推送都新增一条跟进记录客户详情页就会被重复消息刷屏。所以接收端做了幂等处理用一个唯一键去判断消息是不是已经处理过已经处理过就直接丢弃。短信集成则是用于提醒场景客户生日、回款逾期、公海回收提醒。发送逻辑放在xxl-job的定时任务里发送前做频控同一个客户一天最多一条营销类短信避免被投诉骚扰。4.3 旧系统并行期与增量同步系统上线后没有立刻关停旧工具而是跑了两到三个月的并行期。并行期最怕两边数据不一致所以做了每日增量同步任务每天晚上把旧系统当天新增和修改的数据同步到新系统。这个思路没错但执行时踩了一个大坑。旧系统里客户被删除了新系统没有收到删除事件于是这个客户就成了“新系统有、旧系统没有”的幽灵数据。销售人员莫名其妙看到一堆已经被清理掉的客户问了一圈没人知道怎么回事。后来在同步脚本里加了软删除状态检查每天比对两边ID集合差异部分生成报告给管理员手工确认。数据同步这个环节宁可每天多花十分钟看报告也不能让脏数据悄悄流进正式系统。5. 真实问题排查登录慢、导出崩、任务漏跑怎么修5.1 登录接口越来越慢缓存没做好再小的库也会拖垮体验系统上线两周后陆续有人反馈登录要转三秒。排查后发现用户表量其实不大问题出在登录时每次都查询了所有部门信息和权限角色加上Redis还没做角色缓存等于每次登录都把全量角色权限从数据库里查一遍。用户一多、并发一上来接口就开始排队。处理办法是两级缓存常用角色信息缓存在Redis权限变更时主动清理相关缓存登录接口本身只做认证权限信息异步加载到前端前端按模块懒请求。改完之后登录响应时间从三秒降到了四百毫秒以内。这个问题的教训是登录接口看着简单但它是所有请求的入口任何一次全表查询都会被放大无数倍。5.2 导出Excel内存溢出大数据导出不能一把梭客户列表导出两千多条数据居然内存溢出了这个Bug当时被测试同事反复提特别影响信任感。排查以后发现是导出工具把所有数据一次性加载到内存再写成文件客户表字段又多每条记录变成一个对象以后占用很高几千条就把堆内存撑爆了。解决思路是分批查询加流式写入。每批查500条写完落到临时文件最后再合并导出任务发给后台前端显示进度条完成后提供下载链接。这样导出大数据不会阻塞主线程用户也不需要一直盯着页面转圈。这个改动之后哪怕是导出五万条客户数据系统也没有再出过问题。5.3 定时任务漏跑调度成功了执行器却在装睡公海回收任务运行了一个多月后有一天运营发现回收规则有一个星期没执行。检查调度中心任务状态明明是成功的但执行器日志里什么都没有。后来定位到原因当天发布版本的时候执行器的Bean被重新加载但调度中心还持有旧的任务参数超时时间设置太短任务还没执行完就被判定为超时下一次调度又被同一个任务卡住。解决办法是调整超时时间、增加执行幂等、设置任务不允许多实例并行执行同时给每个定时任务加上执行开始和结束的日志埋点。现在每次任务跑完都会在日志里打印“开始时间、结束时间、处理条数”运营同事自己就能看出来任务有没有正常执行不用每次找我查。5.4 重复数据合并高危操作要备份、加锁、留痕合并客户是整个系统里最危险的操作之一。比如A客户和B客户被判定为重复合并方向是A保留B合并进A那么B下面的联系人、商机、跟进记录、工单都要迁移到A下面同时更新所有关联表的外键。执行时最怕并发如果用户在合并过程中给B客户录了一条跟进而MySQL外键还指向BB删除以后这条跟进记录就丢了。所以合并功能特意做了事务控制加锁合并过程中不允许任何写入操作并且合并前把两个客户的完整数据备份到一张归档表。这个功能上线以来一共手动跑过三十多次没有丢过一条数据。整体做下来我对CRM这类系统最大的感受是技术难度其实不高难的是业务规则梳理和数据一致性保障。像客户归属、去重、权限、数据迁移每一个听起来只是“一个模块”真正落地时全是细节。如果你也在做类似的系统建议先在规则层面把文档写清楚再让开发动手别急着写代码。最后分享一个实用小技巧上线前找两个销售真人在系统里录一周的真实客户不要用测试数据。真实录入会暴露大量字段命名、交互流程、必填规则的问题这是任何测试用例都替代不了的。DeskcommCRM能平稳上线这一个星期的真人试用帮了大忙。