接到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小时，销售也慢慢养成了当日线索当
