接到DeskcommCRM这个项目时我脑子里闪过的第一个问题不是“用什么框架”而是“团队为什么要做一套自己的CRM”。市面上SaaS CRM一大把从国际大厂到国内厂商功能堆得又高又全按理说随便挑一套就能用。但真正在业务侧泡过一圈之后你会发现通用产品在落地时永远存在一个尴尬地带——销售流程的个性化表达、客户数据的内部口径、跨部门协作时的权限边界这些软需求往往比功能列表本身更致命。这篇就把DeskcommCRM从零搭建的完整思路拆开讲包含方案选型、数据模型设计、权限边界划分、自动化与集成落地以及部署阶段最容易被忽略的坑适合正在规划自建CRM或者准备替代老旧系统的团队参考。1. 立项逻辑与整体设计思路1.1 通用CRM的痛点倒逼自建先说说为什么要自研。很多团队觉得买一套现成的就行其实不然。我们当时选型调研了十几套产品试用下来发现核心问题集中在三块第一销售团队自己定义的线索阶段和商机推进规则在通用CRM里往往只能靠“自定义字段工作流”硬套配置量一大系统就变成一张巨大的动态表维护成本直线上升第二客户数据往往散落在销售个人微信、Excel表格、客服工单、财务开票记录里通用系统很难低成本地把这些数据源串成一条清晰的客户时间线第三权限模型太粗糙要么是所有人能看全部客户要么是严格按部门隔离完全没法表达“区域销售经理能看自己团队的客户但只读不能改”这类真实业务规则。所以DeskcommCRM立项的时候定的第一原则就是“让业务规则变成系统配置而不是写死在代码里”。销售阶段、审批流程、字段可见性、数据归属范围全部做到后台可视化配置。第二原则是“一切围绕客户时间线展开”不管事件来自销售跟进、客服工单、市场活动还是系统自动记录全部汇入同一个客户的 timeline。第三原则是“权限必须细到按钮级别”做到字段级脱敏、记录级隔离、操作审计全覆盖。这三条原则听起来不复杂真落地的时候直接决定了数据模型、接口设计和服务拆分方式。1.2 DeskcommCRM的技术选型逻辑技术选型这块我们走了比较稳的路子没有追求新奇框架。后端用Java Spring Boot 2.7原因很简单团队对Spring生态熟悉招聘容易运维生态成熟。前端选了Vue 3 TypeScript Element Plus好处是组件丰富、二次开发快销售端和管理端的后台界面都能快速搭出来。数据库用MySQL 8.0核心业务表全部InnoDB引擎配合Redis做缓存和分布式锁。搜索这一块初期数据量还没到需要Elasticsearch的程度直接用了MySQL全文索引和前缀匹配兜底等客户量到百万级再考虑引入ES。这里有个经验值得分享CRM系统千万不要一开始就把架构搞得太重。微服务、消息队列、K8s全家桶这些东西在早期只会拖慢迭代速度。我们刚开始就是单体应用模块化划分好边界后端按业务包分层前端按业务模块拆目录等真正需要扩展了再按模块拆服务也不迟。事实上DeskcommCRM跑了半年单体架构完全扛得住直到导入历史数据和对接第三方系统的需求上来之后才逐步把报表模块和工单模块拆了出去。2. 数据模型与权限架构2.1 客户数据建模的核心字段设计做CRM第一件事就是把客户数据模型定清楚。DeskcommCRM里客户分两大类型企业和联系人。企业表存公司主体信息联系人表存个体信息两者是多对一关系——一个企业下面可以有多个联系人一个联系人也可能同时关联多个企业比如采购经理跳槽后历史关联关系仍要保留。这个设计看似简单实际很多CRM要么把企业和联系人混在一张表里要么联系人只能挂单一企业后续做商机分析、客户画像时就会到处踩坑。企业表核心字段包括企业名称、统一社会信用代码、所属行业、企业规模、客户状态潜在/跟进中/已成交/流失、来源渠道市场活动/转介绍/自然流入/老客户扩展、归属销售ID、创建时间、最后跟进时间。这里“最后跟进时间”字段特别重要是后续做销售跟进提醒和客户活跃度分析的基础。联系人的核心字段包括姓名、手机号、微信号、邮箱、职位、决策链角色决策者/关键影响者/使用者/内线以及是否主联系人标记。我在建模时坚持加了几个容易被忽略的字段客户唯一标识外部系统同步时用、数据来源批次号批量导入回溯用、更新时间戳增量同步用。这几个字段在后续对接数据中台和第三方系统时省了无数事。另外强调一点手机号和微信号这类敏感信息要做字段级加密存储查询时按需解密前端列表页默认脱敏显示点击“查看”按钮才明文展示这个逻辑是权限模块最先要支持的。2.2 销售阶段和商机的状态机设计商机是CRM的核心业务对象它的状态流转设计直接决定销售漏斗是否真实可用。DeskcommCRM里商机状态机不是写死在代码里的switch而是通过配置中心维护的一张流转表每个状态节点定义状态名称、允许进入该状态的角色、进入时是否必填某些字段、是否触发通知、是否自动创建跟进任务。默认的商机阶段是九段式但根据行业调整过初步接触刚拿到线索关联客户需求确认完成初步需求访谈方案报价发送解决方案或报价单商务谈判涉及折扣、条款协商赢单合同签订丢单记录丢单原因这套模型支撑了一个很实用的功能商机阶段转化率报表。从“初步接触”到“赢单”的每一步都能看到有多少商机流入、多少流出、转化率是多少、平均停留多少天销售管理者一眼看出哪个环节最卡。数据模型上商机表除了基础信息外还有一个当前阶段ID、进入当前阶段的时间、预计成交金额、预计成交日期、赢单概率。赢单概率是阶段和行业数值的映射但允许销售手动调整保证一线灵活度。2.3 权限模型字段级脱敏和记录级隔离权限这块DeskcommCRM用的是RBAC基于角色的访问控制加数据范围的双层设计。用户属于一个或多个角色角色绑定一组权限点权限点精确到操作按钮查看、新增、编辑、删除、导出、审批、分配。数据范围单独一张表配置支持几种模式仅本人、本部门、本部门及下级部门、全部数据、自定义数据范围按区域或客户分组过滤。数据范围配置示例“华东销售总监”角色数据范围是“本部门及下级部门”那么他看到的客户记录就是华东销售团队所有人的客户但记录的“编辑”权限可能只配置给自己直接负责的客户不是全部可改。这块要让销售总监能看不能乱改又要让他对团队客户有全局把控。字段级脱敏则是另一个维度普通销售查看客户时客户手机号显示为138****1234片区经理可以看到完整手机号只有管理员和导出角色可以看到全部字段并且允许导出Excel。权限设计里最容易忽略的是“跨部门协作”。比如售前工程师被拉到一个客户的方案沟通群里他要临时查看这个客户的资料但没有这个客户的归属权限。DeskcommCRM的方案是引入了“协作空间”——销售可以把某个客户主动分享给指定用户有效期可设到期自动回收。每次分享都记录操作日志谁在什么时间把哪个客户分享给了谁避免客户数据被变相泄露。这里我建议所有权限模型里都加审计日志哪怕前期用不上后面追责的时候就靠它了。3. 核心业务功能实操拆解3.1 线索管理从市场活动到有效商机的过滤漏斗线索这个词在CRM里的定义很关键。线索是不确定的需求商机是确认的需求客户是长期关系的实体。很多团队把三者混为一谈结果漏斗分析一塌糊涂。DeskcommCRM里线索管理从市场活动引入开始一场线上直播带来2000条线索市场部导入系统后系统自动做三件事去重同手机号、同企业名的合并、补齐通过企业库API补充行业、规模信息、分配按区域、按线索池规则自动分配给对应销售。销售拿到线索后执行“跟进—回访”动作系统记录每一次跟进的时间和内容并标记线索反馈有需求转化为商机、暂不需要进入培育池、无效线索关单。这里有个细节线索转商机时系统自动携带线索来源、首次来源渠道、首次来源活动三个字段到商机表这样后续统计ROI就能知道哪场市场活动真正带来了订单而不是只停在场次和报名量层面。线索分配是实操中最容易出矛盾的点。我推荐采用“预占式分配”新线索进池系统按规则分配给某个销售该销售有24小时的黄金跟进期48小时内未做有效跟进动作线索自动释放回池子重新分配。这个规则一开始阻力很大但跑通后线索平均响应时间从原来的36小时降到7小时销售也慢慢养成了当日线索当