1. 项目定位为什么要做一套自己的CRM1.1 团队背景与需求痛点DeskcommCRM 这个名字拆开看就是 Desk桌面工作台 Comm沟通协同 CRM客户关系管理。说白了这套系统从一开始就不是奔着做一个“标准 CRM”去的而是要解决团队在客户跟进过程中最扎手的几个问题客户资料散落在微信、Excel、邮箱里销售离职带走一堆客户关系管理层想看销售漏斗只能靠销售自己填报表。我在做这套系统之前先花了两周时间把团队的日常工作流捋了一遍。发现绝大多数人每天真正花在“管客户”上的时间不是录入资料而是在翻聊天记录、找上次沟通的结论、对客户到底处于哪个阶段。这其实暴露了一个很典型的认知偏差很多团队以为 CRM 是“管客户信息的”但实际上CRM 最该管的是“跟进过程”。信息只是静态的过程才是动态的、有价值的。所以 DeskcommCRM 的核心定位很明确以“跟进记录”为中心把客户信息、联系人、商机、工单、日程全部串起来。每个客户点进去相当于打开了一本完整的“沟通档案”从第一次加微信到最后成交每一步都有迹可循。这个设计思路决定了后面所有的数据模型、页面布局和权限设计的方向。1.2 方案选型自研还是购买团队一开始也纠结过市面上成熟的 CRM 那么多Salesforce、销售易、纷享销客都用过为什么要自己做一套这里我得说句实话不是买了不好用而是“不好改”。大平台功能确实全但意味着学习成本高、配置复杂而且最要命的是销售团队的个性化流程很难在里面落地。你要改一个字段的验证规则可能得等两周的工单你想按自己的逻辑做一个自动化提醒平台自带的规则引擎又不够灵活。自研这套 DeskcommCRM最大的优势在于“贴合”。业务部门提需求开发团队直接改今天提的优化明天就上线这种迭代速度是买来的系统给不了的。再加上数据在自己服务器上不管是做数据分析还是对接企业微信、钉钉这类内部工具都没有任何限制。数据库可以按自己的习惯建模API 可以随意扩展这在后期要接 AI 能力或者做报表分析的时候优势会非常明显。当然自研不是没有代价。最直接的代价就是时间成本从零开始搭一套可用的客户管理系统从数据库设计到前后端开发再到测试上线人少了真玩不转。所以如果你们的团队规模特别小比如就三五个人或者业务模式还没稳定下来我建议还是先用现成的工具把流程跑通再说。但如果团队已经有了一定的客户体量并且对流程有自己独特的理解和诉求那自研的逻辑就完全站得住。2. 核心模块设计与业务闭环2.1 客户数据模型怎么建才不会返工做 CRM 最容易犯的错误就是一上来就把客户表设计得特别复杂。字段几十个各种关联表一堆结果开发到一半发现销售根本不用因为录入成本太高。DeskcommCRM 在数据建模时坚持了一个原则核心字段尽量少扩展字段动态加。最基本的客户表我只留了这几个字段客户名称、所属行业、客户规模、来源渠道、负责人、状态、创建时间、更新时间。客户名称这个字段值得一提我把它做了唯一索引同时加了一个“别名”的非唯一字段。为什么因为同一个企业销售A可能录的是“北京华信科技有限公司”销售B可能录的是“华信科技”如果不做处理这两个记录就会变成两个客户。用“别名”字段配合查重规则能解决很大一部分重复录入问题。联系人表单独建一个客户下面可以挂多个联系人。联系人字段包括姓名、职位、手机号、微信号、邮箱、是否为关键决策人。这里有个设计细节手机号和微信号都建了索引因为销售找人的时候最常用的就是按联系方式搜索引建好了查询速度差距非常大。商机表和客户的关联是多对一的一个客户可以有一堆潜在商机。商机表的核心字段是预计金额、成交概率、预计结单日期、当前阶段。这里需要强调一下“阶段”这个字段不少团队把它设计成纯文本我建议一定要用枚举类型因为后续的销售漏斗分析、自动化提醒全都依赖这个字段做条件判断。如果它是自由文本统计数据根本没法做。2.2 跟进记录与销售流程的闭环设计跟进记录是整个系统的灵魂。我设计的跟进记录表有两个核心字段跟进类型和跟进内容。跟进类型包括电话、微信、邮件、线下拜访、会议、其他这六种每一条跟进记录都自动关联到客户、联系人、商机这样任何一个客户页面打开纵向时间线上的跟进历史一目了然。这里有个很实用的细节跟进记录不直接存在客户表下面而是通过一张中间关联表来实现。为什么要分开因为一条跟进记录可能既跟客户相关又跟某个具体商机相关如果直接挂在客户表下商机维度的分析就做不了。用关联表之后同一个跟进记录可以被客户视图和商机视图同时引用数据不用存两遍。销售流程的闭环体现在状态流转上。我设计了一个严格的状态机新客户 - 初步接触 - 需求确认 - 方案报价 - 商务谈判 - 成交另外还有两个特殊状态流失和暂停跟进。状态流转不是随便点的系统里做了规则校验比如从“需求确认”直接跳到“成交”会被拦截必须经过方案报价和商务谈判。这样做的目的不是为难销售而是保证漏斗数据的真实性管理层看到每一个成交客户都经过了完整的推进过程。闭环的另一半是自动化提醒。系统每天早上 9 点自动扫描所有商机的“预计结单日期”如果距离日期不足 7 天且状态不是“商务谈判”或“成交”就给负责人推送一条待办提醒。这个功能上线之后销售跟进逾期的情况明显减少了因为它解决了人最容易忽略的“时间感知”问题。3. 技术实现中的关键环节3.1 权限模型怎么做既能管住又不太烦权限设计是 CRM 系统里最容易走极端的部分。要么权限太松销售之间互相看到对方的客户容易撞单要么权限太紧管理层想看全局数据还得逐个开通麻烦得很。我在 DeskcommCRM 里用的是RBAC 数据范围的双层模型。RBAC基于角色的访问控制解决的是“能不能操作”的问题。我定义了四个角色超级管理员、销售主管、销售、运营。每个角色的操作权限不同例如销售只能对自己的客户做新增、编辑、删除操作销售主管除了这些之外还能查看和编辑自己团队内所有销售的数据运营角色只有只读权限用来做数据分析和报表导出。数据范围解决的是“能看到谁的数据”的问题。每个客户记录上会打一个负责人标记销售登录后默认只能看到“负责人是自己”的客户记录。但这带来一个问题如果某个销售休假或者离职了他的客户怎么办所以我加了一个“转移”功能管理者可以把客户批量转移给其他负责人转移后原负责人的访问权限自动回收。这块逻辑不算复杂但非常容易被忽略做不好就会出现离职销售还能看公司客户数据的安全事故。每个数据请求在后端都会做一次数据权限校验不是单纯靠前端隐藏按钮来控制因为前端权限再严格也能被绕过。我封装了一个通用的查询过滤器在数据访问层统一注入权限条件这样不管后续功能怎么加只要是通过标准查询接口拿数据权限控制都是自动生效的。3.2 自动化提醒与数据统计怎么落地自动化提醒用的是定时任务加消息队列的组合。每天晚上 10 点定时任务会扫描所有数据把需要提醒的事项生成一批任务推送到消息队列里。第二天早上 9 点消费端程序从队列里取任务逐条推送给对应的销售。为什么不在扫描的时候就提醒而要经过消息队列两个原因一是避免高峰期数据库压力过大扫描任务很重直接推送给用户如果再遇到推送服务响应慢会把整个接口拖死二是消息队列天然支持重试和日志记录哪条消息没推出去可以事后排查不会因为一次网络抖动就丢失提醒。统计报表这边我预计算了几个核心指标新增客户数、跟进次数、商机金额、成交转化率、跟进平均周期。这些指标如果每次打开报表都实时从原始表聚合数据量一大查询会非常慢。我的方案是每天凌晨跑一次汇总任务把当天的数据写入统计表用户看报表时只查统计表。虽然实时性差一天但完全满足管理需求。这里要特别说一下“跟进平均周期”这个指标它计算的是从商机创建到商机成交之间的天数。这个数字比成交率更能反映销售人员的执行效率。有的团队只盯着成交率看结果销售人员为了把成交率做上去故意把商机创建时间往后拖或者提前关闭漏斗数据全是水分。有了跟进周期这个指标这类问题就藏不住了。4. 常见问题与排查实录4.1 数据重复问题查重规则怎么定才不至于误伤查重这块我踩过大坑。最初做客户查重时我直接在客户名称上做了精确匹配结果上线第三天就出事了有两个销售录入同一家公司的数据一个录的是“腾讯科技深圳有限公司”一个录的是“腾讯科技(深圳)有限公司”括号全半角不一样系统判定为两个客户。后来我把查重逻辑改成了两层第一层是精确匹配大小写不敏感全半角字符先归一化再比较第二层是模糊匹配用编辑距离算法两个字符串相似度达到 95% 以上就提示疑似重复。但模糊匹配不能做成自动合并只能给出候选列表让管理员人工确认否则误合并的风险太大。我测试下来有一家客户叫“华信科技有限公司”另有一家叫“华信科技发展有限公司”编辑距离相似度很高但其实是完全不同的两家公司如果自动合并就出大事了。实际运行中还发现一个问题客户的别名和历史名称变化。比如某公司之前叫“A网络科技有限公司”后来改名成了“A科技有限公司”按名称查重会把两条记录认为是完全不同的客户但负责人其实是同一个。这个问题的解法是把客户表里的“曾用名”字段也纳入查重范围实现的效果比单纯靠算法优化要好。4.2 提醒不推了怎么回事消息队列的几个坑有一个星期好几个销售反馈说早上的跟进提醒没收到。我排查了一遍定时任务发现任务一直在正常运行日志里也没有报错但队列里的消息就是没被消费。看了半天才发现是消费端程序的数据库连接池满了——因为前一天晚上有个报表在跑把数据库的连接全占满了消费程序获取不到连接就一直处于阻塞状态既不报错也不消费。这个问题靠加日志才定位到因为程序本身没有抛出任何异常表现得像个“假死”。后来我在消费端做了一个超时保护如果连续 5 次尝试获取数据库连接失败就主动抛异常并退出当前批次的消费任务同时向监控群发送一条报警。这样问题即使再次出现也能第一时间发现而不是等用户来反馈。4.3 权限配置后看不出来效果前端缓存惹的祸还遇到过一个挺有意思的问题管理员给某个销售开通了客户查看权限但那个销售刷新了好几次页面还是看不到新分配的客户数据。排查到最后才发现是前端对客户列表做了一层本地缓存缓存的过期时间设成了一个小时所以权限变更之后用户要等缓存失效才能看到最新的数据。这个体验非常差尤其是管理层临时分配客户给销售的场景销售等着干活页面却看不到新数据。我的解决方案是在用户执行“刷新列表”操作时强制绕过本地缓存直接从后端拉数据紧接着在后端的权限校验里加了一个用户的“权限版本号”只要权限发生变化版本号就加一前端拉数据的时候带上版本号和服务端比对不一致就放弃本地缓存。这样既保留了缓存的性能优势又解决了数据一致性的问题。5. 上线之后的维护心得与扩展方向5.1 数据质量怎么保持制度约束加工具辅助系统上线三个月后我发现一个现象数据量上来了但数据质量在下滑。具体表现在跟进记录开始出现“电话沟通客户说再考虑一下”这类毫无信息量的记录。这种记录写了跟没写一样后来的人根本不知道客户到底在考虑什么、顾虑在哪里。光靠系统是解决不了这个问题的必须配合管理动作。我做了一个“跟进记录质量评分”的小功能用关键词和字数两个指标给跟进记录打分低于一定分数的记录会标黄显示并在周报里统计“低质量记录占比”。这个功能上线后销售主动把记录写规范的多了很多因为谁也不想在周报里成为那个“占比最高”的人。这个思路不算什么先进技术但效果出乎意料地好。5.2 接下来可以扩展什么DeskcommCRM 目前已经有客户管理、跟进记录、商机管理、权限控制、自动化提醒、数据报表这六个核心模块。接下来我打算做两件事一是把客户画像做起来根据客户的行业、规模、历史跟进记录给客户打标签方便销售快速了解客户偏好二是接入一个简单的 NLP 接口对跟进记录做关键词提取和情绪分析在商机页面上直接展示这个客户最近沟通的核心主题和态度变化。如果你们也在自研客户管理系统我的建议是不要一上来就想着功能大而全先跑通最小闭环用起来之后再根据实际的痛点和反馈快速迭代比憋一个大版本再发布要靠谱得多。我在开发过程中最深的一点体会是行业里经常说技术和业务要结合其实真正落地的时候选择上面这些技术方案比如查重算法选哪种、权限模型怎么设计每个决策背后的诉求都是具体的业务场景在推着走。
