做CRM系统这件事一开始我是拒绝的。市面上现成的产品一堆无论是付费的SaaS还是开源方案随手都能部署一套。但真正用起来总会遇到一些绕不过去的别扭——尤其是当你需要把客户沟通记录和业务数据串在一起看的时候那种割裂感特别明显。DeskcommCRM这个名字拆开就是Desk Communication最初的想法很简单做一个能把“桌面端的沟通动作”和“客户管理流程”绑在一起的系统。这篇文章我会把从需求梳理到落地部署的完整过程都拆开聊适合正在犹豫自研CRM、或者想给现有系统加入通信能力的团队参考。先把我这套系统的核心思路概括成三个关键词通信一体化、流程自动化、数据可追踪。通信一体化是把电话、消息、邮件这些桌面端最常发生的沟通动作统一收口到客户档案下流程自动化是让跟进提醒、回访任务、线索分配这些琐事不再靠人肉催数据可追踪则是让每一笔成交和每一张工单都能回溯到对应的沟通记录。这套思路不一定适合所有团队但如果你也面临类似的问题整个梳理过程和踩坑方法很值得借鉴。1. 项目缘起沟通与客户管理为何总在“分家”1.1 团队日常运营的三个痛点在动手写DeskcommCRM之前我先在自己的工作场景里做了两周的观察把团队日常运转中的问题列了一份清单。最终浮出来的痛点非常集中主要就是三个。第一个痛点是沟通工具和客户档案严重割裂。销售或者运营人员一天里大量时间花在IM、电话、邮件上但每切换一个工具就意味着客户的上下文断了一次。早上打电话聊完的客户下午想在CRM里补跟进记录往往要凭记忆复述漏掉关键信息是常态。时间一长客户曾经提过什么需求、承诺过什么时间全都埋在聊天记录里想翻都翻不出来。第二个痛点是跟进动作缺乏强制闭环。线索分配下去之后谁跟了、跟到哪一步、有没有超时未处理这些靠人盯基本盯不住。很多时候线索发下去就石沉大海等你想起来去问客户早跑别家去了。旧系统里虽然有“跟进记录”这个字段但录入全靠自觉不填也没有任何后果。第三个痛点是数据口径不统一。管理层想看一下这个月的转化率、平均响应时长结果销售用的是A表客服用的是B表两边对不上账。单个客户的历史脉络更是查不到——他是什么时候进来的、中间断联了多久、因为什么原因又激活了没有任何系统能给出完整答案。这些痛点不是买一套现成CRM就能解决的因为问题的根源在于“通信动作没有沉淀到业务数据里”。市面上的CRM更多是管结果不管过程。而这恰恰是我决定自研DeskcommCRM的直接原因我要的不是一个记录本而是一条从沟通发生到业务推进的完整链路。1.2 自研前的现成方案评估决定自研之前我花了一个周末把市面上的方案大概过了一遍。付费SaaS功能确实全但按坐席收费团队规模上来之后年费不低而且通信能力往往要额外接服务商数据还不在自己手里。开源方案部署方便但通病是前端偏重、定制成本高想把IM、通话记录和客户模块深度打通改动量不亚于重写。我也考虑过分阶段走先用现成系统跑业务同时开发DeskcommCRM做并行验证。后来想想这个方案太拖沓老系统数据迁移本身就是坑还不如一开始就锚定自研把核心模块边界划清楚至少不背历史包袱。最终打动我的还是可控性。通信能力通过服务商API接入CRM核心自己写两者之间用消息队列解耦。这样每一层都可以独立替换将来就算通信服务商涨价了或者IM换了供应商业务层不用动。这种“核心自主、外围开放”的架构思路是这次选型最关键的判断。1.3 核心需求清单我把需求拆成四个模块客户管理、通信集成、任务自动化、数据看板。每个模块下面的子项都列了优先级P0是必须做P1是尽量做P2是以后再做。客户管理模块的P0项包括客户档案公司联系人、标签体系、跟进记录、归属人变更。通信集成模块的P0项包括通话记录自动同步、IM消息存档、一键拨号和快速回复。任务自动化模块的P0项包括待办提醒、超时未跟进升级、线索分配规则。数据看板模块的P0项包括转化率漏斗、响应时长统计、成交客户画像。这里有个比较重要的决策P2里面我放了一个“客户评分预测”的功能但不打算一期做。原因很简单没有足够的真实业务数据喂给模型做出来的评分就是玄学。先跑两三个月把基础数据收集齐了再考虑上智能化才靠谱。做系统最忌讳一上来就搞花活核心链路没跑通之前一切华丽功能都是空中楼阁。这份需求清单全部整理完之后我心里大概有数了这是一个普通规模的Web应用技术难度不在某个单点而在于把通信、业务、自动化这三块在数据层面拧成一股绳。2. 系统整体设计模块划分与技术选型2.1 功能模块全景DeskcommCRM的功能模块划分我是按“端到端业务链路”来切的而不是按部门切。一个客户从线索进入系统到最终成交或者流失中间会经历分配、联系、跟进、转交、成交这几个阶段。每个阶段都有对应的功能模块去承接。一共有六个核心模块线索管理、客户管理、通信中心、任务引擎、数据报表、系统管理。线索管理负责公海池和线索分配客户管理维护公司、联系人的详细信息和标签通信中心是这次自研的重点聚合了通话、IM、邮件三种通信渠道的记录和操作入口任务引擎负责所有自动提醒和超时任务数据报表提供实时看板和导出能力系统管理管用户、角色、权限和操作日志。这里面最值得说一下的是通信中心和任务引擎的关系。通信中心不是简单地把通话记录存下来而是每一次沟通动作都会触发事件事件推送给任务引擎由任务引擎判断要不要生成新的待办。比如一通电话结束之后系统检测到通话时长大于3分钟且客户标签是“高意向”就自动生成一条“72小时内发送报价方案”的待办分配给通话的发起人。这种自动化的联动逻辑是DeskcommCRM区别于普通客户管理系统的核心所在。2.2 技术栈选择的考量技术选型上我本着“团队熟什么用什么不追新”的原则。后端选了Spring Boot 2.7理由很简单稳定、生态成熟、招人容易。前端用了Vue 3 Element Plus一个原因是Vue在国内资料多另一个原因是Element Plus的表单和表格组件做管理后台非常顺手能省不少UI开发时间。数据库这块我用了MySQL 8.0。为什么不用PostgreSQL说实话MySQL更熟悉团队排障效率高。Redis 6.x用来做缓存、分布式锁和待办队列。消息队列一开始纠结了很久最终选了RabbitMQ。原因有两个第一团队之前有RabbitMQ的生产经验运维上不虚第二RocketMQ虽然性能好但部署重对这样一个体量的系统来说有点杀鸡用牛刀。通信接入方面IM用的是WebSocket做的长连接通话则是通过服务商提供的SIP网关对接。这里要重点提醒一句如果你也要接通信服务商一定要提前确认他们有没有提供沙箱环境以及回调接口的鉴权方式。我在对接过程中发现有些服务商的文档写得含糊回调字段和网上示例对不上只能靠抓包实测。所以选服务商时技术支持响应速度甚至比价格更重要。核心技术栈清单层次选型说明后端框架Spring Boot 2.7稳定、生态好适合长期维护前端Vue 3 Element Plus后台管理场景效率高数据库MySQL 8.0核心业务数据存储缓存/队列Redis 6.x RabbitMQ缓存、锁、异步消息解耦通信接入WebSocket SIP网关IM长连接与电话语音通道部署Docker Compose单机多容器一键编排这里有一个踩过的坑想分享一下不要一上来就用微服务架构。DeskcommCRM这个体量单体应用绰绰有余。把模块边界在代码里划清楚比物理拆分成多个服务更实际。微服务带来的分布式事务、链路追踪、服务治理这些问题在团队规模不到一定级别时纯粹是给自己找麻烦。2.3 架构分层与数据流向整体架构我分成了三层接入层、业务层、数据层。接入层负责统一的API入口、鉴权和WebSocket长连接管理业务层拆成客户域、通信域、任务域、报表域四个逻辑域数据层就是MySQL、Redis和对象存储。对象存储用来存放IM图片、通话录音这些非结构化文件我没有单独搭FastDFS直接用云上的对象存储加CDN省心。数据流向是这套系统设计的核心。我画了一张数据流图用文字描述通信事件产生后接入层把原始数据写入入库队列业务层消费队列后做三件事——第一更新客户档案的最近联系时间和沟通摘要第二调用任务引擎判断是否生成待办第三把事件追加到客户的互动时间线。整个过程对用户是无感的销售只需要正常打电话、发消息系统在后台自动把该记的东西全记了。当初设计这个数据流的时候有一个反复斟酌的点通信记录入库到底是实时同步还是异步解耦。最终我选了异步因为通话记录和IM消息的量级跟普通业务数据不一样实时同步会拖垮主业务流程而且通信服务商偶尔会有回调延迟或者重试异步队列可以把这些不确定性挡在核心链路之外。实测下来从通话挂断到记录出现在客户档案里延迟大概在1秒以内完全够用。3. 数据库模型设计从客户档案到通信记录3.1 核心业务表结构数据库设计是整个DeskcommCRM能不能跑顺的地基。我在这里花了大量时间做字段级的设计因为后面所有功能都建立在数据模型之上一旦表结构要改牵一发而动全身。客户表是最核心的表我命名为customer关键字段包括id、company_name、industry、source、owner_id、status、score、created_at、updated_at。这里说明一下我把“联系人和公司”做了拆分company和contact两张表分开而不是把联系人字段直接塞进客户表。原因很简单一个公司会有多个联系人不分表就得冗余字段查起来极其别扭。source字段记录客户来源广告、转介绍、自然流量等status则是当前销售阶段。联系人表contact的字段包括id、customer_id、name、phone、email、wechat、position、is_primary。其中is_primary标记是否主要联系人在通信匹配时优先用主要联系人的电话号码去做关联。通信记录表communication是这套系统的灵魂字段包括id、customer_id、contact_id、channel_type、direction、content_summary、duration、record_url、occurred_at。channel_type区分call/message/emaildirection区分inbound/outbound。每次通信产生后系统都会尝试自动匹配customer_id和contact_id。匹配规则是优先匹配电话号码匹配不到就按邮箱再匹配不到就归到未关联会话等待人工认领。这里要特别提醒注意索引设计。communication表会持续增长不做好索引后面查起来全是慢查询。我的做法是建了一个联合索引(customer_id, occurred_at)以及一个单独索引(contact_id)。因为最常见的查询是“某个客户的全部历史沟通记录”这个联合索引能把扫描范围缩到最小。3.2 跟进记录与时间线设计跟进记录表follow_up和通信记录的关系我采用的是“双轨并行、统一汇总”的方案。跟进记录和通信记录物理上分两张表但对外展示时通过一个视图或者接口把它们合成一条时间线。这样设计的好处是两类数据的写入路径完全独立互不干扰但读的时候可以合并展示。follow_up表的关键字段有id、customer_id、content、next_plan、type、creator_id、created_at。type区分电话跟进、线下拜访、微信沟通、邮件往来等。next_plan字段是这次跟进之后计划的下一次动作这个字段非常有用后续可以自动转化成待办任务。时间线合并展示的时候我用了一个activity_type字段来区分事件类型。在返回前端的JSON里每一条记录都有统一的activity_type、occurred_at、summary、operator_name。前端拿到统一格式之后按时间倒序渲染就能呈现出一个非常清晰的客户互动全貌。这个设计虽然简单但实际用下来效果出奇地好老板和销售都爱看。客户360°时间线的事件类型枚举activity_type来源表展示摘要CALL_INcommunication客户呼入电话通话89秒CALL_OUTcommunication外呼联系客户无人接听IM_MSGcommunication微信回复确认产品细节EMAIL_SENTcommunication发送产品介绍和报价FOLLOW_UPfollow_up线下拜访沟通合作意向TAG_CHANGEDoperation_log标签修改高意向注意这里的时间线并不是只展示通信和跟进记录系统操作日志也会融合进来。比如销售修改了客户的行业分类、添加了标签、把客户转给了同事这些动作同样会出现在时间线上。这样做的好处是整个客户的生命周期在任何一个时间点上是什么状态后面的人都能看得到。3.3 标签体系与权限设计标签系统看起来简单但设计不好很容易变成摆设。DeskcommCRM的标签分了两类系统标签和自定义标签。系统标签是后端自动打的比如“30天未跟进”“高活跃”“疑似流失”由定时任务根据客户行为计算得出。自定义标签是销售和运营手动打的比如“价格敏感”“决策周期长”“有竞品”。权限设计这块我采用的是RBAC基于角色的访问控制加上数据范围控制。角色有超级管理员、部门经理、普通销售、客服专员。数据范围上普通销售只能看自己和协作客户的资料部门经理能看整个部门的数据超级管理员看全部。这个数据范围的过滤不是在SQL里到处加where条件而是在MyBatis的拦截器里统一处理传入当前用户的可见客户ID集合自动拼接到查询语句中。这个方案有一个显而易见的好处新来的开发不会因为忘了加数据权限条件导致越权访问漏洞。统一拦截的好处就是“安全默认”哪怕以后加了新的查询接口只要走了MyBatis的Mapper权限过滤就自动生效。4. 核心功能实战从通信接入到自动化提醒4.1 通信通道接入的实现细节通信接入是DeskcommCRM一期最麻烦的部分没有之一。要做好心理准备通信服务商提供的API和文档跟实际总有对不齐的地方这一块非常考验耐心。先讲通话接入。我选了一家常用的语音服务商他们提供SIP中继和HTTP回调两种方式。我采用的是“回调为主、API为辅”的方案通话开始时服务商推一个call_start事件通话结束时推一个call_end事件里面带有通话时长、录音文件地址、主叫号码、被叫号码。我的后端收到call_end事件后做号码匹配、生成通信记录、触发后续任务。这里有一个非常重要的设计细节回调接口必须是幂等的。通信服务商的回调机制是“重试直到收到成功响应”如果你在处理过程中出了异常服务商会隔几秒再推一次。如果回调处理逻辑没有做幂等校验一条通话记录就会入库两次甚至多次。我的解决办法是在communication表上建了一个unique_key字段用“服务商回调ID通话时间戳”做唯一索引。入库的时候先查这个唯一索引存在就直接返回否则才插入。这个坑我前后踩了两次第一次是没加索引第二次是加了索引但业务表里没判重就直接insert结果还是爆了唯一键冲突异常。最后在ORM层加了一个try-catch冲突时直接按已处理处理才彻底消停。IM接入相对直观一些。我直接用了WebSocket协议客户端通过一个SDK建立长连接收发消息都由服务端转发。每条IM消息经过服务端时都会额外做一次“关键词识别”如果消息中包含“价格”“合同”“报价”这类词就会给这条消息打一个intent标记同时追加到客户时间线。这个功能让销售在复盘的时候能快速定位到关键沟通节点不用一条条翻聊天记录。4.2 自动任务引擎的实现思路任务引擎是DeskcommCRM真正提升团队效率的地方。我的设计思路是“事件驱动、规则匹配、延迟触发”。事件驱动是指任何通信动作和业务字段变更都会产生一个领域事件。规则匹配是指任务引擎里配置了一系列规则每条规则包含触发条件和动作。延迟触发是指某些任务不是立即生成而是等到设定时间才进入待办列表。比如“客户3天未响应则触发短信提醒”这个规则是在上一通电话结束时就创建了一个延迟任务到了72小时后任务引擎检测到客户仍然没有新通话记录才会真正发起提醒。实现上我用的是RabbitMQ的延迟队列插件rabbitmq-delayed-message-exchange。每条延迟任务作为一个消息设置好延迟时间后投递到延迟交换机。时间一到消息进入业务队列消费端判断任务条件是否满足满足就生成待办不满足就丢弃。整个链路有一个好处不会因为应用重启导致延迟任务丢失因为消息是持久化的。参数配置上我把所有规则都放在数据库表rule_config里没有写死在代码中。管理员可以在后台动态调整阈值比如把“高意向判定”的通话时长从3分钟改成2分钟不用重新发布代码。当时这个设计多花了半天时间但后来越用越香。这里分享一个具体规则的实现参考——自动任务规则示例规则ID触发事件条件延迟时间动作R001CALL_END通话时长≥180秒客户标签含“高意向”立即生成“发送报价方案”待办R002FOLLOW_UP_CREATED跟进计划中next_plan非空按next_plan时间到期生成回访提醒R003LAST_CONTACT_OVERDUE30天无任何通信记录每天9点检查标记“疑似流失”标签R004LEAD_ASSIGNED新线索分配10分钟提醒销售首次接触R003这条规则解释一下它不是事件驱动而是定时任务。我用了Spring的Scheduled注解每天早上9点跑一次扫表把30天没有互动记录的活跃客户自动打上标签。这种周期型任务和事件型任务本质上是两种模式不能混在一起否则要么漏跑要么重复跑。4.3 数据看板的实现数据看板这部分我没有用专门的大数据组件就是基于MySQL的表做聚合查询。核心是两张聚合表daily_kpi每日核心指标和customer_funnel客户漏斗转化。daily_kpi表的字段包括stat_date、new_customer_count、active_communication_count、avg_response_time、conversion_rate。这里面的数据是每天凌晨由一个定时任务跑批生成的从明细表聚合汇总。前端展示的时候直接查聚合表毫秒级响应。customer_funnel表记录的是从线索到成交每个阶段的客户数和转化率。我用了漏斗图来展示但背后的实现并不复杂。每个客户在status字段上有不同的阶段值我按阶段写了一个CASE WHEN的SQL直接查出来各节点的人数再在Java里计算转化率。有一点心得想分享看板的指标定义一定在项目初期就统一好。什么叫“平均响应时长”是首次响应时长还是所有消息的平均回复间隔这个口径如果不统一技术写完了业务一句话说“这个数不对”你连辩驳的依据都没有。我们当时开了两轮会专门把每一个看板指标的计算公式写成了文档并且和业务确认签字。虽然流程上感觉有点重但这个文档后面成了排解指标争议的唯一依据。5. 部署优化与踩坑实录5.1 部署方案与参数调优部署方面我用的是Docker Compose一台8核16G的云服务器跑全套MySQL、Redis、RabbitMQ、后端应用、前端Nginx。这个配置对这个体量几百个客户、每天千把条通信记录来说完全够用。几个重要的配置参数我列一下MySQL的innodb_buffer_pool_size我设置为4Gmyisam_sort_buffer_size保持默认Redis的maxmemory设置为2G淘汰策略选了allkeys-lruRabbitMQ的vm_memory_high_watermark设置为0.6低于默认的0.4避免触发流控导致队列堵塞。这里说一个我真实踩过的坑。RabbitMQ的默认内存阈值是0.4生产环境跑了一阵子某天突然发现队列消费变慢了查了半天发现是RabbitMQ触发了flow control。原因是通信回调的消息量在高峰期突增内存飙升到了阈值broker主动限制了和客户端的连接。我把水线调到0.6之后问题解决了。这种问题不在压力测试的时候根本发现不了只有线上流量才能暴露。5.2 并发场景下的数据一致性问题通信回调的高并发场景下数据一致性是必须认真对待的问题。我当时遇到一个比较典型的场景同一通电话服务商既推送了call_start也推送了call_end但如果call_end先到而call_start还在队列里排队这时候处理call_end的逻辑就会发现没有对应的通话开始记录。最初的处理方式是直接丢弃这条call_end导致通话记录缺失。后来我把逻辑做了调整通信事件不依赖“前后置事件必须送达”的强顺序。call_end到达时即使找不到对应的start记录也会在通信表里直接创建一条完整记录只缺失start时间这个字段不影响整体业务。然后后台有一个补全任务每分钟扫描一次尝试用主叫号、被叫号、时间范围去匹配未关联的start记录匹配到就把start时间补上。这个方案虽然有一个极短的时间窗口内数据不完整但整体来看通信记录的完整性从95%提升到了99.9%。还有一个并发问题是客户的owner_id转交。销售A把客户转给销售B同时销售B正在给这个客户录入跟进记录这两个操作并发时有可能出现“跟进记录归属人和客户归属人不一致”的情况。我的解决方式是给customer表加了一个乐观锁版本号字段version更新归属人时检查版本号冲突则重试。虽然看起来有点老土但在这种轻量级并发场景下乐观锁比分布式锁更简单可靠。5.3 缓存策略与慢查询优化缓存的粒度问题我经过几次调整。最初我缓存了整个客户详情对象结果发现客户资料一旦有任何字段修改比如标签、备注整个缓存都要失效重刷成本太高。后来我改成“按字段族缓存”客户基础资料一个key沟通记录时间线一个key标签列表一个key。这样改一个字段只需要刷一小块缓存命中率也更高。慢查询方面communication表增长最快半年之后已经到了百万级。最典型的一个慢查询是“查询某个销售半年内所有通话记录并按客户维度统计通话次数”。没有合适索引时这个查询跑了8秒多。后来我把统计查询改成走daily_kpi聚合表明细表的查询严格控制到单个客户维度同时给communication表按月份做了分区。分区之后历史数据归档和清理也变得简单了——按月drop分区就行不需要跑delete。还有一个小优化是前端列表页的查询接口。原来的做法是查总数再查分页后来发现总数查询在大数据量下消耗大直接换成“查询下一页时查出N1条来判断是否还有更多”。这种方式省掉了一次count查询接口响应时间从900ms降到了300ms以内。6. 实操心得与复盘这套DeskcommCRM系统从需求梳理到上线运行我个人的体会是技术上没有用到什么高深的东西但要把通信、业务、数据串成一条顺畅的链路工程量远比自己预想的大。通信回调的异常、并发下的数据一致、指标口径的统一每一个单独看都不是难题真正难的是它们交织在一起时你得有一个非常清晰的数据模型作为支撑。如果让我重新做一遍我最可能在两点上做调整。第一更早地引入统一的数据字典管理很多字段的枚举值一开始散落在代码各处后期维护成本高第二通信接入的服务商要多备选一家因为一旦业务量上来单一服务商的不可用会直接影响整个系统的通信能力现在我已经在规划第二服务商的容灾切换方案。DeskcommCRM这个项目让我对自研系统的价值有了新的认识。现成工具解决的问题是“记录发生了什么”而一套贴合业务的系统能回答的是“接下来该做什么”。如果你也准备在客户管理方向做点自己的东西我建议你先别急着写代码把业务链路和数据模型想透这一半的功夫花下去后面能省你三倍的时间。最后再分享一个小经验这种中型系统最容易失败的地方不在技术在于做的时候没有明确回答“给谁用、解决什么问题”。只要不围着这两个问题打转系统就不会跑偏。
自研CRM系统实战：从通信一体化到流程自动化的完整落地指南
做CRM系统这件事一开始我是拒绝的。市面上现成的产品一堆无论是付费的SaaS还是开源方案随手都能部署一套。但真正用起来总会遇到一些绕不过去的别扭——尤其是当你需要把客户沟通记录和业务数据串在一起看的时候那种割裂感特别明显。DeskcommCRM这个名字拆开就是Desk Communication最初的想法很简单做一个能把“桌面端的沟通动作”和“客户管理流程”绑在一起的系统。这篇文章我会把从需求梳理到落地部署的完整过程都拆开聊适合正在犹豫自研CRM、或者想给现有系统加入通信能力的团队参考。先把我这套系统的核心思路概括成三个关键词通信一体化、流程自动化、数据可追踪。通信一体化是把电话、消息、邮件这些桌面端最常发生的沟通动作统一收口到客户档案下流程自动化是让跟进提醒、回访任务、线索分配这些琐事不再靠人肉催数据可追踪则是让每一笔成交和每一张工单都能回溯到对应的沟通记录。这套思路不一定适合所有团队但如果你也面临类似的问题整个梳理过程和踩坑方法很值得借鉴。1. 项目缘起沟通与客户管理为何总在“分家”1.1 团队日常运营的三个痛点在动手写DeskcommCRM之前我先在自己的工作场景里做了两周的观察把团队日常运转中的问题列了一份清单。最终浮出来的痛点非常集中主要就是三个。第一个痛点是沟通工具和客户档案严重割裂。销售或者运营人员一天里大量时间花在IM、电话、邮件上但每切换一个工具就意味着客户的上下文断了一次。早上打电话聊完的客户下午想在CRM里补跟进记录往往要凭记忆复述漏掉关键信息是常态。时间一长客户曾经提过什么需求、承诺过什么时间全都埋在聊天记录里想翻都翻不出来。第二个痛点是跟进动作缺乏强制闭环。线索分配下去之后谁跟了、跟到哪一步、有没有超时未处理这些靠人盯基本盯不住。很多时候线索发下去就石沉大海等你想起来去问客户早跑别家去了。旧系统里虽然有“跟进记录”这个字段但录入全靠自觉不填也没有任何后果。第三个痛点是数据口径不统一。管理层想看一下这个月的转化率、平均响应时长结果销售用的是A表客服用的是B表两边对不上账。单个客户的历史脉络更是查不到——他是什么时候进来的、中间断联了多久、因为什么原因又激活了没有任何系统能给出完整答案。这些痛点不是买一套现成CRM就能解决的因为问题的根源在于“通信动作没有沉淀到业务数据里”。市面上的CRM更多是管结果不管过程。而这恰恰是我决定自研DeskcommCRM的直接原因我要的不是一个记录本而是一条从沟通发生到业务推进的完整链路。1.2 自研前的现成方案评估决定自研之前我花了一个周末把市面上的方案大概过了一遍。付费SaaS功能确实全但按坐席收费团队规模上来之后年费不低而且通信能力往往要额外接服务商数据还不在自己手里。开源方案部署方便但通病是前端偏重、定制成本高想把IM、通话记录和客户模块深度打通改动量不亚于重写。我也考虑过分阶段走先用现成系统跑业务同时开发DeskcommCRM做并行验证。后来想想这个方案太拖沓老系统数据迁移本身就是坑还不如一开始就锚定自研把核心模块边界划清楚至少不背历史包袱。最终打动我的还是可控性。通信能力通过服务商API接入CRM核心自己写两者之间用消息队列解耦。这样每一层都可以独立替换将来就算通信服务商涨价了或者IM换了供应商业务层不用动。这种“核心自主、外围开放”的架构思路是这次选型最关键的判断。1.3 核心需求清单我把需求拆成四个模块客户管理、通信集成、任务自动化、数据看板。每个模块下面的子项都列了优先级P0是必须做P1是尽量做P2是以后再做。客户管理模块的P0项包括客户档案公司联系人、标签体系、跟进记录、归属人变更。通信集成模块的P0项包括通话记录自动同步、IM消息存档、一键拨号和快速回复。任务自动化模块的P0项包括待办提醒、超时未跟进升级、线索分配规则。数据看板模块的P0项包括转化率漏斗、响应时长统计、成交客户画像。这里有个比较重要的决策P2里面我放了一个“客户评分预测”的功能但不打算一期做。原因很简单没有足够的真实业务数据喂给模型做出来的评分就是玄学。先跑两三个月把基础数据收集齐了再考虑上智能化才靠谱。做系统最忌讳一上来就搞花活核心链路没跑通之前一切华丽功能都是空中楼阁。这份需求清单全部整理完之后我心里大概有数了这是一个普通规模的Web应用技术难度不在某个单点而在于把通信、业务、自动化这三块在数据层面拧成一股绳。2. 系统整体设计模块划分与技术选型2.1 功能模块全景DeskcommCRM的功能模块划分我是按“端到端业务链路”来切的而不是按部门切。一个客户从线索进入系统到最终成交或者流失中间会经历分配、联系、跟进、转交、成交这几个阶段。每个阶段都有对应的功能模块去承接。一共有六个核心模块线索管理、客户管理、通信中心、任务引擎、数据报表、系统管理。线索管理负责公海池和线索分配客户管理维护公司、联系人的详细信息和标签通信中心是这次自研的重点聚合了通话、IM、邮件三种通信渠道的记录和操作入口任务引擎负责所有自动提醒和超时任务数据报表提供实时看板和导出能力系统管理管用户、角色、权限和操作日志。这里面最值得说一下的是通信中心和任务引擎的关系。通信中心不是简单地把通话记录存下来而是每一次沟通动作都会触发事件事件推送给任务引擎由任务引擎判断要不要生成新的待办。比如一通电话结束之后系统检测到通话时长大于3分钟且客户标签是“高意向”就自动生成一条“72小时内发送报价方案”的待办分配给通话的发起人。这种自动化的联动逻辑是DeskcommCRM区别于普通客户管理系统的核心所在。2.2 技术栈选择的考量技术选型上我本着“团队熟什么用什么不追新”的原则。后端选了Spring Boot 2.7理由很简单稳定、生态成熟、招人容易。前端用了Vue 3 Element Plus一个原因是Vue在国内资料多另一个原因是Element Plus的表单和表格组件做管理后台非常顺手能省不少UI开发时间。数据库这块我用了MySQL 8.0。为什么不用PostgreSQL说实话MySQL更熟悉团队排障效率高。Redis 6.x用来做缓存、分布式锁和待办队列。消息队列一开始纠结了很久最终选了RabbitMQ。原因有两个第一团队之前有RabbitMQ的生产经验运维上不虚第二RocketMQ虽然性能好但部署重对这样一个体量的系统来说有点杀鸡用牛刀。通信接入方面IM用的是WebSocket做的长连接通话则是通过服务商提供的SIP网关对接。这里要重点提醒一句如果你也要接通信服务商一定要提前确认他们有没有提供沙箱环境以及回调接口的鉴权方式。我在对接过程中发现有些服务商的文档写得含糊回调字段和网上示例对不上只能靠抓包实测。所以选服务商时技术支持响应速度甚至比价格更重要。核心技术栈清单层次选型说明后端框架Spring Boot 2.7稳定、生态好适合长期维护前端Vue 3 Element Plus后台管理场景效率高数据库MySQL 8.0核心业务数据存储缓存/队列Redis 6.x RabbitMQ缓存、锁、异步消息解耦通信接入WebSocket SIP网关IM长连接与电话语音通道部署Docker Compose单机多容器一键编排这里有一个踩过的坑想分享一下不要一上来就用微服务架构。DeskcommCRM这个体量单体应用绰绰有余。把模块边界在代码里划清楚比物理拆分成多个服务更实际。微服务带来的分布式事务、链路追踪、服务治理这些问题在团队规模不到一定级别时纯粹是给自己找麻烦。2.3 架构分层与数据流向整体架构我分成了三层接入层、业务层、数据层。接入层负责统一的API入口、鉴权和WebSocket长连接管理业务层拆成客户域、通信域、任务域、报表域四个逻辑域数据层就是MySQL、Redis和对象存储。对象存储用来存放IM图片、通话录音这些非结构化文件我没有单独搭FastDFS直接用云上的对象存储加CDN省心。数据流向是这套系统设计的核心。我画了一张数据流图用文字描述通信事件产生后接入层把原始数据写入入库队列业务层消费队列后做三件事——第一更新客户档案的最近联系时间和沟通摘要第二调用任务引擎判断是否生成待办第三把事件追加到客户的互动时间线。整个过程对用户是无感的销售只需要正常打电话、发消息系统在后台自动把该记的东西全记了。当初设计这个数据流的时候有一个反复斟酌的点通信记录入库到底是实时同步还是异步解耦。最终我选了异步因为通话记录和IM消息的量级跟普通业务数据不一样实时同步会拖垮主业务流程而且通信服务商偶尔会有回调延迟或者重试异步队列可以把这些不确定性挡在核心链路之外。实测下来从通话挂断到记录出现在客户档案里延迟大概在1秒以内完全够用。3. 数据库模型设计从客户档案到通信记录3.1 核心业务表结构数据库设计是整个DeskcommCRM能不能跑顺的地基。我在这里花了大量时间做字段级的设计因为后面所有功能都建立在数据模型之上一旦表结构要改牵一发而动全身。客户表是最核心的表我命名为customer关键字段包括id、company_name、industry、source、owner_id、status、score、created_at、updated_at。这里说明一下我把“联系人和公司”做了拆分company和contact两张表分开而不是把联系人字段直接塞进客户表。原因很简单一个公司会有多个联系人不分表就得冗余字段查起来极其别扭。source字段记录客户来源广告、转介绍、自然流量等status则是当前销售阶段。联系人表contact的字段包括id、customer_id、name、phone、email、wechat、position、is_primary。其中is_primary标记是否主要联系人在通信匹配时优先用主要联系人的电话号码去做关联。通信记录表communication是这套系统的灵魂字段包括id、customer_id、contact_id、channel_type、direction、content_summary、duration、record_url、occurred_at。channel_type区分call/message/emaildirection区分inbound/outbound。每次通信产生后系统都会尝试自动匹配customer_id和contact_id。匹配规则是优先匹配电话号码匹配不到就按邮箱再匹配不到就归到未关联会话等待人工认领。这里要特别提醒注意索引设计。communication表会持续增长不做好索引后面查起来全是慢查询。我的做法是建了一个联合索引(customer_id, occurred_at)以及一个单独索引(contact_id)。因为最常见的查询是“某个客户的全部历史沟通记录”这个联合索引能把扫描范围缩到最小。3.2 跟进记录与时间线设计跟进记录表follow_up和通信记录的关系我采用的是“双轨并行、统一汇总”的方案。跟进记录和通信记录物理上分两张表但对外展示时通过一个视图或者接口把它们合成一条时间线。这样设计的好处是两类数据的写入路径完全独立互不干扰但读的时候可以合并展示。follow_up表的关键字段有id、customer_id、content、next_plan、type、creator_id、created_at。type区分电话跟进、线下拜访、微信沟通、邮件往来等。next_plan字段是这次跟进之后计划的下一次动作这个字段非常有用后续可以自动转化成待办任务。时间线合并展示的时候我用了一个activity_type字段来区分事件类型。在返回前端的JSON里每一条记录都有统一的activity_type、occurred_at、summary、operator_name。前端拿到统一格式之后按时间倒序渲染就能呈现出一个非常清晰的客户互动全貌。这个设计虽然简单但实际用下来效果出奇地好老板和销售都爱看。客户360°时间线的事件类型枚举activity_type来源表展示摘要CALL_INcommunication客户呼入电话通话89秒CALL_OUTcommunication外呼联系客户无人接听IM_MSGcommunication微信回复确认产品细节EMAIL_SENTcommunication发送产品介绍和报价FOLLOW_UPfollow_up线下拜访沟通合作意向TAG_CHANGEDoperation_log标签修改高意向注意这里的时间线并不是只展示通信和跟进记录系统操作日志也会融合进来。比如销售修改了客户的行业分类、添加了标签、把客户转给了同事这些动作同样会出现在时间线上。这样做的好处是整个客户的生命周期在任何一个时间点上是什么状态后面的人都能看得到。3.3 标签体系与权限设计标签系统看起来简单但设计不好很容易变成摆设。DeskcommCRM的标签分了两类系统标签和自定义标签。系统标签是后端自动打的比如“30天未跟进”“高活跃”“疑似流失”由定时任务根据客户行为计算得出。自定义标签是销售和运营手动打的比如“价格敏感”“决策周期长”“有竞品”。权限设计这块我采用的是RBAC基于角色的访问控制加上数据范围控制。角色有超级管理员、部门经理、普通销售、客服专员。数据范围上普通销售只能看自己和协作客户的资料部门经理能看整个部门的数据超级管理员看全部。这个数据范围的过滤不是在SQL里到处加where条件而是在MyBatis的拦截器里统一处理传入当前用户的可见客户ID集合自动拼接到查询语句中。这个方案有一个显而易见的好处新来的开发不会因为忘了加数据权限条件导致越权访问漏洞。统一拦截的好处就是“安全默认”哪怕以后加了新的查询接口只要走了MyBatis的Mapper权限过滤就自动生效。4. 核心功能实战从通信接入到自动化提醒4.1 通信通道接入的实现细节通信接入是DeskcommCRM一期最麻烦的部分没有之一。要做好心理准备通信服务商提供的API和文档跟实际总有对不齐的地方这一块非常考验耐心。先讲通话接入。我选了一家常用的语音服务商他们提供SIP中继和HTTP回调两种方式。我采用的是“回调为主、API为辅”的方案通话开始时服务商推一个call_start事件通话结束时推一个call_end事件里面带有通话时长、录音文件地址、主叫号码、被叫号码。我的后端收到call_end事件后做号码匹配、生成通信记录、触发后续任务。这里有一个非常重要的设计细节回调接口必须是幂等的。通信服务商的回调机制是“重试直到收到成功响应”如果你在处理过程中出了异常服务商会隔几秒再推一次。如果回调处理逻辑没有做幂等校验一条通话记录就会入库两次甚至多次。我的解决办法是在communication表上建了一个unique_key字段用“服务商回调ID通话时间戳”做唯一索引。入库的时候先查这个唯一索引存在就直接返回否则才插入。这个坑我前后踩了两次第一次是没加索引第二次是加了索引但业务表里没判重就直接insert结果还是爆了唯一键冲突异常。最后在ORM层加了一个try-catch冲突时直接按已处理处理才彻底消停。IM接入相对直观一些。我直接用了WebSocket协议客户端通过一个SDK建立长连接收发消息都由服务端转发。每条IM消息经过服务端时都会额外做一次“关键词识别”如果消息中包含“价格”“合同”“报价”这类词就会给这条消息打一个intent标记同时追加到客户时间线。这个功能让销售在复盘的时候能快速定位到关键沟通节点不用一条条翻聊天记录。4.2 自动任务引擎的实现思路任务引擎是DeskcommCRM真正提升团队效率的地方。我的设计思路是“事件驱动、规则匹配、延迟触发”。事件驱动是指任何通信动作和业务字段变更都会产生一个领域事件。规则匹配是指任务引擎里配置了一系列规则每条规则包含触发条件和动作。延迟触发是指某些任务不是立即生成而是等到设定时间才进入待办列表。比如“客户3天未响应则触发短信提醒”这个规则是在上一通电话结束时就创建了一个延迟任务到了72小时后任务引擎检测到客户仍然没有新通话记录才会真正发起提醒。实现上我用的是RabbitMQ的延迟队列插件rabbitmq-delayed-message-exchange。每条延迟任务作为一个消息设置好延迟时间后投递到延迟交换机。时间一到消息进入业务队列消费端判断任务条件是否满足满足就生成待办不满足就丢弃。整个链路有一个好处不会因为应用重启导致延迟任务丢失因为消息是持久化的。参数配置上我把所有规则都放在数据库表rule_config里没有写死在代码中。管理员可以在后台动态调整阈值比如把“高意向判定”的通话时长从3分钟改成2分钟不用重新发布代码。当时这个设计多花了半天时间但后来越用越香。这里分享一个具体规则的实现参考——自动任务规则示例规则ID触发事件条件延迟时间动作R001CALL_END通话时长≥180秒客户标签含“高意向”立即生成“发送报价方案”待办R002FOLLOW_UP_CREATED跟进计划中next_plan非空按next_plan时间到期生成回访提醒R003LAST_CONTACT_OVERDUE30天无任何通信记录每天9点检查标记“疑似流失”标签R004LEAD_ASSIGNED新线索分配10分钟提醒销售首次接触R003这条规则解释一下它不是事件驱动而是定时任务。我用了Spring的Scheduled注解每天早上9点跑一次扫表把30天没有互动记录的活跃客户自动打上标签。这种周期型任务和事件型任务本质上是两种模式不能混在一起否则要么漏跑要么重复跑。4.3 数据看板的实现数据看板这部分我没有用专门的大数据组件就是基于MySQL的表做聚合查询。核心是两张聚合表daily_kpi每日核心指标和customer_funnel客户漏斗转化。daily_kpi表的字段包括stat_date、new_customer_count、active_communication_count、avg_response_time、conversion_rate。这里面的数据是每天凌晨由一个定时任务跑批生成的从明细表聚合汇总。前端展示的时候直接查聚合表毫秒级响应。customer_funnel表记录的是从线索到成交每个阶段的客户数和转化率。我用了漏斗图来展示但背后的实现并不复杂。每个客户在status字段上有不同的阶段值我按阶段写了一个CASE WHEN的SQL直接查出来各节点的人数再在Java里计算转化率。有一点心得想分享看板的指标定义一定在项目初期就统一好。什么叫“平均响应时长”是首次响应时长还是所有消息的平均回复间隔这个口径如果不统一技术写完了业务一句话说“这个数不对”你连辩驳的依据都没有。我们当时开了两轮会专门把每一个看板指标的计算公式写成了文档并且和业务确认签字。虽然流程上感觉有点重但这个文档后面成了排解指标争议的唯一依据。5. 部署优化与踩坑实录5.1 部署方案与参数调优部署方面我用的是Docker Compose一台8核16G的云服务器跑全套MySQL、Redis、RabbitMQ、后端应用、前端Nginx。这个配置对这个体量几百个客户、每天千把条通信记录来说完全够用。几个重要的配置参数我列一下MySQL的innodb_buffer_pool_size我设置为4Gmyisam_sort_buffer_size保持默认Redis的maxmemory设置为2G淘汰策略选了allkeys-lruRabbitMQ的vm_memory_high_watermark设置为0.6低于默认的0.4避免触发流控导致队列堵塞。这里说一个我真实踩过的坑。RabbitMQ的默认内存阈值是0.4生产环境跑了一阵子某天突然发现队列消费变慢了查了半天发现是RabbitMQ触发了flow control。原因是通信回调的消息量在高峰期突增内存飙升到了阈值broker主动限制了和客户端的连接。我把水线调到0.6之后问题解决了。这种问题不在压力测试的时候根本发现不了只有线上流量才能暴露。5.2 并发场景下的数据一致性问题通信回调的高并发场景下数据一致性是必须认真对待的问题。我当时遇到一个比较典型的场景同一通电话服务商既推送了call_start也推送了call_end但如果call_end先到而call_start还在队列里排队这时候处理call_end的逻辑就会发现没有对应的通话开始记录。最初的处理方式是直接丢弃这条call_end导致通话记录缺失。后来我把逻辑做了调整通信事件不依赖“前后置事件必须送达”的强顺序。call_end到达时即使找不到对应的start记录也会在通信表里直接创建一条完整记录只缺失start时间这个字段不影响整体业务。然后后台有一个补全任务每分钟扫描一次尝试用主叫号、被叫号、时间范围去匹配未关联的start记录匹配到就把start时间补上。这个方案虽然有一个极短的时间窗口内数据不完整但整体来看通信记录的完整性从95%提升到了99.9%。还有一个并发问题是客户的owner_id转交。销售A把客户转给销售B同时销售B正在给这个客户录入跟进记录这两个操作并发时有可能出现“跟进记录归属人和客户归属人不一致”的情况。我的解决方式是给customer表加了一个乐观锁版本号字段version更新归属人时检查版本号冲突则重试。虽然看起来有点老土但在这种轻量级并发场景下乐观锁比分布式锁更简单可靠。5.3 缓存策略与慢查询优化缓存的粒度问题我经过几次调整。最初我缓存了整个客户详情对象结果发现客户资料一旦有任何字段修改比如标签、备注整个缓存都要失效重刷成本太高。后来我改成“按字段族缓存”客户基础资料一个key沟通记录时间线一个key标签列表一个key。这样改一个字段只需要刷一小块缓存命中率也更高。慢查询方面communication表增长最快半年之后已经到了百万级。最典型的一个慢查询是“查询某个销售半年内所有通话记录并按客户维度统计通话次数”。没有合适索引时这个查询跑了8秒多。后来我把统计查询改成走daily_kpi聚合表明细表的查询严格控制到单个客户维度同时给communication表按月份做了分区。分区之后历史数据归档和清理也变得简单了——按月drop分区就行不需要跑delete。还有一个小优化是前端列表页的查询接口。原来的做法是查总数再查分页后来发现总数查询在大数据量下消耗大直接换成“查询下一页时查出N1条来判断是否还有更多”。这种方式省掉了一次count查询接口响应时间从900ms降到了300ms以内。6. 实操心得与复盘这套DeskcommCRM系统从需求梳理到上线运行我个人的体会是技术上没有用到什么高深的东西但要把通信、业务、数据串成一条顺畅的链路工程量远比自己预想的大。通信回调的异常、并发下的数据一致、指标口径的统一每一个单独看都不是难题真正难的是它们交织在一起时你得有一个非常清晰的数据模型作为支撑。如果让我重新做一遍我最可能在两点上做调整。第一更早地引入统一的数据字典管理很多字段的枚举值一开始散落在代码各处后期维护成本高第二通信接入的服务商要多备选一家因为一旦业务量上来单一服务商的不可用会直接影响整个系统的通信能力现在我已经在规划第二服务商的容灾切换方案。DeskcommCRM这个项目让我对自研系统的价值有了新的认识。现成工具解决的问题是“记录发生了什么”而一套贴合业务的系统能回答的是“接下来该做什么”。如果你也准备在客户管理方向做点自己的东西我建议你先别急着写代码把业务链路和数据模型想透这一半的功夫花下去后面能省你三倍的时间。最后再分享一个小经验这种中型系统最容易失败的地方不在技术在于做的时候没有明确回答“给谁用、解决什么问题”。只要不围着这两个问题打转系统就不会跑偏。