从Excel到自研CRM：数据模型、销售自动化与权限设计全复盘

做CRM系统这事儿说实话最初不在我今年的计划里。当时业务那边拿着一张Excel表来找我说销售跟进记录乱到已经影响报价了——同一个客户三个销售分别登记了不同的对接人交付那边催了三次回款财务说压根没看到合同。我打开那张十万行的表看完第一列就知道靠表格和聊天记录管客户的路子已经走不下去了。所以当老板提了一嘴“要不换个CRM”的时候我没有急着去开采购申请而是先用两周时间把现有的业务流、角色权限、客户类型和对账逻辑盘了一圈。盘完之后我发现市面上成熟产品确实强但要在这个基础上把我们特有的交付验收、回款计划、售后回访串成一条闭环链路得做不少定制。综合考虑成本和后续的数据打通需求我们决定基于开源框架和自研模块搭一套真正贴合自家业务节奏的CRM——起名DeskcommCRM不搞那些花哨的销售概念核心就三件事管住客户管住过程管住钱。这篇就当成一次完整复盘从数据模型到销售自动化从客户合并策略到报表落地再到我踩进去的那些坑。如果你也正准备在团队里搞一套内部CRM或者已经上了系统但用不起来这篇里的大部分内容应该都能直接抄作业。1. 为什么从选型走到自研现成CRM的四个“不够用”在决定自研之前我带着需求清单把主流的几套CRM都体验了一遍。实话实说它们做客户管理、做销售漏斗、做跟进提醒基本功都是过关的中小团队直接拿来用完全没问题。但落到我们这种“销售交付财务”三方协同的业务场景里有几个点怎么试都别扭。第一是客户模型太死板。标准CRM里的客户、联系人、商机对应的是比较标准的B2B销售流程。但我们有大量客户是“一个集团下有多个法人和多个使用部门”的形态签约主体和实际使用主体经常不是同一个。用标准的Account-Contact模型去套每次都要开备注时间一长备注就是信息黑洞。我想要的是一套可以灵活配置的客户层级关系比如“集团—子公司—部门”每一层都能独立挂联系人、独立挂合同这样财务按签约主体对账、交付按使用部门实施才不打架。第二是流程引擎经常被阉割。大多数SaaS CRM的自动化流程只支持标准对象的字段变更触发一旦涉及跨对象联动比如线索转客户的同时要生成待办任务、要通知交付负责人、要按客户类型分配不同团队就得分三步配置还未必支持条件分支。我需要的是一套可以在前端可视化编排的规则引擎触发条件能覆盖字段、时间、操作人、客户层级关系这些维度。第三是报表口径不透明。现成CRM的报表图表倒是漂亮但每个数字背后的统计逻辑是黑盒。我们财务和销售对“成交金额”的理解就不一样——销售觉得签了合同就算成交财务觉得款到账才算。如果系统里的数字解释不了项目复盘的时候就没法用最后大家还是回到Excel去拉数。自研之后我直接可以把口径固化到SQL里每个报表页面上带一个“口径说明”按钮谁有疑问点开就是一行行解释。第四个原因也是压垮骆驼的最后一根稻草数据要进数仓和自研的其他系统打通。CRM只是客户数据循环的一个起点理想情况下它要和企业微信会话存档、财务开票数据、交付工时系统、售后工单系统实时联动。如果只用SaaS自带API去一个个对接成本和时间完全不可控。自己捏在手里数据库直接共用实时性和一致性都好办得多。所以最后的选择不是“现成的不行”而是“现成的不够”。自研不是目的能在自己控制的数据流上快速迭代才是目的。DeskcommCRM第一版的核心目标就定了三条打通客户与合同的关联关系把跟进过程变成结构化的数据让管理层能清楚地看到一个单子从线索到回款走到哪一步。2. 数据模型是地基DeskcommCRM的核心表设计与取舍数据库设计是CRM项目的定盘星后面所有功能、报表、自动化都压在这上面。我一开始没急着建表而是把所有业务对象画了一张关系图最后落到二十多张核心表。这里挑几个关键的讲讲设计时的思考和取舍。2.1 客户模型用Account与Contact分开存绑定层级关系客户表crm_account和联系人表crm_contact是分开的这是CRM的常识。但我在crm_account上额外加了parent_id字段去表示父级账户这样就能表达“集团-子公司”的树形结构。同时每一层account可以单独维护地址、行业、来源渠道、客户状态这些属性。光有树形结构还不够实际业务里经常要处理“签约主体A、使用主体B、付款主体C”这种复杂关系。所以我又加了一个关系表crm_account_relation专门记录account之间的关联类型签约、使用、付款、代运营。报价的时候根据付款主体去找开票资料交付的时候根据使用主体去找实施负责人都是靠这张关系表实时查询。为了这层关系我牺牲了一定的统计便利性——比如“集团成交额”这种汇总要递归遍历子账户——但换来的是财务和交付那边再也没过来抱怨说“客户信息对不上”。2.2 字段设计预配置字段自定义字段不给开发添堵很多自研CRM死在自定义字段上因为开发怕麻烦直接把自定义字段做成动态JSON列查询的时候惨不忍睹。我的方案是做一个字段配置表crm_field_config每一行定义一个字段属于哪个对象客户、联系人、线索、商机、工单、字段类型、可选值、是否必填、是否参与高级搜索、是否启用。前端动态渲染表单后端根据字段配置动态拼接筛选条件。核心业务字段用固定列保证索引和查询效率拓展字段走JSONB列但限制只能存标量值。这样既满足了业务不断加字段的需求又不会把数据库结构搞散。实测下来即使到了4万多家客户、单表千万级活动记录查询性能依然可控。2.3 活动记录一切皆可沉淀但做了冷热分离CRM里最容易被低估的是活动记录。打电话、发微信、开会、发邮件、改字段、跟进状态变化这些都是判断一个单子健康度的原始材料。DeskcommCRM里设计了统一的crm_activity表用 action_type 区分call、meeting、email、note、system用 target_type和target_id 做多态关联可以挂到客户、联系人或商机上。但问题也来了——这张表涨得飞快。一个月就上百万条如果和主查询实时join数据库压力很大。我的调整是热数据保留近三个月的流水用于日常操作和历史查看三个月前的数据定期归档到crm_activity_archived分区表报表层再通过汇总表间接读取。一线用户最常用的是“近一个月的跟进记录”归档之后查询体感基本无变化但数据库压力降了一个量级。2.4 商机与合同拆分不让一个对象承载太多状态很多CRM把商机、合同、回款全揉在一个对象里字段越加越多界面越来越挤状态机也乱。我坚持拆开商机crm_opportunity只关注销售过程记录金额、预计成交时间、阶段、赢率。合同crm_contract只关注法律与商务信息记录合同编号、金额、起止时间、签约主体、审批状态。回款计划crm_payment_plan一个合同对应多期回款记录每期金额、应收日期、实际回款日期、回款状态。这种拆法最直接的收益是财务的出账和销售的跟进是两个独立的业务流不会再互相干扰。比如合同审批通过后系统自动生成回款计划销售继续跟进商机推进下一阶段两边各跑各的都清晰。后来做报表的时候这个拆分省了大事回款逾期率直接一条SQL就能算出来不用再从乱七八糟的合同字段里翻。2.5 权限模型RBAC数据范围缺了数据范围就是摆设权限设计上一个常见的坑是只做了“功能权限”谁能点哪个菜单没做“数据权限”谁能看到哪些客户的记录。结果就是销售员登录系统能看到全公司的客户或者按菜单硬切数据范围非常僵硬。DeskcommCRM用的是RBAC角色权限数据范围双维度数据范围分为四个等级仅本人、本部门、本部门及下属部门、全部。在前端查询时后端根据当前用户的数据范围自动追加过滤条件。同时还有共享规则表crm_share_rule比如某个大客户可以显式共享给多个销售或售前团队。这个策略后期基本没改过支撑了从5个人的小团队到60多人的跨区域团队。3. 线索到回款销售自动化流程怎么一步步跑通数据模型搭好之后接下来是让数据流动起来。DeskcommCRM的核心流程是“线索—客户—商机—合同—回款—售后”这么一条长链路。当时和业务方对齐时我画了一张大流程图后来在系统里一点点实现最关键的自动化节点大概有十多个。我挑几个有代表性的讲。3.1 线索分配按规则自动归属而不是靠管理员手动指派新线索进来之后如果还要管理员手工分配一是慢二是容易落不公。我在系统里做了一个分配规则引擎支持按来源渠道、地区、客户规模、线索关键词这些条件把线索自动分给不同的销售组或个人还支持轮询、负载均衡、最高空闲量几种分配策略。比如百度推广来的线索条件是“地区华东”自动走轮询分配给华东一组的销售如果是合作伙伴转介绍则分配给对应的客户成功经理。分配规则在前端可以配置优先级命中后立即触发通知销售个人工作台里就能看到新线索卡片不用再等群消息通知。这套规则上线后线索响应时间从平均4小时压缩到了20分钟以内别小看这个数字对线索转化率影响很大。3.2 阶段推进与赢率不靠拍脑袋靠历史数据计算商机阶段一般分“初步沟通—方案确认—报价—商务谈判—赢单/输单”每个阶段有个赢率。我一开始是让销售经理手动设置赢率比如“初步沟通10%、方案确认30%…”后来发现这不够科学。DeskcommCRM的报表模块每周会基于历史已关闭商机做一次统计自动计算每个阶段的实际历史赢率然后回写到阶段配置的默认赢率里。比如某段时间“方案确认”阶段的商机最后赢单率只有22%系统就会在页面提示“当前阶段历史赢率低于默认值”倒逼销售复盘是自己跟进问题还是阶段定义偏差。实际跑下来这个方法比教练整天开会催数字管用得多。3.3 超期自动升级没人跟进的事系统来盯销售业务里最常见的事就是“单子凉了都不知道什么时候凉的”。我在商机和合同对象上设置了超期提醒规则如果某个商机超过N天没有新增活动记录系统就把该商机自动标记为“跟进异常”并通知销售主管再超过N天自动进入“待回收线索池”可以由其他销售主动认领。这条规则当时研发觉得做起来复杂但上线后的效果非常直观异常商机的清理速度提升了近一倍以前积压的僵尸商机基本被清空。趁热打铁我后来又加了“回款计划超期自动升级”回款逾期1天通知跟单销售逾期7天通知销售主管逾期30天通知业务负责人。财务再也不用来回找人催了。3.4 合同审批从纸质签字改成在线流转合同审批的痛点以前是“合同在谁那儿卡住了”根本没法追踪。DeskcommCRM对接了自家的审批中心统一支持条件分支、会签、或签并且每一步都有时间戳。合同提交后系统自动判断合同金额档位——普通合同走销售总监交付负责人会签大额合同还要追加财务负责人和法务。这个流程做完之后最大的提升不是审批时间缩短了多少而是它变成了数据每个合同平均在哪个环节停留最久、哪个审批人处理速度最慢都能拉报表。后来我们还做了审批时效排行榜公开在部门大屏上效率立刻就不一样了——这是机制设计的问题不完全是技术能解决的。3.5 商机健康度把“感觉要凉”变成可计算的分数销售预测里最虚的就是“这个月能签多少”。如果完全靠销售自己拍板往往会过于乐观。我参照一些成熟CRM的做法在系统里做了一个商机健康度评分模型按以下几个维度打分最近一次跟进距离今天的天数权重30%客户关键决策人是否已知且参与权重25%阶段停留天数是否超过该阶段平均时长权重20%是否存在竞争对手信息权重15%商机金额与客户历史成交金额的匹配度权重10%满分100低于60自动标记为“风险商机”所有风险商机汇总到管理驾驶舱。上线后销售总监主动把这张表设成了每周例会的第一页因为有具体数字可以吵讨论质量上了一个台阶。4. 客户360度视图多源数据清洗与合并的实操细节CRM能不能让一线销售打心眼里觉得好用很大程度上取决于打开客户详情页时能不能快速搞清楚“这个人是谁、之前聊了什么、我们正好有什么可以讲”。这就引出了客户360度视图的构建也是DeskcommCRM里技术含量比较高的模块。4.1 多源同步客户数据不是录进去的是汇集起来的客户数据最开始分散在四五个地方线下门店的U盘表格、企业微信聊天记录、官网表单、纸质合同、老业务员手机通讯录。靠人工录入根本录不完也录不准确。我的做法是写了成套的同步任务官网表单直接写入线索池并自动映射来源渠道企业微信会话存档定期接入把与客户相关的聊天摘要自动挂到客户时间线上老Excel通过批量导入先进入“待清洗区”不直接进主数据表纸质合同由专人录入校验后进入合同模块自动关联对应客户这种“先汇集、后清洗”的模式能让数据以较低门槛开始流动。但要记住同步任务一定要有可观测性。我专门做了一个数据同步状态页显示每个数据源的最近同步时间、成功条数、失败条数和错误原因。否则哪天断了一个同步没人知道数据又悄悄悄悄变脏了。4.2 客户合并同一个人多个条目怎么处理才不丢信息这是做360度视图时最容易翻车的地方。同一个客户可能在老系统、微信昵称、纸质合同里分别存了三条记录手机号或邮箱还不一样。如果直接合并极可能覆盖掉有效字段。我设计了一个比较保守的合并策略先通过身份证号、手机号、邮箱、企业名称做模糊匹配把疑似同一客户的候选集列出在待合并列表里系统会标注冲突字段比如一个档案里填的是“王经理”另一个填的是“王小明”。合并的时候默认保留完整度较高的一条作为主记录其余内容作为附属记录保存不直接删除。更关键的是“可追溯”。每次合并系统都会在crm_activity表里自动写入一条系统日志记录“哪条记录和哪条记录经哪个用户合并哪些字段被覆盖原值是什么”。这样万一合错了也随时可以回滚。这个设计后来帮我们挡住两次因为重名客户导致的数据错乱事故。4.3 时间线客户的完整故事按时间倒序排开客户详情页我设计成一眼能看到“客户360时间线”把与该客户相关的所有活动、来电、消息、任务、合同签约、收款记录都按时间倒序排列。研发同事一开始觉得不就是把数据按时间查出来吗但真正麻烦的是把来自不同系统的数据统一字段格式。比如企业微信的聊天记录里有“对方撤回了一条消息”这是没有业务意义的数据必须在同步时过滤掉而合同回款数据和活动记录的时间粒度不同可能以天为单位这时候就要在前端展示时做时间分组的归一化。最后我定了一套统一的“展示事件”格式时间、事件类型、事件标题、参与人、结果。所有模块往时间线上吐数据时都按这个格式输出前端只负责渲染不看业务语义。这套结构让后续接入新模块都很顺。4.4 关键联系人识别谁才是这个单子的拍板人客户维度的信息再全如果不知道谁是关键决策人销售还是等于盲人摸象。DeskcommCRM在联系人模块增加了角色标签比如“使用者”“技术把关”“预算负责人”“最终决策者”并且支持手动设置影响力权重和参与度权重。系统会结合活动记录计算出每个联系人的活跃指数和影响力指数在详情页显示“决策人识别提示”。这个功能看着不起眼但对新销售特别友好接手客户的时候不需要重新把聊天记录翻一遍直接看系统推荐就知道该重点围绕谁做工作。相比于那种堆了一堆联系人却分不清主次的界面这个设计可以说非常切中实际痛点。5. 报表、预测与权限管理层和一线都愿意用的设计CRM系统如果没有好的报表洞察就是又一个大号Excel。但把报表做出来只是第一步难的是让不同角色都愿意打开它、相信它、拿它做决策。DeskcommCRM的报表中心走了不少弯路这里分享几条关键经验。5.1 销售漏斗不再只看总金额分阶段看转换率销售漏斗报表是标配。但最开始我做的版本只有“总量金额”和“阶段金额”结果销售们根本不看原因是看不出问题在哪。后来我把漏斗拆成“数量漏斗”和“金额漏斗”两个视图并且增加了“阶段转换率”和“平均停留时长”。比如你一眼就能看到从“方案确认”到“报价”这个阶段金额掉了60%而停留时长是7天高于平均值的2天。这时候销售主管就不会再说“这个月预测不准了”而是直接定位到是哪个团队卡在哪个环节。为了让漏斗数据更可靠阶段变更必须带时间戳并且只有审批通过的阶段变更才计入统计防止人为乱改阶段。5.2 预测准确性让数据自己说话而不是听销售讲故事月度预测的准确性以前全靠销售总监的经验和直觉。我做的预测模块不是让销售填一个“本月预测金额”而是基于三个算法口径自动计算加权预测每个商机金额乘以当前阶段对应赢率求和乐观预测只计算“决策人已知”且“无竞争对手”的商机保守预测只计算本周有计划回款或明确承诺的商机页面把三个口径同时展示管理层自己选信哪个。每个月月底系统会自动把预测值和实际成交通对比给每个销售算一个“预测偏差率”特别离谱的会在经营分析会上公开点评。三个月后销售填阶段的认真程度明显提高了因为他们意识到填得越随意预测越不准最后丢脸的是自己。5.3 自定义报表先做权限隔离再做灵活查询我不赞成一开始就做一个非常灵活的拖拽报表因为每个人都会问“为什么我的报表和别人的数字对不上”。DeskcommCRM的报表权限做了以下隔离个人报表只有自己能看到适合日常跟单统计团队报表团队负责人及以上可见全公司报表老板和管理层可见口径由数据团队统一维护在这个基础上才开放自定义维度组合允许用户选择时间范围、对象、指标、过滤条件。但所有自定义报表背后都调用同一个指标计算服务确保“成交金额”在任何一张报表里都遵循同一套口径。跑了大半年财务和销售最关键的对账终于不再吵架了。5.4 仪表盘要做“驾驶舱”不是“取数机”仪表盘我最后只保留了六个核心卡片今日新线索数、待跟进商机数、本周回款金额、逾期回款金额、销售漏斗总额、风险商机数。每个卡片都可以点击下钻。我不堆砌那些花里胡哨的图表因为管理层上班第一件事就是想用30秒知道“今天哪里出了问题”而不是看二十个指标自己判断。有意思的是自从仪表盘精简之后业务方主动询问“能不能加一个XX指标”的次数反而变多了。因为他们终于看懂了系统在算什么才会提出更有针对性的需求。这比一开始全铺开要有效得多。6. 落地过程中的重建与取舍权限、性能和数据迁移的血泪教训每个自研项目都会碰到那种让人想摔键盘的Bug和设计失误。DeskcommCRM从第一个能用的版本到稳定运行也踩了不少坑这里挑几个印象深刻的希望能给后来者提个醒。6.1 时区问题所有时间统一存UTC展示层再转本地时区一开始开发图省事数据库直接用datetime存本地时间。结果分公司在新疆的同事发现系统里的“今天”永远和本地日历对不上还影响销售漏斗日切。排查了半天最终把所有时间字段统一改成timestamptz带时区的时间戳后端一律按UTC输出前端根据登录用户的时区设置做展示转换。这种基础问题看起来简单但如果不在一开始就统一约定后面改起来特别痛苦。6.2 金额字段永远用Decimal不要用Float第一版合同金额字段用Float某个合同写的是1200000算出来变成了1200000.0000001。财务那边开票系统一对接就弹了个提示“金额不一致”。查了半天发现是浮点精度问题。后来所有金额相关字段全部切入Decimal(18,2)在代码里也统一使用BigDecimal计算。虽然性能没Float好但做财务相关功能时正确性优先于性能这个原则不能妥协。6.3 深分页性能翻到第1000页数据库要崩了客户列表分页用传统的LIMIT/OFFSET到了几万条数据后翻页到后面越来越慢最夸张一次查询耗时12秒。后来换成keyset pagination用“WHERE id 上一页最大id ORDER BY id LIMIT 20”的方式彻底解决了深度分页的问题。代价是页码不能随意跳转但实际业务里用户基本只看前几页完全够用。如果你也遇到列表越来越慢先检查这一条比加什么缓存都有效。6.4 数据迁移从Excel到系统最重要的不是导入脚本而是导入流程第一次把业务方的Excel导入系统时我只写了脚本没设计流程结果数据一进去就乱了各种空字段、重复企业、联系人对应错位。后来调整策略把所有导入数据先进“待清洗区”第一遍机器校验必填项是否完整、手机号格式是否合法、企业名称是否归一化 第二遍人工审核由业务方指派一位骨干抽查5%的数据 第三遍批量写入主库同时生成导入日志和冲突报告。这套流程虽然麻烦但保证了“导入进来的数据是有人负责的”。系统上线三个月数据质量没有出现大问题很大程度上就是因为这个步骤。6.5 权限矩阵宁可多配不可缺失但也要防“越配越乱”权限体系刚做上线时我发现很多用户的权限被反复配置一个账号同时有销售、管理员、财务三个角色非常危险。后来做了两个改进一是“角色互斥”配置比如销售和财务不能同时拥有二是“权限变更审计”功能每次权限变更都会记录操作人、变更前后状态、变更原因。权限这玩意儿看起来平淡无奇不出事的时候谁都感受不到它的价值一旦出一次“销售看到全公司底薪”的事故整个部门的信任感就崩了。所以这个方向值得多花时间。7. 系统的边界什么时候该做什么时候该停DeskcommCRM做了一年多功能越加越多但我一直提醒自己CRM不是越庞大越好。很多时候一个功能没必要做一个自动化规则没必要加一个报表没必要看。做系统的本质是收敛业务复杂度而不是把复杂度从一个地方搬到另一个地方。比如我们曾计划做一个“销售教练”功能通过自然语言分析销售跟客户的聊天内容给出话术建议。技术上可行但业务价值存疑——我们自己的销售大部分场景是线下沟通线上会话占比不高数据样本不足训练出来的东西价值有限。这个需求最终被我砍掉了。我更愿意把资源投入到“回款逾期提醒”“商机健康度”这种已经验证有收益的场景上。另外CRM不应该是所有问题的大熔炉。售后工单模块如果不是必须也建议和相关专业工具对接而不是自己硬造。系统越多团队要维护和学习的成本就越高。做技术选型时要守住边界。在我实际的落地过程中最受益的一条原则是每一个自动化功能上线后的第一周我都会亲自找三位一线销售、一位财务、一位主管聊一轮反馈问“这个功能有没有让你的工作变简单”。如果连续三个用户在三个不同场景下都说没用那就果断下掉或者重新设计。系统是给人用的不是给架构图好看的。DeskcommCRM能从一个“就我们几个人的内部工具”长成现在这样被几十个同事日常依赖的业务平台靠的不是一开始规划得多完美而是每一次上线后都认真听使用者骂什么、干什么、为什么不用。