DeskcommCRM 并不是一个商业产品，它是我给一家销售型小团队从零搭起来的内部客户关系管理系统。刚开始立项的时候，老板的想法很简单：把销售手里的客户资料从 Excel 和微信聊天记录里救出来，放到一个所有人都能看得见、又不会互相乱改的地方。做下来以后我发现，越是听起来简单的需求，落地时越容易翻车，CRM 这种系统尤其如此——因为它管的不只是数据，而是人和人之间的协作节奏。
这套系统最适合两类人参考：一类是销售或运营团队里的技术负责人，想用最小的成本解决客户跟进混乱的问题；另一类是想系统搞明白 CRM 背后核心逻辑的开发者，看看一个真实的客户管理工具从表结构设计、权限模型到跟进流程引擎，到底是怎么一层层长出来的。项目跑起来以后，客户从录入到成交的平均周期缩短了一截，更重要的是，销售离职交接时不再出现“人走了、客户也带走了”的烂账。
先说我为什么没有直接买现成的 CRM。市面上开源的、付费的 CRM 我前后试过不下八款，最后放弃的原因出奇一致：要么业务字段改不动，要么销售觉得录入负担太重、用不起来。DeskcommCRM 从第一天起就把“销售愿意用”当成最高优先级，宁可功能少一点，也要让每一次点击都有即时反馈。
1. 整体设计思路：为什么做一个以“跟进”为中心的 CRM
1.1 核心需求拆解：不是管客户，是管“下一步动作”
项目刚启动时，我照着传统 CRM 的思路画了一堆模块：客户管理、联系人管理、商机管理、合同管理、产品库、报表中心。画完以后拿给销售负责人看，对方眼神里全是抗拒。后来我坐在旁边看了一个下午的销售工作过程，才明白问题出在哪：销售真正的工作流不是“录入客户资料”，而是“今天要联系谁、上次聊到哪了、接下来做什么”。
所以 DeskcommCRM 的设计主轴被我彻底换掉了。所有页面都围绕“下一步动作”来组织：首页不是一堆统计图表，而是一份按计划时间排序的跟进清单；客户详情页的第一屏不是字段表单，而是这条客户最近五次的沟通时间线和待办任务。这个改动听起来小，实际影响巨大——销售打开系统的第一反应从“又要填表了”变成了“哦，原来我该干这个”。
我把这种方式叫“动作优先”的设计原则。数据录入不再是一堆必填字段，而是嵌入在“记一笔跟进”这个动作里。每一次跟进，顺手把客户的公司、联系人、阶段、金额一起更新，系统会用时间戳把变更历史自动记录下来。也就是说，数据是被“用”出来的，而不是被“填”出来的。
1.2 架构取舍：单体应用就够，别急着上微服务
很多开发者一听到 CRM 就会想到复杂的权限、多租户、海量数据，恨不得起步就是微服务。我的判断完全相反：一个几十人规模的销售团队，核心数据量撑死几十万行，单体应用用起来最顺、最稳，也最好维护。DeskcommCRM 采用的就是前后端分离的单体后端加一个 PostgreSQL 数据库，部署在一台 4 核 8G 的云服务器上，跑了半年，CPU 日常占用基本没超过 15%。
这个选择背后的逻辑很直接：系统复杂度的增长点不在并发，而在业务规则。真正的难点是权限边界怎么划、商机阶段怎么流转、数据怎么去重合并，这些跟微服务一点关系都没有。如果一开始就拆服务，光处理服务间的事务一致性和调用链路，就能把项目拖垮。
我把可扩展性留在了数据层：数据库尽量用标准 SQL，避免不必要存储过程；对外提供 REST API；将来真需要拆服务，把跟进模块、报表模块单独抽出去，边界是清晰的。但这是后话，先把一个能用的东西跑起来，比什么都重要。
1.3 技术栈选型：选自己半夜能爬起来改的
技术栈我选了 Python 的 FastAPI 做后端，前端用 Vue 3 加 Element Plus，数据库用 PostgreSQL，ORM 用 SQLAlchemy。选 FastAPI 而不是 Django，是因为 Django 自带的后台管理在这个场景下反而累赘，FastAPI 的自动接口文档对后续对接小程序和第三方工具特别方便。前端用 Vue 是因为生态成熟，Element 的表格和表单组件用来做业务系统效率极高。
这里我想给个很朴素的建议：选技术栈的标准不是“最流行”，而是“你半夜三点被叫起来改 bug 时，还能不能想起来代码写在哪”。团队里如果有更熟悉别的语言的成员，完全可以换，核心逻辑不受影响。DeskcommCRM 的架构核心在于业务模型，跟语言绑定很弱。
2. 数据模型设计：这块是整个系统的地基
2.1 核心表结构：客户、联系人、商机怎么关联
数据模型我前后改过四版，最后稳定下来的结构不复杂，总共七张核心表：用户表、角色表、客户表、联系人表、商机表、跟进记录表、待办任务表。客户和联系人是 1 对 N 关系，客户和商机是 1 对 N 关系，联系人和商机会通过中间表做关联，因为一个联系人可能同时出现在多个商机里。
CREATE TABLE customers ( id BIGSERIAL PRIMARY KEY, name VARCHAR(200) NOT NULL, status VARCHAR(20) NOT NULL DEFAULT 'active', level VARCHAR(20) NOT NULL DEFAULT 'new', owner_id BIGINT NOT NULL REFERENCES users(id), source VARCHAR(50), created_at TIMESTAMPTZ NOT NULL DEFAULT now(), updated_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE follow_ups ( id BIGSERIAL PRIMARY KEY, customer_id BIGINT NOT NULL REFERENCES customers(id), contact_id BIGINT REFERENCES contacts(id), deal_id BIGINT REFERENCES deals(id), user_id BIGINT NOT NULL REFERENCES users(id), action_type VARCHAR(20) NOT NULL, content TEXT, next_action VARCHAR(200), next_time TIMESTAMPTZ, created_at TIMESTAMPTZ NOT NULL DEFAULT now() );这里最关键的决定是把跟进记录做成了独立表，而不是在客户表上盖一个“最近联系时间”的字段。原因很实际：跟进记录是判断一个客户价值的最核心依据，它既要支持任意时间点的回溯，又要能跟商机、联系人、待办任务做关联。盖字段的做法会让历史信息全部丢失，等于把系统最重要的资产扔了。
每张表上都加了owner_id，这是数据权限的第一道关口。另外一个容易被忽略的点是：所有业务表我都加了created_at和updated_at，虽然多写几个字段，但排查问题时时间戳就是救命稻草。
2.2 字段设计上的实战调整：少用枚举，多用配置表
早期我在客户阶段字段上用了数据库枚举类型，比如new、contacted、negotiating、won、lost，后来业务说要在“新客户”和“洽谈中”之间加一个“已加微信”，我不得不跑一次迁移。改了几次以后我悟了：凡是业务会自己定义状态的字段，一律不要用数据库枚举，改成一张配置表或者前端字典维护。
CREATE TABLE deal_stages ( code VARCHAR(30) PRIMARY KEY, name VARCHAR(100) NOT NULL, sort_order INT NOT NULL, is_active BOOLEAN NOT NULL DEFAULT true );这么做的好处是业务调整阶段时，只需要改配置表，不需要发版。代价是代码里要多做一次字典缓存。我当时用了一个很简单的方案：服务启动时把配置表加载到内存，提供/api/dict/stages这样的接口给前端拉取，改动后重新加载即可。
这个设计在后期帮了大忙。销售总监有一天说要把“赢单”拆成“赢单待回款”和“已回款”两段，改配置、重新排序、刷新页面，十分钟搞定，全程没有动代码。
2.3 索引与查询优化：热数据要单独“喂饱”
客户列表和跟进清单是使用频率最高的页面，也是最容易出现“越用越慢”的地方。我的方案是给高频查询单独建索引，并且让索引针对真实的查询模式。比如客户列表页最常见的过滤条件是“我的客户 + 最近跟进时间倒序”，那就建一个(owner_id, updated_at DESC)的复合索引，而不是盲目给每个字段都加索引。
跟进记录表也一样，列表页频繁按customer_id和created_at查，复合索引(customer_id, created_at DESC)必不可少。建表的时候我特意测过，在 50 万行数据量下，有复合索引和无索引的查询耗时差了 80 倍，这个差距在销售天天点开的页面上是能直接感知到的。
我还做了一张专门的“客户摘要表”，用触发器或者定时任务把客户的核心统计信息（商机总额、最近跟进时间、下步计划）提前算好存进去。这样客户列表页只需要查一张表就能拿到所有展示数据，不用每次现算聚合，响应时间稳定在 100ms 以内。
3. 核心功能模块的落地细节
3.1 权限模型：数据隔离怎么做才不吵架
权限是 CRM 里最容易引发团队矛盾的点。DeskcommCRM 的权限模型分两层：功能权限和数据权限。功能权限走传统的 RBAC，角色有管理员、销售主管、销售人员、运营人员，对应菜单和按钮的增删改查权限。数据权限才是真正难搞的部分，我设计了三种可见范围：仅本人、本部门、全员。
实现方式不复杂，就是在查询层统一注入数据可见范围的条件。后端封装了一个叫ScopeFilter的模块，每个查询自动附带当前用户的可见范围条件。销售主管默认能看到本部门数据，但跨部门数据绝对看不到，这是用硬编码条件控制的，不是为了方便直接放开。
这里有一点我踩过坑：权限判断不能在多个接口里各写各的，必须统一走一个公共层。早期我在几个接口里手工写WHERE owner_id = current_user_id，后来客户列表、商机列表、待办列表的权限逻辑开始出现不一致，一个接口漏了条件就出现数据越权。统一封装以后，整个系统的权限逻辑只有一个入口，审查起来非常清晰。
3.2 待办与跟进管道：把“今天该联系谁”推到眼前
DeskcommCRM 最受销售欢迎的功能不是客户管理，而是首页的那份“今日待办”。它的逻辑很简单：所有跟进记录如果有next_time，并且小于当前时间，就自动汇总成一个待办清单，按紧急程度排序。加上 8 个小时没跟进的自动标红，销售只要打开系统就知道该干嘛。
待办的实现其实是一个视图加一次查询，不复杂，但体感极好。我特意把“完成跟进”的操作设计成在待办列表里直接展开表单，填完自动刷新，整个过程不到 30 秒。一个功能有没有人用，往往就差在这 30 秒上。如果点进去还要跳转三五个页面才能记完，销售很快就又会回到小本本上。
商机管道视图我做得比较克制，没有用什么花哨的拖拽看板，就是一个按阶段分列的表格。每列显示商机名称、金额、预计成交时间、最近跟进人，点进去看详情。柱子上的数字用聚合查询算出来，展示每个阶段的商机总金额。这个视图是销售主管开会时用得最多的，因为一眼能看出哪里有商机卡住不动了。
3.3 客户查重与合并：最容易忽略又最显价值的环节
客户资料重复是 CRM 系统的慢性病。销售录入客户时不会先去搜一遍有没有重复，于是“某某科技有限公司”在系统里出现三四份，跟进记录散落在不同重复客户下，报表看到的数据全是虚的。我在 DeskcommCRM 里做了一个“疑似重复”的检测机制：录入或编辑客户名称时，用相似度算法和现有客户比对，超过阈值就弹提示。
实现上我用的是 PostgreSQL 的pg_trgm扩展，对客户名称做三元组模糊匹配，再结合统一社会信用代码、官网域名做二次校验。
CREATE EXTENSION IF NOT EXISTS pg_trgm; CREATE INDEX ON customers USING gin (name gin_trgm_ops); SELECT id, name, similarity(name, '某某科技') AS sim FROM customers WHERE name % '某某科技' ORDER BY sim DESC LIMIT 10;查重只是第一步，更重要的是合并功能。合并时要以一个“主客户”为基准，把其他客户的联系人、商机、跟进记录全部迁移过来，然后删除重复客户。这个过程必须有事务包裹，一旦失败要能整体回滚，避免出现“跟记录过去了，客户没了”的尴尬情况。我在这里写了个迁移任务，每个关联表都做了移转记录，方便出问题时定位。
4. 实操实录：从零搭建的关键步骤
4.1 第一步：先把主流程走通，再做报表
我犯过不少项目都会犯的错：一上来先做客户列表和报表，结果跟进行为没人买单。做 DeskcommCRM 的第一阶段，我只交付了三件事：能录入客户、能记跟进、能生成明日待办。这三个功能串起来就形成了一个最小闭环，销售团队从第一天就能用起来，而不是等两个月以后看一个半成品。
这个阶段我把大量精力花在了“录入体验”上。客户名称输入框加了拼音首字母联想，联系人手机号加了格式校验，跟进表单里把常用的下次动作做成标签（微信、电话、见面、寄样），点击一下就填入。这些细节看着小，但是销售每天要录几十条，每省一秒都是提升。
同时我把 Excel 模板也做好了。老客户数据的导入，我是先用 Python 脚本把几十个账号的客户数据清洗、去重后再批量导入。清洗规则很简单：手机号去空格去横杠，企业名称去末尾的有限公司之类的后缀做统一。导入不是一次性工作，我把上传导入做成了功能，后续新来的销售可以直接自己导。
4.2 第二步：权限和历史追溯同步上线
主流程跑通以后，第二步不是加报表，而是上权限和历史记录。权限晚一步上的原因很简单：前期人少，大家互相都认识，可以先不管；等团队扩展到 10 个人以上，不设权限就会开始出问题。我印象最深的一次，是一个销售误删了另一个销售的跟进记录，虽然数据恢复了，但大家心里对系统产生不信任。
历史追溯我用了一张统一的操作日志表，记录谁在什么时间改了什么字段、旧值是什么、新值是什么。实现上用 SQLAlchemy 的事件钩子在每次更新后自动写入，不用在各个接口里手写日志。
@event.listens_for(Customer, 'after_update') def log_customer_update(mapper, connection, target): connection.execute( operation_logs.insert().values( table_name='customers', record_id=target.id, changed_fields=json.dumps(target._changed), operator_id=target._operator_id, created_at=func.now() ) )这套日志上线之后很像“全场的监控摄像头”，不是用来为难人，而是给所有人一个安全感：东西不会不明不白消失，谁改的都能追溯到。销售团队的配合度反而提高了，毕竟大家都怕背锅，有据可查反而踏实。
4.3 第三步：打通邮件和日历，让跟进有迹可循
销售日常跟进大量依赖邮件，但早期的 DeskcommCRM 和邮箱是分开的，跟进记录全靠手工填写，经常漏记。我后来做了一个轻量连接器：用 IMAP 协议轮询销售指定的跟进邮箱，把发给客户或客户发来的邮件主题、发件人、时间拉取下来，自动匹配到对应的客户下，生成一条跟进记录。
这个功能解决了“跟进记录总是记不全”的老大难问题。只要邮件有主题、有收件人，系统就能按域名匹配到客户。匹配不上的话就留在未关联邮件池里，销售可以手工拖拽关联。准确性不用做到 100%，能自动归集 80% 就已经省了大量体力活了。
日历打通用的是标准的 CalDAV 协议，把销售在系统里创建的下次联系时间同步到各自的公司日历，这样即使销售不打开 CRM，也能在日历上看到今天要联系谁。同步是单向的，CRM 是本尊，日历是投影，避免双向同步产生死循环。这一步做完，系统才真正嵌入了日常工作流，不再是“多一个要维护的系统”。
5. 常见问题与排查技巧实录
5.1 重复客户数据为什么越用越多
上线两个月后有个销售问我：为什么我一搜“某某网络科技”，能搜出五条几乎一样的客户？我排查了一下，问题出在查重提示被当成了摆设。弹窗提示“疑似重复”时，下面给了“仍然创建”和“查看相似”两个按钮，大部分人会图快直接点“仍然创建”。
解决办法不是强制拦截，而是让创建重复数据的成本变高。我把按钮改成了“我确认这是新客户”，默认选中查看相似，并把相似客户列表展示在创建表单旁边。改完以后重复产生率下降了七成。这个经验让我明白：系统设计只能引导，不能全靠强制，好的交互让正确操作变得顺手。
5.2 跟进记录丢失的排查过程
有段时间运营反馈：昨天的跟进记录今天看不到了。我查了数据库，记录确实存在，但客户列表页的最近跟进时间没有更新。再往下查，发现是更新客户表updated_at和插入跟进记录这两个操作之间没有做事务。记录插进去了，但更新客户表那步失败回滚了，导致客户列表页展示的“最近跟进时间”还是旧的。
这类问题的共同病根是跨表操作没有统一事务边界。我在跟进创建接口里把所有写操作包进同一个事务，并且加了一个数据库约束：跟进记录插入时间必须晚于客户当前最近跟进时间，否则报错。用数据库兜底，比在代码里小心保持顺序更可靠。从那以后没再出现过记录丢失或时间倒退的情况。
5.3 客户全景视图加载慢的优化
客户详情页我设计了一个“全景视图”，把客户的基本信息、所有联系人、所有商机、时间线、下步计划全部放在一个页面里。最初实现是前端依次调五个接口，每个接口查一遍数据库，导致页面转圈时间超过三秒。销售的耐心撑不住三秒，这个页面有段时间几乎没人看。
我改成了后端聚合一次完成：写一个get_customer_profile的接口，用一条查询把客户信息取出来，联系人、商机、待办分别走各自索引查询，然后用 JSON 一次性返回。这种“读多写少”的场景，牺牲一点灵活性换响应速度是完全值得的。优化以后这个接口稳定在 300ms 以内，页面秒开。
真正的经验是：这类问题的排查顺序要反着来。别一上来就怀疑 SQL 慢，先打开浏览器的网络面板看看发了多少个请求。大部分所谓“慢页面”，是请求数量太多而不是单条 SQL 太慢。
6. 复盘：如果让我重来一次
现在回头看 DeskcommCRM，我会在三个地方做得更好。第一，查重功能应该在第一版就做。我上线一个月以后才补上，导致系统里积累了近千条重复数据，清理成本比预防成本高得多。第二，权限模型最好在一开始就统一封装。前期的简陋实现虽然跑得快，但后期重构花的时间远超节省的时间。第三，应该更早让销售参与验收。我习惯把一个功能做完善了再给业务看，结果有两次方向理解偏差，等于白做了两周功能，这个教训很贵。
但也有几件事我做得还算聪明。用配置表代替枚举，让业务改流程完全不用发版；用操作日志给所有人建立安全感；邮件自动归集解决了跟进记录不全的老大难。这三个决策让 DeskcommCRM 没有在跑起来半年后变成一个新的“僵尸系统”。
如果你也在考虑给自己的团队做一套内部客户管理工具，我的建议很具体：先找到那个“今天该联系谁”的答案，其他所有功能都是这个核心的延伸。数据模型把客户、联系人、商机、跟进四个实体之间的关系理清楚，权限一开始就统一设计，查重导入这类基础功能尽量提前。把这四件事做好，这套系统就能在团队里活很久。
最后再分享一个个人体验：内部工具做成什么样，本质上是团队协作方式的一种确认。销售愿意每天打开的系统，靠的不是功能堆叠，而是它真的知道自己下一步该干什么。DeskcommCRM 能留下来，恰恰是因为它记住了这一点。
