从零自研CRM系统：用互动时间线解决客户信息碎片化难题

1. 为什么我会从零写一套叫 DeskcommCRM 的系统先交代一下背景。我之前所在的一家做企业服务的公司销售、客服、实施三个角色混在一起办公每天要切五六个窗口干活客户资料在Excel和旧CRM里电话记录在PBX后台邮件在个人邮箱微信和企微聊天记录要看手机工单系统又是另外一套。最典型的场景是销售在电话里答应客户我把上次的报价单再发你一遍挂了电话之后要翻三四个地方才能找到那份文件客户追问我们上周提的工单到哪一步了得先去工单系统查状态再去聊天记录里翻当时的对话截图。所以就有了 DeskcommCRM 这个项目。名字拆开看desk 是工位comm 是 communication核心就一个词把坐在这张工位上的人每天要处理的客户沟通全部收拢到一个工作台里。它不是那种大而全的 CRM 套件而是一套围绕客户沟通记录来组织的轻量级客户关系管理系统重点解决客户资料、通信记录、跟进任务、业绩归属这几件事之间的断层问题。这篇文章写给谁一类是准备自研系统、想少踩坑的技术负责人或全栈工程师另一类是有过 CRM 选型经验、对为什么通用 CRM 不好用有体感的业务负责人。我会把 DeskcommCRM 从产品定位、数据模型、通信集成、自动化设计到性能优化完整拆开讲不讲废话只讲我们实际做过的方案和踩过的坑。2. 产品定位先把客户的碎片化这个问题本身拆清楚2.1 一个客户信息被拆散以后的真实困境我当时做的第一件事不是写代码而是花了两周时间跟销售、客服、实施蹲在一起看他们每天怎么干活。结果发现问题不在工具数量多而在客户信息天然是碎片的这件事被所有工具放大了。一个客户从线索到成交通常要经历这些触点官网留资、销售电话、微信沟通、邮件往来、合同审批、售后工单。每一类触点都有对应的工具在记录但它们各自为政。客户在CRM里的档案可能只有公司名、联系人、电话、地址这些静态字段而真正有价值的动态信息——昨天电话里客户提到预算收紧、今天邮件里客户要求变更交期——全都散落在通话录音、邮箱、聊天记录里很难被检索、很难被关联。传统 CRM 做的往往是把静态资料管好而 DeskcommCRM 换了个思路以互动时间线为核心。任何一个客户点进去先看到他跟我们的全部交互记录时间从新到旧电话、邮件、IM、工单、会议全混排在这条时间线上。客户资料本身变成这条线的基础属性而不是系统的主角。2.2 传统 CRM 的四层断层才是真正要解决的东西我梳理了一下传统客户管理方式基本存在四层断层每一层都对应一类具体的业务痛点而不只是技术问题断层表现后果客户资料与沟通记录断层档案里有客户公司信息但电话录音和邮件躺在其他系统客户问起历史沟通细节没人能快速回答沟通记录与跟进任务断层电话打完、邮件发完没有自动产生下一步待办高意向客户被遗忘周期一长就流失跟进任务与结果归属断层谁跟进、跟进了几次、结果如何全部靠自觉填报表管理者看不到真实过程只能看最终签没签结果归属与决策分析断层成交了不知道为什么成丢单了不知道为什么丢团队经验无法沉淀只能靠老人传帮带每一层断层的修复成本是递增的但收益也是递增的。DeskcommCRM 的第一步先把第一层做透只要客户跟你发生过任何一次互动系统里就必须有一条带时间戳、带渠道、带内容摘要的记录。这一步做扎实了后面三层的自动化才有数据基础。2.3 DeskcommCRM 的边界不做什么比做什么更重要这个项目启动的时候我们内部也有过争论要不要做营销自动化要不要做客户画像和AI推荐最后全部砍掉了。原因很简单——小团队自研系统最怕的就是功能和销售型CRM看齐最后变成一个什么都做但什么都不好用的半成品。DeskcommCRM 明确只做四件事客户与联系人档案的统一管理全渠道通信记录的自动归集基于互动的任务自动生成与跟进闭环管理者视角的过程透视与基础报表。凡是超出这四件事的需求先不进核心版本。比如合同管理我们直接对接现有的财务系统数据分析报表先出一版最原始的明细导出等跑一段时间再说。这个取舍帮我省掉了至少一个月的开发量而且让团队对系统的使用成本保持在很低水位。3. 数据模型设计五个核心对象一条主线串起来3.1 五张核心表一张时间线视图DeskcommCRM 的数据模型没有走特别复杂的领域建模而是老老实实用了五张核心业务表外加一系列关联表和字典表。这五张表是accounts客户也就是公司级主体contacts联系人挂在客户下面一个客户可以有多个联系人opportunities商机代表一个潜在的销售机会tickets工单代表一个售后服务或问题处理流程interactions互动记录这是整个系统的灵魂所有渠道的沟通都沉淀在这里。其中 interactions 表是重中之重。一张标准的互动记录表大概长这样CREATE TABLE interactions ( id BIGSERIAL PRIMARY KEY, account_id BIGINT NOT NULL REFERENCES accounts(id), contact_id BIGINT REFERENCES contacts(id), opportunity_id BIGINT REFERENCES opportunities(id), ticket_id BIGINT REFERENCES tickets(id), channel VARCHAR(20) NOT NULL, -- call/email/im/ticket/meeting direction VARCHAR(10) NOT NULL, -- inbound/outbound happened_at TIMESTAMPTZ NOT NULL, summary TEXT, -- 自动生成或人工填写的内容摘要 payload JSONB NOT NULL DEFAULT {}, created_by BIGINT REFERENCES users(id), created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE INDEX idx_interactions_account_time ON interactions (account_id, happened_at DESC);字段里值得解释的是payload JSONB。一开始有同事问我为什么不用固定的列把通话时长、邮件主题、附件列表这些字段都存下来答案是不同渠道的元数据差异太大。一条通话记录需要 call_duration、recording_url、call_status一条邮件记录需要 message_id、in_reply_to、subject、attachments一条 IM 记录需要 msg_type、content_type。如果全部做成数据库列这张表很快就会变成一张几十列的大宽表而且大部分行的大多数字段都是空的。JSONB 的优势是灵活查询时也可以利用 GIN 索引做内部字段的条件过滤完全够用。3.2 互动时间线的查询设计时间线是 DeskcommCRM 最核心的页面性能要求很高。查询逻辑其实很简单选定一个客户按 happened_at 倒序取出最近的互动记录再按渠道类型渲染成不同的卡片。SELECT * FROM interactions WHERE account_id 123 ORDER BY happened_at DESC LIMIT 50;这条 SQL 看起来简单但一旦数据量上去很容易踩索引失效的坑。我们的表中account_id是外键happened_at是时间字段单独看都建了索引但组合查询时除非建立联合索引否则数据库只能先按 account_id 过滤再把结果排序数据多了就会慢。上面的联合索引(account_id, happened_at DESC)就是为了让这个查询直接走索引顺序扫描而不需要额外的 filesort。这条经验后来在性能优化章节还会展开讲。3.3 标签体系和客户分群除了互动记录客户标签也是系统里被高频使用的功能。销售习惯用高意向已报价待回访重点客户这类词来快速筛选客户。我们在 accounts 表上直接加了一个数组字段ALTER TABLE accounts ADD COLUMN tags TEXT[] NOT NULL DEFAULT {}; CREATE INDEX idx_accounts_tags ON accounts USING GIN (tags);PostgreSQL 的数组类型和 GIN 索引配合得非常好查询带有高意向标签的客户就是一句话的事SELECT * FROM accounts WHERE tags ARRAY[高意向];这个能力放在 MySQL 里要实现得费一番功夫而在 PostgreSQL 里就是原生的。这也是为什么我在项目启动时坚定选了 PostgreSQL 而不是 MySQL——后面节会详细说选型理由。3.4 为什么数据库用了 PostgreSQL 而不是 MySQL很多小团队默认选 MySQL因为生态熟悉、文档多。但在 DeskcommCRM 的场景里PostgreSQL 有三个实实在在的优势是我们需要的第一JSONB 的灵活性和索引能力。互动记录的 payload 字段需要存不同渠道的异构数据而且偶尔要根据里面的字段做查询统计。PostgreSQL 的 JSONB 支持 GIN 索引可以高效执行payload - call_duration这类查询。MySQL 8.0 虽然也支持 JSON 和索引但功能和性能都还差一截。第二数组类型天然适合标签和打标场景。本节的标签功能如果用 MySQL要么拆一张标签关联表要么用逗号分隔的字符串然后靠 LIKE 模糊匹配前者查询麻烦后者性能堪忧。PostgreSQL 的数组配合 GIN 索引方案非常优雅。第三CTE 递归查询。我们的组织架构是层级结构的查询某个销售总监下面所有团队成员负责的客户这类需求非常常见PostgreSQL 的WITH RECURSIVE一条 SQL 就能解决。换了 MySQL 8 虽然也支持递归 CTE但在更深层的复杂查询上PostgreSQL 还是稳得多。当然 PostgreSQL 也不是没有代价比如运维经验要求更高托管成本比云厂商的 RDS MySQL 稍贵。但考虑到这套系统的寿命至少三五年这些成本完全值得。4. 通信集成实战把电话、邮件、IM 拉进同一个时间线4.1 软电话集成WebRTC SIP 中继的低成本方案DeskcommCRM 最重的一块集成是电话。我们的目标很简单销售在系统里点一个号码就能发起呼叫通话结束后自动在互动时间线上生成一条通话记录。技术选型上我们没有自研整个 SIP 通信栈而是用了 WebRTC 对接运营商提供的 SIP 中继。大致架构是浏览器端通过 WebRTC 与 SBC会话边界控制器建立媒体通道信令走 SIP over WebSocket由运营商侧完成传统电话网的落地。这样省掉了自建媒体服务器的成本也规避了公网 IP 和 NAT 穿透的一大堆麻烦。客户端的核心状态机比较简单围绕一通电话的几个关键事件来驱动{ event: call.ringing, call_id: CALL-20241101-0001, agent_id: agent_001, direction: inbound, customer_phone: 13800138000, customer_name: 某科技公司-张总, timestamp: 2024-11-01T14:23:1008:00 }事件依次是 call.ringing、call.established、call.ended。前端收到事件后就更新通话状态、计时、录音地址后端在 call.ended 之后把整通电话的信息写入 interactions 表。这里有一个非常关键的细节一通电话最少会产生 5 类事件而且事件可能乱序、重复如果不对 call_id 做幂等处理一条通话会被重复写好几遍。我们的做法是在 interactions 表上加唯一约束(channel, external_id)external_id 就填运营商的 call_id写库时用INSERT ... ON CONFLICT DO NOTHING从根源上杜绝重复。4.2 通话数据落库后的自动摘要通话记录纯靠销售手动填摘要基本没人愿意做。我们当时做了一版半自动的摘要生成通话结束后系统会把通话时长、呼入呼出方向、对应客户名称这些结构化字段自动填好再抓取通话录音的转写文本来生成一个粗糙的内容摘要草稿销售只需要改一两句话就能保存。这里要提醒一句语音转写摘要的准确率不要太迷信尤其是行业术语多的电话内容转写结果往往是不可用级别。所以我在设计里把摘要定位成草稿绝不替代人工确认。核心目的只是帮助销售从敲三段字降到改一句话这样他们才不会觉得记录通话是负担。4.3 邮件收发与客户档案自动关联邮件集成比电话简单但关联逻辑更讲究。我们用 IMAP 收信、SMTP 发信把整个邮箱接入系统。每一封发出去的邮件都会带上一个自定义的Message-ID头回复邮件会通过In-Reply-To和References头串起整个邮件线程。自动归档到客户档案的匹配策略我们按优先级实现了四级如果收到的邮件In-Reply-To能对应到系统里某封已发送邮件直接用那封邮件关联的客户这最准确如果In-Reply-To匹配不到但发件人的邮箱地址在某个客户的联系人资料里存在按邮箱精确匹配如果邮箱匹配不到尝试在邮件主题里找业务编号比如报价单#SO-2024-0088就解析出商机号再关联上去以上都失败邮件会进入未关联收件箱由销售手动拖拽到对应客户下。这套四级匹配策略上线后邮件的自动关联率能做到 70% 左右。剩下 30% 是那些新客户首次发邮件、或者销售用个人邮箱跟客户沟通的情况。别小看这 70%在系统上线前这些邮件可能一封都不会出现在客户档案里。4.4 第三方 IM 的接入策略能拉就拉拉不了就剪贴板最难搞的是微信生态的聊天记录。企业微信有开放接口可以做会话内容存档但个人微信几乎没有合规的自动接入方式。我们当时的处理策略是三档方案企业微信客户通过企业微信 API 拉取会话存档自动归档到互动时间线这是最理想的钉钉、飞书同样走开放平台的会话存档能力个人微信不自动接入在系统里提供一个粘贴引文按钮销售复制聊天记录后一键粘贴系统自动提取时间、对方昵称、正文生成一条互动记录。很多团队希望在个人微信上打通所有聊天记录我认为这在合规和稳定性上都风险极大尤其涉及到客户隐私数据。与其冒着封号风险去折腾非官方接口不如退一步用人工粘帖的方式解决 80% 的记录问题。这里的原则是数据完整性的重要程度低于系统安全和合规的重要程度。5. 坐席工作台与自动化引擎让系统主动推着人走5.1 工作台的布局逻辑信息密度不是越高越好DeskcommCRM 的界面布局我前前后后改了三版。第一版参考了大型 SaaS CRM 的满屏密密麻麻的小组件结果团队试用评价是看一眼就头大。第二版把信息层级拆扁结果图标太多反而不认识。第三版才定稿采用了三段式的极简布局左侧客户列表可搜索、可筛选展示客户名称、最新互动时间和待办数量中间互动时间线与客户相关的所有记录按时间倒序排列右侧客户信息 待办任务 下一步建议。这个布局的逻辑是让用户一眼看到这个客户现在处于什么状态和我接下来应该为他做什么而不是强迫他浏览一堆历史信息。右侧的待办任务是由自动化引擎生成的系统认为客户需要被跟进、需要被回访、有工单超时了都会在这一栏给出明确动作。5.2 自动生成待办任务的规则引擎DeskcommCRM 的自动化引擎没做什么复杂的 AI 决策核心就是一个条件 动作的规则系统。规则用 JSON 存储后台可以可视化配置。最早期我们先内置了三条业务方最刚需的规则新客户分配后 24 小时内未产生任何互动记录自动给负责人生成首次跟进待办商机超过 7 天没有更新自动生成商机回访待办并标记为高优先级工单超过 48 小时没有内部响应自动给工单负责人生成催办待办同时抄送其主管。规则引擎的存储结构长这样{ name: 商机超7天未更新, trigger: { type: opportunity_updated, condition: { days_since_last_update: 7, status_not_in: [closed_won, closed_lost] } }, action: { type: create_task, assignee: owner, priority: high, due_in_days: 1 }, enabled: true, recursion_limit: 0 }规则引擎的判断逻辑是每次任何业务对象发生变化都会产生一个事件事件进入规则匹配器匹配器按顺序检查所有规则如果条件满足就执行对应的动作。执行动作时还会检查recursion_limit防止规则动作触发新事件、新事件再触发新规则的死循环。5.3 自动化引擎的踩坑循环触发和误通知这个规则引擎上线初期最大的事故就是循环触发。有一条规则是待办任务完成时如果商机超过 3 天没有更新则自动生成提醒任务。逻辑本身没问题但它触发的新任务在创建时会改变商机的updated_at字段这又触发了商机更新事件而事件又匹配到了另一条商机更新后生成回访任务的规则形成了一条无限循环链。好在我们当时设置了事件处理的最大深度才没有把数据库打爆。教训是**规则引擎里每一条规则都必须显式声明它监听的事件类型并且要设定递归深度限制。**更进一步的方案是引入事件溯源维护一张事件处理历史表同一个业务实体的同一类型事件 10 分钟内只允许触发生成任务一次用幂等来彻底堵死循环。这些坑在文档里看不到几乎都要靠实际运营才能暴露。5.4 权限体系RBAC 和数据范围要分开管权限设计在初期被我们严重低估了。第一个版本只做了角色权限判断谁能不能访问某个菜单结果上线后被业务方骂了一周——销售居然能看到全公司所有客户的详细信息这在我们公司的管理制度下是不可接受的。正确的做法是 RBAC角色权限和数据权限范围双维度控制。角色权限管的是能不能访问这个功能数据范围管的是能看哪些数据。数据范围分为三个层级本人只能看自己负责的客户和互动记录本组可以看整个小组的客户数据全部管理员和高管可以看全公司数据。开发上数据范围不能只靠前端隐藏列表字段来实现必须在后端查询里强制拼接数据可见范围的 SQL 条件。我们在每个业务查询的外层包了一层with_data_scope()函数根据当前登录用户的角色和部门动态生成条件片段。否则用户拼一个 URL 参数就能绕过权限看到全量数据这种漏洞在 CRM 里是致命的。6. 性能优化从 2.8 秒到 180 毫秒的一次完整排查6.1 问题现象客户列表页越来越慢系统上线后的第三周有销售反馈客户列表页打开要转圈好几秒。我们去看监控发现一个 SQL 的平均耗时已经高达 2.8 秒——就是那个最基础的查询当前用户负责的客户列表并按最近更新时间排序。看了执行计划慢的原因非常典型opportunities表上的查询走了owner_id的索引排除了大部分数据但排序字段updated_at没有索引于是 PostgreSQL 只能把筛选结果全部搬到内存里排序。随着客户量增长需要排序的数据越来越多性能直线下降。6.2 优化手段一联合索引覆盖排序第一版优化很简单直接加联合索引CREATE INDEX idx_opps_owner_status_time ON opportunities (owner_id, status, updated_at DESC);这个索引让数据库可以同时完成过滤和排序不需要额外的 filesort查询时间从 2.8 秒降到了 400 毫秒左右。注意我把status也放进了索引因为业务上列表页按默认条件只会查未关闭的商机这样过滤条件越精确索引的收益越大。6.3 优化手段二改成 keyset 分页400 毫秒其实已经能用了但销售滚动到列表底部翻页时又发现问题——每翻一页加载时间都会变长一截。这是典型的 offset 分页问题当 offset 到 10000 的时候数据库需要跳过 10000 行才能取出后面的数据整个过程都是 O(N) 的额外开销。我们把分页方案改成了 keyset 分页也叫游标分页。客户端不再传page和page_size而是传上一次查询结果里最后一条记录的(updated_at, id)作为游标服务端生成条件WHERE (owner_id :uid AND status NOT IN (closed_won, closed_lost)) AND (updated_at, id) (:last_updated_at, :last_id) ORDER BY updated_at DESC, id DESC LIMIT 20;改用游标分页后翻页深度不再影响查询性能任何一页的查询耗时都稳定在 200 毫秒以内实测平均约 180 毫秒。需要说明的是 keyset 分页有个代价无法显示总页数和跳转到第 N 页。但对销售日常使用来说这个代价完全可以接受用户更在意的是流畅度而不是精确的页码。6.4 实时推送选型WebSocket 直连加短轮询兜底工作台需要实时感知新的互动记录和待办任务最初的方案是前端每 30 秒轮询一次增量接口。数据量小的时候没问题但后来多人同时在线时轮询带来的数据库压力越来越大。我们评估过三个方案WebSocket 直连、SSEServer-Sent Events、以及 Redis Stream WebSocket 订阅。最终采用了WebSocket 直连 短轮询兜底的混合方案后端在互动记录写入后通过 Redis 发布一条事件每个 WebSocket 连接根据当前用户的订阅条件决定是否推送如果 WebSocket 断线或推送失败前端每 10 秒调用一次增量查询接口兜底弥补丢失的推送。这里要说一个经验**WebSocket 做实时通知很爽但必须设计好断线重连和消息补拉的逻辑。**否则用户切换网络或休眠唤醒后前端页面会处于看起来连着其实已经断了的假死状态所有实时更新全部丢失。兜底轮询虽然笨但它能保证数据最终一致。6.5 上线前的双写与对账验证为了确保 DeskcommCRM 上线时不丢数据、不出大岔子我们做了一个星期的影子运行新系统只读不写同时把旧系统里每天新增的客户、通话、工单数据实时同步到新库。每日跑一个对账脚本比较新旧系统里三个核心指标客户总数、互动记录数、待办完成率。对账的意义不只是发现同步 bug更重要的是让团队对新系统的数据质量建立信心。第一天的对账就发现了一个隐藏问题旧系统里 30% 的通话记录缺失了录音 URL因为旧系统的录音文件在一个月后被运营商自动清理了。我们因此紧急调整了录音转存策略把所有录音文件在通话结束后 24 小时内拉取到自己的对象存储。这个坑如果不是因为对账根本发现不了。6.6 真实反馈一线人员最认可的到底是什么DeskcommCRM 上线到现在团队反馈里最受欢迎的功能不是各种漂亮的数据报表也不是我们一度想做的 AI 客户画像而是两个看起来一点都不酷的东西全渠道互动时间线和自动生成的待办任务。销售原话是以前最怕客户问上次我们聊到哪了现在点开客户档案就知道。以前跟进这个客户完全靠记性现在系统到点就提醒我该打电话了。这个反馈让我反思了很久——对一个一线坐席来说减少切换工具的次数、不再靠脑子记事情这两个体验的提升价值远远大于花里胡哨的智能功能。7. 如果再让我做一次架构上会有哪些调整DeskcommCRM 做到现在有些决策我觉得是对的比如选 PostgreSQL、坚持 JSONB、砍掉多余功能。但也有一些地方如果再选一次我会调整。第一通信集成这件事应该放到更早期去推进。最初的版本我先把客户资料和商机管理做得很完整通信集成是第二批才上的。结果团队用第一批功能时还是觉得新 CRM 跟旧系统差异不大积极性不高。等到互动时间线和电话记录上线后使用率才真正冲上去。如果能重来我会先花两周时间把邮件接入和通话记录做成一个最小可用版本让用户第一眼就看到这是一个会说话的系统而不是又一个静态客户数据库。第二自动化规则引擎应该设计成更通用的事件处理管道。最初的三条业务规则虽然简洁但后续加规则时我们发现自己写的那套 JSON 规则引擎越来越难以覆盖多样的条件组合。如果重新设计我会基于事件驱动架构把规则的触发、条件判断、动作执行拆成独立的组件并引入延迟队列来支持某个条件持续满足 7 天后触发这类需要时间窗口判断的规则。这套改造我们后来花了两周才完成主要是重构了任务调度的逻辑。第三权限体系的数据范围设计应该在建模阶段就进入核心表结构。我们的数据权限是后期打补丁式地加到查询层虽然正确实现了但代码里散落着不少每次查询都要记得拼条件的隐患。正确的做法是在所有业务表里设计owner_id和team_id两个字段并把这套体系做进 ORM 的默认查询拦截器从框架层面杜绝遗漏。最后说说我的总体感受做一个 CRM 系统技术难度其实不高真正的难点在于理解业务人员每天面对的信息碎片化痛苦并且忍住什么都想做的冲动。DeskcommCRM 的价值不是因为它有什么革命性技术而是它把一件朴素的事做到了极致——让每一个坐在工位上的人花最少的时间搞清楚客户过去发生了什么、现在应该做什么。这个方向我认为比堆叠任何酷炫功能都重要。