DeskcommCRM 这个名字，我第一次看到是在团队内部讨论客户端信息维护方案的时候。说实话，市面上的 CRM 并不少，但真到用的时候，总有种“功能全归全，可就是不够顺手”的感觉。后来我们决定自建一套，定名 DeskcommCRM，从需求梳理到上线维护，前前后后踩了不少坑，也沉淀出很多实操细节。这篇就围绕这个项目，把从 0 到 1 的过程完整拆开讲讲，重点聊需求、数据模型、技术栈、落地实现和上线后维护这五个环节，适合正在犹豫要不要自建 CRM，或者已经开始自己写但缺少系统思路的团队参考。
1. 为什么一个团队会需要自建CRM
1.1 先从一团乱的客户信息说起
大多数中小团队的客户信息管理，一开始都是靠 Excel 和微信群。销售跟进到哪一步、合同什么时候到期、售后问题有没有人处理，全靠每个人的自觉。客户一多，问题就全暴露出来了：同一个人被两位销售同时跟进，报价版本对不上，合作到期没人提醒，客户反馈在微信里翻了十分钟才找到截图。DeskcommCRM 最早的出发点就是解决这个问题，把客户、联系人、商机、工单这些散落的信息收敛到一个系统里，用一套明确的状态机约束每一步流程。
为什么非要自己写，而不是直接买现成的？原因也很简单。市面上成熟产品确实稳定，但字段、权限、流程都是按通用场景设计的，真要贴合团队习惯，要不就得花大量时间配置，要不就得接受很多用不上的模块每天干扰视线。自建 CRM 最核心的逻辑不是“造一个功能更多的产品”，而是“造一个符合我们工作习惯的系统”，所以需求梳理比代码更重要，一定不要让开发同学直接开工，而是要先把业务方天天抱怨的点列出来。
1.2 商业化产品与自建的取舍
自建不一定适合所有团队，这一点必须先说清楚。如果团队只有三五个人，业务模式也相对固定，用成熟 SaaS 产品是最省成本的方案。但像我们这种客户周期长、涉及报价审批、售后工单又多的业务，通用产品的客制化成本并不低，叠加按席位付费和接口限制，算下来几年费用足够支撑自建了。
当时我们做了一个很简单的对比：按 20 人团队估算，市面产品每人每年大约 2000 到 4000 元，加上集成和定制开发费用，首年基本 8 到 15 万。自建方案分摊到两年，主要成本是服务器和开发人力，如果团队里本身有后端和前端资源，边际成本就更低了。更重要的是自建之后，每一个字段、每一个按钮都可以按自己的业务来，真正做到了“系统适应业务而不是业务适应系统”。
1.3 DeskcommCRM 的定位和功能边界
自建系统最忌讳的就是贪多。最初我们列功能清单时，差点把 OA、财务、项目管理系统都包进去，后来硬生生砍掉了一大半，才确定 DeskcommCRM 的核心边界：客户管理、线索跟进、商机转合同、售后工单，外加一个轻量报表看板。所有审批流程都围绕客户生命周期展开，不做考勤、不做报销、不做内部 IM，这些交给更专业的工具。
权限也分得很清楚：销售只能看自己名下的客户和商机，销售主管可以看本部门数据，管理员拥有全部配置权限。这个边界确定之后，后面的数据模型设计、接口规划、页面布局都变得简单了。很多自建项目做不下去，不是开发能力不行，而是边界没划清楚，需求越加越多，最后变成谁都不敢用的巨无霸。
2. 核心数据模型：先想清楚再动手写代码
2.1 客户与联系人的主数据模型
数据模型是 CRM 的地基，这块设计不好，后面写多少代码都是补窟窿。我们的第一版设计是把联系人和客户存在同一个表里，结果客户公司信息一变，所有关联数据全乱。后来重构时，才老老实实拆成三个核心表：客户表、联系人表、客户归属关系表。
客户表存的是公司级信息，包括公司名称、统一社会信用代码、行业分类、客户等级、所属地区、来源渠道、创建人、创建时间。联系人表存的是个人级信息，包括姓名、职位、手机、邮箱、微信、备注，通过外键关联到客户表。之所以要单独拆出归属关系表，是因为一个客户可能同时被多个角色跟进，比如售前顾问谈新需求、客户成功经理管日常、售后工程师处理故障，如果只是简单地在客户表里放一个拥有者字段，那后加的角色就只能改字段了。
这里有一个比较实用的经验：给每个表都加上version字段，每次更新时递增。虽然听起来很土，但排查并发修改和数据同步问题时会非常有用，尤其是在 Webhook 回调更新场景里，没有版本号几乎没法处理冲突。
客户表、联系人表之外，我们专门加了一个去重表，也可以理解成客户 ID 映射表，用来记录同一家集团下面的不同法人主体之间的关联关系。比如“某某集团华东分公司”和“某某集团”在业务上是同一个大客户，但在数据上又是两个独立客户，如果没有映射关系，报表统计时就会算成两个客户，数据永远对不上。
2.2 线索、商机、工单各自的状态机
CRM 里最容易出逻辑漏洞的就是状态流转。线索、商机、合同、工单不是简单的增删改查，它们都需要一套明确的状态机。
线索的状态我们设计成：新线索、跟进中、已转化、已放弃。转化动作会创建一个新的商机，并关联回原来的线索。这里有个小细节要注意：线索一旦转化，就不能再被随意编辑，否则会出现一条转化后的商机对应一个被改得面目全非的线索，审单时根本无从追溯。
商机的状态更复杂，包含：初步沟通、需求确认、方案报价、商务谈判、赢单、输单。每一步之间不是可以随意跳转的，比如“方案报价”之后必须由主管审批通过才能进入“商务谈判”。我们把这些状态流转写成一张独立的配置表，由管理员在后台维护，而不是写死在代码里。这样业务方自己就能调整流程，不用每次改流程都找开发。
工单的状态我们分了：待分配、处理中、等待客户反馈、已解决、已关闭。并且有一个规则：工单在处理中和等待客户反馈之间，必须留有超时自动提醒。客户三天没回复，系统要自动发通知给客服；客服两天没更新处理进展，系统要提醒主管。这种状态机配合定时任务的效果，远比人手去催要可靠得多。
2.3 标签体系和自定义字段
每个团队都会有一些特殊字段，比如我们业务上需要记录客户的采购偏好、预算范围、供应商评级，这些字段在产品化 CRM 里往往要通过付费模块才能实现，自建的话直接加自定义字段即可。但我们做的时候也踩过一个坑：自定义字段一开始不加类型校验，导致同一个字段有的填文本、有的填日期，后面统计报表时根本没法按类型处理。
所以后来我们在自定义字段设计上加了三要素：字段类型、是否必填、所属分组。字段类型严格限定为文本、数字、日期、单选、多选、关联记录六种，暂时不支持任意类型。单选、多选的选项值需要提前在选项字典里维护，不能随手在界面上随便填。这样做的原因是为了保证后续筛选和报表聚合时的数据一致性。
标签体系则是另一个维度的补充。字段是结构化信息，标签是非结构化信息。比如“试用过竞品”“有扩容预算”“决策周期长”这类描述，用标签比用字段更灵活。我们规定标签统一用小写英文加连字符存储，展示层再映射成中文，这样无论是做模糊搜索还是做数据导出，都不会出现因为大小写不一致而产生重复标签。
2.4 权限模型：部门、角色、数据范围
权限设计如果一开始不考虑，后面再做就是大工程。商用 CRM 数据往往涉及销售机密，客户联系方式、报价信息肯定不能全公司可见。DeskcommCRM 采用的权限模型是三要素：角色、部门、数据范围。
角色决定能做什么操作，比如查看、创建、编辑、删除、导出、审批。部门决定数据归属，每个客户记录必须有一个负责部门。数据范围分为三种：仅本人、本部门、全公司。销售默认仅本人，销售主管本部门，财务和管理员全公司。在代码层面，所有查询都会自动带上数据范围过滤条件，不需要业务层每个查询都手动写权限判断，这样的好处是不会漏掉某个角落的接口导致越权。
授权之外还需要操作日志。每次客户资料的查看、导出、修改都会记录操作人、时间和变更前后的值。最开始我们对操作日志的态度是随便记记，直到有一次客户投诉销售泄露联系方式，才发现没有日志完全无法追溯，从那以后所有关键字段的修改日志都会同步到一个独立日志服务里，至少保留三个月。
3. 技术选型与架构设计
3.1 前后端框架选型背后的逻辑
技术选型没什么神秘，核心标准就三条：团队熟悉度、社区生态、长期维护成本。我们后端选了 Python 的 FastAPI，主要原因不是它快，而是类型声明配合 Pydantic 在做字段校验和接口文档生成时极其顺手，写一个接口可以把参数校验、自动文档、数据序列化一次做完，开发速度能提升不少。
前端选了 Vue 3 加 Element Plus。之所以没有上 React，纯粹是团队里大部分人更熟悉 Vue 的模板写法，做后台管理类系统时 Element Plus 的基础组件基本可以直接用，省去大量造轮子的时间。这里想提醒一句：技术选型别追新，尤其是 CRM 这种重业务系统，稳定、熟练、能维护才是第一位。我们有个模块曾经用了一个刚出不久的状态管理库，结果社区资料太少，出问题只能读源码，硬是耽误了两周，后来才换回了成熟方案。
3.2 数据库选择与使用中的坑
主数据库我们用了 PostgreSQL，没选 MySQL。原因也很实际：CRM 的客户标签、联系人信息里有很多 JSON 格式的不定长数据，PostgreSQL 的 JSONB 类型配合 GIN 索引，在灵活性和查询性能上的表现比 MySQL 更稳。另外一个重要原因是 PostgreSQL 的数组类型和全文检索能力，在实现客户名称模糊搜索时省了很多事。
但数据库也出过不少问题。最典型的是连接数被占满。原因是某几个列表接口没有做分页限制，前端每次刷新都全量查询，后端连接池被打满之后，连正常的登录接口都超时。这个问题最后通过三步解决：一是所有列表接口强制分页，最大每页 100 条，二是用 PgBouncer 做连接池，三是给慢查询日志加了阈值，超过 200ms 的 SQL 统一输出到单独文件，方便定位。
值得一提的还有索引设计。客户表的数据到 10 万条以后，搜索明显变慢，排查发现是没有给搜索字段建联合索引。后来按照查询习惯把customer_name和owner_id建了联合索引，再用gin_trgm_ops支持模糊查询，查询时间从 3 秒压到了 50 毫秒以内。建议所有做自建 CRM 的团队，上线之前一定要先做一次数据量模拟，至少压到未来一年预期数据量的两倍，再检查索引和接口性能。
3.3 通知、文件存储、审批流这些周边模块
CRM 离不开通知。跟进记录更新、工单状态变化、商机审批提醒，都需要通过站内信、邮件、企业微信机器人发送。我们做了个简单的消息中心，事件发生时不直接调用发送接口，而是写消息表加一条记录，由后台异步任务统一推送。好处是业务操作不会被发送失败拖累，而且消息记录可查、可重发。
文件存储方面，客户合同、对账单、产品手册等附件都走对象存储，数据库只保留文件 key。最开始我们图省事直接把文件存服务器本地，结果磁盘很快被塞满，备份也特别麻烦。换到对象存储后，权限控制也顺便解决了：需要给某个客户分享附件时，生成一个带时效的预签名 URL，到期自动失效，比自己在应用层做限权简单太多。
审批流我们没有引入独立的工作流引擎，因为场景相对固定：报价审批、合同审批、交付审批，总共不到十种流程。用一张审批配置表加一张审批实例表，通过模板配置每个节点由谁审批、需要什么角色、是否要多人会签。这种方式对中小团队足够用，而且排查问题非常直观：审批实例表里可以看到每个实例当前停在哪个节点、谁还没操作。真到需要复杂条件分支的那一天，再考虑引入流程引擎也不迟。
3.4 API 设计时一定要留好的扩展口
技术架构里最容易被忽略的是 API 设计的前瞻性。我们一开始只是老老实实地写 CRUD 接口，后来接企业微信、接第三方呼叫中心、接简道云表单时，才发现没有统一的事件机制，到处加补丁代码，丑得不行。
第二版重构时，我们给所有写操作统一返回resource_id、revision、changed_fields三个字段，并在代码层面对外抛出领域事件，比如LeadConverted、DealWon、TicketClosed。其他模块通过监听这些事件来执行后续动作，比如商机赢单后自动生成任务提醒、推送财务复核。这套设计让新增扩展模块时不再需要改动已有代码，维护性提升非常明显。建议在动手之前，就把这套事件规范写进开发文档，越早定越省事。
4. 关键功能实现与实操细节
4.1 客户去重与模糊搜索的落地
客户去重是 CRM 领域的老大难。我们最初的去重规则只是精确匹配公司名称，结果“XX有限公司”和“XX股份有限公司”被当成两个客户，数据一多非常头疼。后来改成了三层匹配：第一层精确匹配统一社会信用代码，第二层名称精确匹配，第三层名称归一化后分词匹配。
归一化处理里有几个细节值得展开说说：一是统一全角半角，二是去掉公司类型的后缀，三是把括号统一为英文括号，四是将“有限公司”和“有限责任公司”这类后缀归一化。做完这些处理后，再用 PostgreSQL 的 pg_trgm 做相似度匹配，设置相似度阈值在 0.7 左右，基本能把重复客户识别出八成。匹配时只标记为“疑似重复”，而不是直接合并，避免误伤。
模糊搜索则是一个从惨痛教训中优化出来的功能。最初用LIKE '%关键词%'，数据量一上来，查询直接爆炸，因为无法走普通索引。后来改成了 pg_trgm 的 GIN 索引结合相似度查询，效果立刻好了很多。前端还做了一个交互细节：输入两个字符以上才触发搜索，并且在结果里高亮命中片段，用户点击后直接跳到客户详情页。整个体验跟搜索一个网站差不多，销售同学用起来评价不错。
4.2 销售漏斗与看板统计的实现
销售漏斗看板是管理层最看重的模块，也是开发起来最容易踩统计口径坑的模块。我们第一次做的时候，看板上的每一个数字都能从数据库里查出来，但就是连不成一条逻辑完整的销售链路，原因在于对漏斗阶段的时间点定义不一致。
后来我们统一了一个概念：一个商机在任何时刻都只属于一个阶段，阶段变更必须记录变更时间。看板统计时，只统计“当前阶段”的商机金额，而不是把所有历史上进入过该阶段的商机都算进去。用代码表达就是WHERE deal.status = 'quotation'而不是WHERE EXISTS (SELECT 1 FROM deal_history WHERE stage = 'quotation')。这个口径统一之后，漏斗数据才真正能反映大家脑子里预期的那个漏斗。
另外一个实用技巧是趋势图的时间桶。统计某个月的赢单金额时，不能简单用“创建时间”或“预计成交时间”，因为商机的推进经常跨越多个自然月。我们最终选择了“赢单时间”作为收入统计的基准，也就是deal.closed_at的月份。这样财务核对和销售提成都有了一个共同依据，不会再出现两张报表对不上的情况。
4.3 自动化工单和超时提醒
工单模块的核心不是“记录一个售后问题”，而是“保证每个问题都不被遗忘”。我们给工单设了三层自动任务：新工单创建后 15 分钟未分配，通知客服主管；工单处理中超过 24 小时未更新，通知工单负责人；等待客户反馈超过 72 小时，自动发提醒给客户并抄送客服。
这些自动任务最初是用 Python 的定时框架APScheduler在应用内部跑的，结果部署多实例后，定时任务在每个实例上都执行了一遍，导致重复通知。后来改成把定时任务单独拆成一个 worker 进程，通过 Redis 分布式锁保证同一时刻只有一个实例在处理某个工单的提醒。这里有一个写代码之外的经验：定时任务和业务接口一定要分开部署，否则业务高峰期定时任务跑来抢资源，接口响应会明显变慢。
自动化工单的设计里还有一个细节，就是允许客户通过邮件回复工单。我们接入了一个简单的邮件轮回应用，把客户回复邮件自动追加到工单详情。虽然实现难度不高，但客户体验提升非常明显，不需要为了回复问题专门去登录系统。
4.4 从 Excel 导入时的坑
系统刚上线时，存量数据都在 Excel 里。第一次导入我们踩了一个大坑：直接让用户用系统提供的模板手动整理，结果导入错误之后排查非常痛苦。后来把导入流程拆成四步：上传文件、字段映射、预览校验、正式导入，每一步都在界面上给出反馈。
字段映射时，系统会自动识别 Excel 表头和系统字段的相似度，用户只需要确认或用下拉框手动匹配。校验阶段会展示每一行数据的问题，比如手机号格式错误、客户名称为空、关联负责人不存在等，同时给出“只导入正确行”的选项。这个设计看似简单，但在实际使用中能减少大量客服咨询，也是我们后来数据质量能保持较高的主要原因之一。
导入的数据还需要做增量识别，原则是同一批次内如果两行客户名称相同，则只保留第一个，并在校验结果里标记出重复行。正式导入前还会自动备份本次数据到一张 raw 导入表，即使导入出问题也可以随时回滚。强烈建议所有做数据导入功能的团队都保留这一层，别问我为什么，都是教训。
5. 上线后最常见的几个坑
5.1 列表查询越来越慢，性能排查怎么做
上线一周后，销售同事反馈客户列表加载越来越慢。最开始我以为是网络问题，后来才发现是请求量上来后，数据库慢查询把 CPU 打满了。性能排查的工具组合其实非常简单：数据库层面打开慢查询日志，应用层面用 APM 工具记录每个接口的耗时，最后通过EXPLAIN ANALYZE分析 SQL 执行计划。
常见的性能问题是分页偏移量过大。客户列表翻到第 100 页时，数据库要扫描前 1000 条再丢到前面，后续翻页的响应时间蹭蹭上涨。优化方式是改成游标分页或者基于created_at和id的键集分页，首页加载速度一下子就上来了。同时要把列表接口的默认排序字段固定下来，如果每次排序字段都不一样，索引就很难生效。
另外一个被忽视的问题是前端表格一次性渲染太多 DOM 节点。即使接口只返回了 50 条数据，如果表格列特别多，渲染也会卡。解决方案是用虚拟滚动，只渲染可视区域内的行，这个在数据列表超过 100 行的场景下必做不可。后来我们干脆把客户列表默认显示列控制在 8 列以内，需要更多信息的用户自己配置显示列，界面清爽了，性能也好了。
5.2 汇总报表和明细对不上，十有八九是口径问题
我遇到过最头疼的 bug 是报表模块里“客户总数”和客户列表页显示的数字不一致。两边查的都是客户表，按说应该完全一样，结果差了十几行。排查了整整半天，发现原因是列表页面默认过滤掉了“已归档”客户，而报表模块的 SQL 没有加过滤条件。这类问题的根源在于统计口径分散在各处代码里，没有统一收口。
后来我们统一封装了一个查询服务层，所有涉及客户、商机、工单的列表和统计都通过这层来查，并且在代码里定义了一套带语义的指标常量，比如client_total、deal_active、ticket_open。这样以后任何页面要显示客户总数，都只调用同一个方法，不会再出现各写各的 SQL 导致数据对不上。上线之后如果再遇到对不上的情况，第一步永远是去查看双方定义的口径，而不是急着改代码。
5.3 权限串数据：最容易出安全事故的环节
权限问题通常出现在关联查询里。比如一个销售可以查看某客户的详情，但同时能通过客户详情接口的关联参数，查到这个客户下的联系人列表，而如果联系人列表接口没做权限校验，那就能看到全公司所有联系人的手机号。这是典型的接口级越权问题，比在页面上少个按钮严重得多。
我们的解决方案是写了一个中间件，在返回数据前检查当前用户对每条记录的数据范围权限。同时专门组织了针对所有关联查询接口的越权测试，用一个权限很低的测试账号遍历所有接口 ID，不断检查响应是否包含预期之外的数据。这种测试建议每发布一个重要版本之前都跑一遍，权限问题是安全底线，绝对不能寄希望于前端隐藏按钮。
5.4 员工不乐意录入数据，怎么办
系统功能做得再好，如果销售不愿意录入，一切都白搭。上线第一周我们遇到了非常尴尬的局面：老板在后台看销售漏斗，销售在前台吐槽 CRM 浪费时间。后来我们总结了经验：系统要给使用者提供直接的收益，而不是只给管理者提供报表。
落地过程中我们做了两件事。一是把 CRM 和日常高频动作绑定，比如发报价单、生成合同必须从 CRM 里发起，数据自然地沉淀到系统里。二是做了一系列自动化便利功能，比如自动识别客户的公司名和地址、一键生成跟进日报。当录入变成顺手的事，而不是额外的工作，员工的配合度自然会提高。不要指望靠考核逼销售录入，这是所有做 CRM 的人最深刻的教训。
6. 如果重新做这个项目，我会做的不同选择
6.1 先用现成工具验证需求，再决定自研
如果再给我一次机会，我会先用低代码平台或者现成的开源 CRM 搭一个原型，跑通业务流程，收集真实反馈，再决定要不要完全自研。这样做的好处是能用最小的成本验证“自建系统是否值得”，而且很多需求在原型阶段就会发现其实并不需要开发，调整业务习惯比做功能快得多。
我们现在这套系统能跑起来，很大程度上归功于第一版原型帮我们理清了字段和流程。否则一上来就写完整代码，大概率会在需求不明确的情况下反复重构。现在很多团队一听到“定制化需求”就想着从零开始写，这是成本最高、风险最大的一条路，除非业务已经跑得很顺、需求已经非常清楚，否则不建议半路出家直接上。
6.2 数据备份和灾备一定要提前做
上线之初我们依赖数据库云服务的自动快照，觉得已经足够了。直到有一次误操作删了一张表，才发现快照恢复至少要等 20 分钟才生效，业务完全停摆。后来我们加了实时流备份到另一个存储，同时每天晚上备份到异地对象存储，备份文件保留 30 天。恢复流程也做了三次演练，确保在关键时刻能在一分钟内把服务拉起来。
数据备份这件事，平时没有人会感激你，但出问题时它就是救命稻草。CRM 里的客户资料、合同记录、沟通历史，每一笔都是业务资产。建议每一个自建系统的团队都认真对待，不要嫌麻烦，定期测试恢复流程。很多系统死于物理故障或运维事故，而不是死于需求问题。
6.3 最后一个经验：给系统留出养成的周期
上线不是终点，只是开始。DeskcommCRM 上线后前两个月是数据质量和用户习惯养成期，这个阶段需要运营介入，而不是纯粹靠技术。我们每周都会从系统里导出数据质量报告，看看哪些客户没有填写来源、哪些商机停留在一个阶段太久没更新，然后找对应负责人沟通原因。
这个过程听起来很耗人力，但它对系统的长期价值非常关键。很多自建系统不是被技术打败的，而是被团队的使用率打败的，没有数据，再好的系统也只是空壳。我记得有一段时间销售总监特别积极地使用看板和分析功能，是因为他发现每周例会上可以直接从系统里拉出团队数据，省掉了很多手工统计的时间。这种正向反馈一旦建立，后面的推动就顺理成章了。
