DeskcommCRM这个词你在网上大概率搜不到太多公开资料因为它是我们内部一套一体化客户管理系统的项目代号。名字拆开其实已经把需求说清楚了Desk是坐席和销售每天盯着的那个工作台Comm是Communication的缩写指电话、邮件、IM这些客户沟通链路CRM则是最终要沉淀下来的客户关系资产。去年团队决定不再让客户资料散落在Excel、个人微信、话单文件和企业邮箱里我们基于这个思路从零把DeskcommCRM搭起来并推上了日常业务。这篇文章不打算写成产品手册我按从需求拆解、数据建模、部署接入到上线排障的顺序把整个项目里真正值得参考的东西摊开讲给想自建CRM或者正在做客服/销售一体化系统的团队一点实测经验。1. 项目到底是什么DeskcommCRM 要解决的三个核心问题1.1 Desk、Comm、CRM名字拆开就是需求清单DeskcommCRM最初不是高层拍脑袋定的方向而是我们花了两周时间盘点现状后倒推出来的目标。当时客服工单系统只能记邮件销售把客户信息存在各自的Excel和手机通讯录里通话录音只在呼叫中心平台保留三个月微信沟通记录完全没沉淀。客户问上个月你答应我的折扣为什么没生效时我们经常要翻五六个工具才能拼出答案。所以需求清单非常朴素在一个工作台里能看到客户是谁、之前聊过什么、目前的卡点在哪、下一步谁去跟进。Desk代表坐席界面要求操作快、切换少Comm代表通信链路自动落库不让一线人员手工补录电话记录CRM代表客户档案、工单、商机形成闭环而不是一张静态登记表。这个顺序也决定了我们的开发优先级通信先通档案后补流程最后转。我还记得第一次把原型界面拿给客服同事看时她的第一反应是这看起来没什么特别的。但当她看到一通呼入电话在挂断后自动出现在客户时间线里旁边还挂着录音和自动生成的通话小结时她的表情明显不一样了。这就是DeskcommCRM和传统CRM在体验上的区别好用的系统不需要提醒人去记录而是把人做过的动作在后台自动沉淀下来。整个项目过程中我反复用这条标准衡量每一个功能如果这个功能需要额外提醒一线人员去操作那它大概率会在真实业务中被跳过。所以后面所有设计包括数据模型、状态机、导入清洗流程都是围绕让沉淀自动发生让流程自然闭环这两个原则展开的。1.2 为什么选择自研而不是直接买现成SaaS关于为什么不自研的讨论当时团队内部也认真进行过。通用SaaS确实能快速覆盖客户管理、工单、报表这些常规功能但我们有几个硬条件直接排除了它。第一是通信链路要深度集成电话回调、邮件解析、IM机器人事件都要落到同一个客户时间线上SaaS的OpenAPI不一定覆盖这么细而且很多接口有配额限制第二是数据私有化要求通话录音、聊天记录和客户资料都属于敏感数据放在私有环境里才能统一做加密和审计第三是业务流程定制会越来越多售前、售后、投诉三条流程的状态机差异很大用SaaS的配置项一个个去凑成本并不比自研低。考虑到团队里有两位后端和一位前端可以牵头我们就决定用大约十周时间做一版核心功能把客户、沟通、工单、跟进四个模块先跑起来。对比维度通用 SaaS自研 DeskcommCRM定制灵活度有限受厂商配置模型约束高业务流程可随时调整数据私有化多数为多租户敏感字段受限数据在自己环境可统一加密审计通信集成深度依赖厂商开放接口和配额可深度对接电话、邮件、IM成本结构坐席年费长期偏高前期开发成本高后期边际成本低交付周期1-2周开通核心版本约10周适合团队无研发能力、业务标准化有研发、业务定制要求高不过这里我要给一个清醒的建议如果你们团队现在没有一位能独立改后端代码的工程师自研这个选项可以直接划掉。CRM的复杂不在页面交互而在数据一致性、权限边界和接口稳定性这些都需要有后端能力的人持续投入。我们当时的判断是即便算上后续两个月的迭代和维护自研成本仍低于在SaaS基础上做定制集成的隐性成本但这个结论只对开发能力还行的团队成立。1.3 整体架构不高大上但很稳的组合选型上我们没有追新。后端用Java 17加Spring Boot 3数据库用PostgreSQL 15前端是Vue 3加TypeScript文件对象存储用MinIO缓存和轻量消息用Redis。没有上微服务也没有引入Kafka因为在一个单体能扛住几千日活的内部系统里微服务和消息中间件带来的运维复杂度远大于收益。Redis Stream已经够做webhook事件的缓冲等到业务量撑到需要独立队列和异步海量处理时再抽出去单独部署一套中间件也不迟。下面是各模块的选型理由都写清楚了。模块选型理由后端Java 17 Spring Boot 3生态成熟事务、权限、定时任务方案齐全招人容易前端Vue 3 TypeScript Element Plus工作台类界面开发效率高组件覆盖度好数据库PostgreSQL 15JSON字段、全文检索、行级安全适合CRM缓存/消息Redis 7缓存热数据和webhook缓冲Stream机制够用对象存储MinIO兼容S3接口保存录音、邮件附件部署Docker Compose Nginx单机即可承载内部系统减少运维成本这套组合没有用到任何所谓前沿技术但有三点我一直觉得很重要。第一数据库尽量选PostgreSQL而不是MySQL因为CRM里经常要做模糊搜索、JSON过滤和行级权限PostgreSQL的pg_trgm全文检索和RLS能省掉很多应用层代码。第二附件类文件不要直接进数据库统一放MinIO数据库只存URL和MD5后续做备份和容量控制都方便。第三所有服务都容器化哪怕是个人开发环境也用Docker Compose起一套避免在我电脑上能跑的尴尬重复上演。1.4 核心用户与业务流程从客户进线到回款DeskcommCRM的用户角色不多但权限边界必须清晰。坐席负责接听电话、处理在线会话和维护沟通记录销售主管负责派单、查看团队统计和处理升级运营管理员负责流程配置、客户合并和导入导出财务和管理层只读报表。角色划分直接绑定后面的行级权限设计普通坐席只能看到自己名下的客户和工单主管能看到本部门管理员才有全局视图。从业务链路来看核心流程是这样的客户通过电话、邮件、IM或官网表单进来系统自动识别号码、邮箱或用户标识先做查重命中则直接弹出已有客户360视图未命中就自动创建客户档案坐席在统一工作台完成接待并把需求转成工单主管在工单池里指派给对应处理人销售跟进后把有购买意向的需求升级为商机最终赢单或输单原因和过程全部沉淀在系统里。这条链路看起来不复杂但真正跑顺之后团队不再需要问这个单现在卡在谁手里所有答案都写在工单状态和跟进记录里。2. 核心细节解析数据模型是 CRM 的灵魂2.1 客户与联系人两张表而不是一张大宽表在DeskcommCRM里客户和联系人从第一天起就是两张表。很多团队为了省事把客户名称、联系电话、联系人姓名全塞进一张宽表等业务跑起来就会发现问题一个公司客户有销售总监和采购专员两个联系人他们的决策角色完全不同宽表根本放不下联系人换了客户的基本信息也得跟着改字段相互污染。我们的做法是customer表管客户主体contact表管联系人一个客户可以挂多个联系人并且通过is_primary标记主要联系人。下面是简化后的建表语句CREATE TABLE customer ( id BIGSERIAL PRIMARY KEY, customer_no VARCHAR(32) UNIQUE NOT NULL, company_name VARCHAR(200), customer_type VARCHAR(20) NOT NULL DEFAULT company, -- company | person industry VARCHAR(50), source_channel VARCHAR(20), owner_id BIGINT NOT NULL, risk_status VARCHAR(20) DEFAULT normal, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), updated_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE contact ( id BIGSERIAL PRIMARY KEY, customer_id BIGINT NOT NULL REFERENCES customer(id), name VARCHAR(50) NOT NULL, mobile VARCHAR(30), email VARCHAR(120), role VARCHAR(50), is_primary BOOLEAN DEFAULT false, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE INDEX idx_contact_customer ON contact(customer_id); CREATE INDEX idx_contact_mobile ON contact(mobile); CREATE INDEX idx_contact_email ON contact(email);字段设计上还有几个容易忽略的点。customer_no建议用业务编号而不是直接暴露自增id否则客户容易被猜到规模或其他信息owner_id标记当前维护人客户离职转移时只需要改这个字段。索引方面contact表的mobile和email是最高频的查询条件必须建索引如果数据量超过百万email建议用小写表达式索引更稳。关于mobile是否唯一我们没有做数据库唯一约束因为真实业务里会出现同一个人在不同阶段被不同同事录入两次的情况因此这里只建普通索引用于查重而不是直接做唯一限制。2.2 沟通记录的统一抽象所有渠道都是同一类事件设计初期我们曾经想过给电话、邮件、IM各建一张表后来被统计需求劝退了。销售要一份这个客户最近30天的所有互动时间线如果分表就得写三套查询再合并而且各渠道字段还不一致排序会乱。最终我们把所有沟通统一成一张communication_log表channel字段区分来源关键内容统一用content_text和content_file_url承载录音、邮件原文、聊天截图都放对象存储数据库只存元数据。这背后的思路是不管客户是从哪个渠道路过每一次互动在CRM里都是一条不可变的事件记录只能追加不能篡改。表结构简化如下CREATE TABLE communication_log ( id BIGSERIAL PRIMARY KEY, conversation_id BIGINT NOT NULL REFERENCES conversation(id), external_msg_id VARCHAR(100) NOT NULL, channel VARCHAR(20) NOT NULL, -- phone | email | im | visit direction VARCHAR(10) NOT NULL, -- inbound | outbound summary VARCHAR(500), content_text TEXT, content_file_url VARCHAR(500), duration_seconds INT, staff_id BIGINT, started_at TIMESTAMPTZ NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), CONSTRAINT uq_comm_channel_msg UNIQUE (channel, external_msg_id) ); CREATE INDEX idx_comm_conversation_time ON communication_log(conversation_id, started_at DESC);这个唯一约束是整张表最重要的设计channel加external_msg_id唯一用来挡掉网关重试和重复回调。电话用呼叫平台的callId邮件用Message-IDIM用消息服务端的msgId这样不管事件来几遍数据库都只保留一条。实际操作中的经验是communication_log要有summary字段但不强制一线人员长篇大论。我们允许留空但系统会在电话结束后根据通话转写自动生成一句话摘要坐席确认或修改即可。千万不要把沟通记录设计成只能靠手工完成否则系统里的沟通记录会严重失真。2.3 工单与跟进任务状态机比自由文本更可靠工单是整个系统的行动核心。一开始我们用varchar存状态结果客服把状态写成了已处理、销售写处理中同一个意思三种写法统计口径完全对不上。后来直接改成数据库枚举类型并且加一张状态变更流水表记录每一步变更。只要你经历过一次客户投诉工单是怎么被关闭的这种追问就会明白审计留痕有多重要。工单相关表结构简化如下CREATE TYPE ticket_status AS ENUM ( NEW, ASSIGNED, PROCESSING, WAITING_CUSTOMER, RESOLVED, CLOSED, REOPENED ); CREATE TABLE ticket ( id BIGSERIAL PRIMARY KEY, ticket_no VARCHAR(32) UNIQUE NOT NULL, type VARCHAR(20) NOT NULL, -- pre_sale | after_sale | complaint priority VARCHAR(10) NOT NULL DEFAULT medium, status ticket_status NOT NULL DEFAULT NEW, customer_id BIGINT NOT NULL REFERENCES customer(id), contact_id BIGINT REFERENCES contact(id), owner_id BIGINT NOT NULL, team_id BIGINT NOT NULL, version INT NOT NULL DEFAULT 0, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), updated_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE ticket_event ( id BIGSERIAL PRIMARY KEY, ticket_id BIGINT NOT NULL REFERENCES ticket(id), from_status ticket_status, to_status ticket_status, operator_id BIGINT NOT NULL, remark TEXT, created_at TIMESTAMPTZ NOT NULL DEFAULT now() );工单表里的version字段是乐观锁后面并发问题排查会专门讲。ticket_event则类似数据库的binlog每一步状态变化都留下痕迹出现纠纷时能还原完整过程。状态机本身不复杂但要符合业务新建工单必须有人接主管指派后坐席开始处理如果中途需要客户补充资料就进WAITING_CUSTOMER防止SLA计时把等待时间也算进处理时长。我们还在这个基础上建了跟进任务表任务字段包括负责人、截止时间、状态每天早上自动扫描到期任务并推送待办解决跟进靠记性的典型问题。2.4 为什么核心主键选会话IDcommunication_log里的conversation_id是整个系统的关键外键。所谓会话是指同一客户、同一渠道、同一业务主题下的一系列沟通消息它可以是一通电话、一个邮件线程、一次IM会话也可以是一次线下拜访记录。我们的conversation表大概是这样的CREATE TABLE conversation ( id BIGSERIAL PRIMARY KEY, customer_id BIGINT NOT NULL, contact_id BIGINT, channel VARCHAR(20) NOT NULL, external_thread_id VARCHAR(100), status VARCHAR(20) DEFAULT open, last_message_at TIMESTAMPTZ, created_at TIMESTAMPTZ NOT NULL DEFAULT now() );为什么强调conversation_id而不是直接用customer_id做分组举个例子客户早上邮件问报价销售回复后又发了一封追问这两封邮件属于同一个会话但一周后客户换了个新问题来投诉就应该开新会话。如果所有沟通都挂在customer_id下时间线会混在一起业务上下文就丢了。用会话聚合之后客户360视图自上而下分成三层客户档案、会话线程、沟通事件每一层都有清晰粒度后面做智能摘要、关联工单甚至统计一次售后需要来回几轮消息都变得非常方便。我们后期只额外花了一天就实现了每个会话自动生成摘要的功能就是因为conversation已经自然聚好了消息。3. 实操过程把 DeskcommCRM 从零跑起来3.1 三步完成基础环境部署DeskcommCRM的部署没我们想象中复杂。最开始我想直接在一台生产服务器上逐个装PostgreSQL、Redis、MinIO后来想想维护成本还是主动加了Docker Compose。下面这份文件就是上线时用的基础环境前端和后端通过镜像单独编排这里只展示依赖服务version: 3.8 services: db: image: postgres:15-alpine environment: POSTGRES_DB: deskcomm POSTGRES_USER: deskcomm POSTGRES_PASSWORD: change_me volumes: - db_data:/var/lib/postgresql/data ports: - 5432:5432 healthcheck: test: [CMD, pg_isready, -U, deskcomm] interval: 10s timeout: 5s retries: 5 redis: image: redis:7-alpine ports: - 6379:6379 volumes: - redis_data:/data minio: image: minio/minio command: server /data --console-address :9001 environment: MINIO_ROOT_USER: deskcomm MINIO_ROOT_PASSWORD: change_me ports: - 9000:9000 - 9001:9001 volumes: - minio_data:/data volumes: db_data: redis_data: minio_data数据库初始化建议使用Flyway启动时自动执行版本化脚本把建表、枚举、初始数据全部纳入版本管理。Redis这里的角色主要是缓存热数据和转发webhook数据量不大不需要持久化配置太复杂。MinIO启动后要建bucket并设置权限为私有文件访问统一走应用层预签名URL不能直接开放匿名读。生产密码无论如何都要改成强密码最好通过环境变量注入不要写死在Compose文件里。整条部署链路我们控制在半小时以内从一台裸机到核心服务可用基本上是跑一条脚本的事情。3.2 接入通信链路先电话和邮件再接入 IM接入顺序我们反复讨论后定成了先电话再邮件最后IM。电话是最难但也最有价值的一环通话是实时发生的信息最容易丢只要电话能自动落库后面接入邮件和IM只是在重复同一套模式。我们用的是云呼叫中心坐席通过SIP软电话登录通话结束后平台会向webhook地址推送事件包含callId、主叫、被叫、开始时间、结束时间、录音地址。我们在回调里做两件事根据主叫号码反查客户没有就创建客户把通话信息写入communication_log并且用channel和external_msg_id的唯一约束兜底。这里贴一段处理逻辑的核心代码PostMapping(/webhook/phone) public ResponseEntityVoid handlePhoneCallback(RequestBody PhoneEvent event) { Long conversationId conversationResolver.resolveByCallId(event.getCallId()); CommunicationLog log new CommunicationLog(); log.setConversationId(conversationId); log.setExternalMsgId(event.getCallId()); log.setChannel(phone); log.setDirection(event.getDirection()); log.setStartedAt(event.getStartTime()); log.setDurationSeconds(event.getDurationSeconds()); try { communicationLogRepo.save(log); } catch (DuplicateKeyException ex) { // 平台重推或者网关重试直接忽略 log.warn(duplicated phone event ignored, callId{}, event.getCallId()); } return ResponseEntity.ok().build(); }这段代码的关键是try-catch重复键异常而不是先查再插。查了再插在高并发重试下仍可能重复数据库唯一约束才是真正的保险。收到回调后还要把录音文件拉到MinIO这一步是异步任务建议放进Redis Stream排队失败时允许重试录音文件名继续用callId关联方便出问题后核对。邮件接入比电话简单一些我们让每个坐席有一个系统专属邮箱通过IMAP拉取新邮件或者在邮件服务商的回调事件里接收通知。邮件天然有Message-ID所以幂等约束直接用邮件服务端消息ID。IM接入我们早期只接企业微信机器人事件回调里带MsgId同样走唯一约束不同IM平台的字段差异比较大建议在适配层统一转换后再落库不要在业务代码里散落各种平台字段名。3.3 配置销售跟进流程从工单到商机通信记录沉淀只是数据基础真正让业务跑起来的是工单和跟进任务的自动流转。我们一开始把状态变更后的动作写死在代码里结果销售主管每周都会提新需求这类工单关闭后要自动创建商机高优先级工单要自动生成4小时任务。写死逻辑根本响应不过来于是改成表驱动的自动化规则把触发事件、条件、动作都配置在automation_rule表里工单状态变化时由事件监听器执行规则这样新增规则不需要改代码。常见的规则包括工单类型为pre_sale且状态变为RESOLVED时自动创建商机归属当前处理人工单优先级为high时自动生成4小时内必须完成的跟进任务所有新增工单按类型生成对应SLA任务任务逾期自动置为overdue在主管工作台标红。CREATE TABLE automation_rule ( id BIGSERIAL PRIMARY KEY, trigger_event VARCHAR(50) NOT NULL, -- TICKET_STATUS_CHANGED condition_json JSONB NOT NULL, action_json JSONB NOT NULL, enabled BOOLEAN DEFAULT true, created_at TIMESTAMPTZ NOT NULL DEFAULT now() );后端处理逻辑很简单核心是事件监听和规则匹配解耦EventListener public void onTicketStatusChanged(TicketStatusChangedEvent event) { ListAutomationRule rules ruleRepo.findByTriggerAndEnabled(TICKET_STATUS_CHANGED); for (AutomationRule rule : rules) { if (rule.matches(event)) { automationExecutor.execute(rule, event); } } }这个设计最直接的收益是业务人员能自己配规则。我们上线后第一个月销售主管就通过后台界面自己加了一条投诉工单关闭后自动给客户发满意度问卷的规则没动一行代码。跟进任务我们独立建表字段包括assignee_id、due_at、status每天早上8点半由定时任务扫当天到期任务生成待办推送逾期任务会逐级上报到团队主管。这套机制上线后工单逾期率肉眼可见地降了下来原因不是大家变勤快了而是系统会定期提醒逾期还瞒不过主管。3.4 老客户数据迁移历史Excel和通话记录怎么清洗旧数据迁移是最容易被低估的工作。我们当时的存量不算大大概一万多个客户和三年通话记录但Excel的清洗仍然花掉了两周里将近四天。第一件事是去重同一个人被不同销售录了两次同一家公司简称和全称并存手机号有的带空格有的带86这些都得先处理。我们写了一个Python脚本做标准化手机号统一成E.164格式邮箱小写去空格公司名去掉括号差异然后按规则匹配出疑似重复客户生成人工确认清单。第二件事是重新分配归属离职员工的客户全部暂时转到主管名下后续再分批调整。第三件事是确定导入顺序先导客户再导联系人然后导沟通记录最后导未关闭的工单。这个顺序为什么不能乱因为沟通记录要挂在customer_id和conversation_id上工单又要挂在customer、contact上。如果先导沟通记录客户还没建外键根本落不进去如果先导工单联系人还没导进来相关负责人对不上。每次导入都建议开一个显式事务并且导入脚本支持断点续跑出错了能从失败批次重来不用从头再来。迁移完成后一定要抽样验证我一般按客户维度随机抽10%检查时间线顺序、客户字段完整性、录音链接是否能正常打开。抽到问题就回头修清洗脚本千万不要带着错误数据继续冲。4. 常见问题与排查技巧实录4.1 电话记录重复计入第一次压力测试时就发现一通电话在测试环境里被计了三次。查下来原因很直接云呼叫中心的webhook在超时后会重推Nginx层面也会对响应做重试而我们的处理逻辑是先查一遍库再插入恰好有一次查询发生在第一次提交之前两次插入都通过了。这个场景几乎在所有回调类系统里都会出现解决方式不是去调整网关重试次数而是在数据库层做唯一约束。我们后来在communication_log上加了channel和external_msg_id的唯一索引插入时用INSERT ON CONFLICT DO NOTHING效果立竿见影。INSERT INTO communication_log ( conversation_id, external_msg_id, channel, direction, content_file_url, started_at ) VALUES ( 123, call_abc_001, phone, inbound, http://minio/record/abc.mp3, now() ) ON CONFLICT (channel, external_msg_id) DO NOTHING;这里要记住唯一约束的列必须是网关真正稳定的消息标识不能是时间戳或手机号。时间戳同样的秒可能重复手机号一次通话可能产生呼入呼出两条都不能当唯一键。如果网关注册的事件里没有唯一的messageId在接入阶段就要先让网关方补上否则这个坑未来会反复踩。测试时也建议专门模拟一次同一条回调连续推三次确保库表始终只有一条记录这个用例应该写进回归测试。4.2 工单状态被并发更新覆盖运营过程中碰到最多的问题是两个人同时打开一个工单主管把状态从NEW改成ASSIGNED坐席同时把负责人改成自己并提交因为前端显示的都是旧版本后提交的人把先提交的覆盖掉了状态和负责人错乱。这是典型的丢失更新问题。我们没有引入复杂锁而是在ticket表加了version字段更新时带上version条件UPDATE ticket SET status PROCESSING, owner_id 1002, version version 1, updated_at now() WHERE id 123 AND version 4;如果影响行数是0就说明工单在打开期间被其他人改过前端弹出工单已被他人更新请刷新后重试而不是强行覆盖。所有状态更新提交后再往ticket_event写入一条变更记录记录操作人、前后状态和备注。这套方案虽然不是分布式锁那样复杂但对一个内部系统来说足够可靠也容易让前端同事理解。后来我们还在工单详情页做了一个很人性化的功能如果检测到工单是10秒内被两个人先后打开会显示当前有同事正在查看此工单从源头减少了并发编辑的频率。4.3 客户查重误伤率高客户查重如果做得太激进会把两个同名公司自动合并后果相当严重做得太松又会出现一堆重复档案。我们最终的设计是精确匹配和模糊匹配结合但合并动作一律交给人工。精确匹配针对手机号和邮箱命中即标记为高疑似公司名用PostgreSQL的pg_trgm扩展计算相似度比如CREATE EXTENSION IF NOT EXISTS pg_trgm; SELECT id, company_name, similarity(company_name, 某科技有限公司) AS sim FROM customer WHERE company_name % 某科技有限公司 ORDER BY sim DESC LIMIT 10;这个查询返回相似度超过阈值的候选列表阈值我们调了几轮最终定在0.4左右太高会漏掉简称太低会全是噪音。对命中的候选系统会给坐席弹提示已有相似客户请确认是否关联但绝不自动合并。合并功能本身要小心把备用客户的联系人、沟通记录、工单全部改到主客户ID下然后给备用客户打上merged标记而不是物理删除否则历史外键引用会断。操作前导出两份数据备份操作后人工抽查主要客户的360视图。这个小流程我们用了很久没有再出现误合并导致翻车的事故。4.4 会话突然丢失刚上线两周客服反馈有一通电话明明打完了客户时间线里看不到记录。排查这类问题我一般按一条链路往下走网关回调日志、应用webhook接收日志、Redis Stream消息、消费任务日志、数据库记录。大多数时候问题出在消费线程异常后没有正确记录failed状态。我们后来给所有webhook入口加了一个inbox表原始回调先原样落库并生成唯一接收ID再由消费者处理这样即使处理失败原始事件还在可以回放。inbox表看起来像这样CREATE TABLE webhook_inbox ( id BIGSERIAL PRIMARY KEY, source VARCHAR(50) NOT NULL, raw_payload JSONB NOT NULL, received_at TIMESTAMPTZ NOT NULL DEFAULT now(), processed BOOLEAN DEFAULT false, process_note TEXT, UNIQUE (source, raw_payload) );保留原始payload非常重要。有了它即使消费者逻辑写错了把这段事件重新消费一遍就能恢复。另外排查会话丢失时我建议先从最小粒度入手不用管页面为什么没显示直接查communication_log里有没有这一条数据。如果库里有但页面没有就是查询或接口问题如果库里都没有再向上游排查网关和inbox。按这个思路曾经半小时都定位不了的问题现在五分钟内能锁到具体环节。4.5 权限和越权问题怎么防DeskcommCRM的权限分两层功能权限控制能不能点这个按钮数据权限控制能看到哪些客户和工单。功能权限通过角色菜单配置数据权限则尽量下沉到数据库。PostgreSQL的行级安全RLS是一个好选择可以在不侵入业务代码的情况下限制查询范围。例如普通坐席在ticket表上只能看到自己创建或分配给自己的记录主管能看到本部门管理员不加限制。我们给后端数据访问层也加了同样的过滤条件做到双重保险。CREATE POLICY ticket_staff_select ON ticket FOR SELECT USING ( owner_id current_setting(app.current_user_id)::bigint OR EXISTS ( SELECT 1 FROM team_member WHERE user_id current_setting(app.current_user_id)::bigint AND team_id ticket.team_id ) );这里需要注意RLS使用要小心如果统计报表需要全量数据就不能简单套同一个策略需要单独给报表查询用管理员角色执行。我们早期因为所有接口共用同一个数据库账号RLS策略切换很头疼后来改为应用层设置app.current_user_id每个请求通过拦截器设置再配合只读账号跑报表问题才解决。上线前建议用不同角色账号做一轮越权测试尤其是列表接口和详情接口最容易出现列表拦了详情没拦的漏洞。最后再说一点个人的体会。DeskcommCRM上线半年让我印象最深的不是某个技术方案而是统一带来的复利销售不再问上个月那个客户聊了什么主管不再问这个工单为什么卡着客户资料和沟通记录终于成了一笔可持续复用的资产。技术层面确实没有太多新奇的东西但能把客户档案、沟通记录、工单闭环这三块底座做扎实已经能解决日常90%的协作问题。如果你们也在规划类似的系统我建议先别急着加报表、AI摘要、自动外呼这些亮点功能先把最基本的查重、幂等、权限、审计做对再谈其他。毕竟CRM的长期价值不在于界面炫不炫而在于数据准不准、流程断不断、责任清不清。
DeskcommCRM这个词你在网上大概率搜不到太多公开资料因为它是我们内部一套一体化客户管理系统的项目代号。名字拆开其实已经把需求说清楚了Desk是坐席和销售每天盯着的那个工作台Comm是Communication的缩写指电话、邮件、IM这些客户沟通链路CRM则是最终要沉淀下来的客户关系资产。去年团队决定不再让客户资料散落在Excel、个人微信、话单文件和企业邮箱里我们基于这个思路从零把DeskcommCRM搭起来并推上了日常业务。这篇文章不打算写成产品手册我按从需求拆解、数据建模、部署接入到上线排障的顺序把整个项目里真正值得参考的东西摊开讲给想自建CRM或者正在做客服/销售一体化系统的团队一点实测经验。1. 项目到底是什么DeskcommCRM 要解决的三个核心问题1.1 Desk、Comm、CRM名字拆开就是需求清单DeskcommCRM最初不是高层拍脑袋定的方向而是我们花了两周时间盘点现状后倒推出来的目标。当时客服工单系统只能记邮件销售把客户信息存在各自的Excel和手机通讯录里通话录音只在呼叫中心平台保留三个月微信沟通记录完全没沉淀。客户问上个月你答应我的折扣为什么没生效时我们经常要翻五六个工具才能拼出答案。所以需求清单非常朴素在一个工作台里能看到客户是谁、之前聊过什么、目前的卡点在哪、下一步谁去跟进。Desk代表坐席界面要求操作快、切换少Comm代表通信链路自动落库不让一线人员手工补录电话记录CRM代表客户档案、工单、商机形成闭环而不是一张静态登记表。这个顺序也决定了我们的开发优先级通信先通档案后补流程最后转。我还记得第一次把原型界面拿给客服同事看时她的第一反应是这看起来没什么特别的。但当她看到一通呼入电话在挂断后自动出现在客户时间线里旁边还挂着录音和自动生成的通话小结时她的表情明显不一样了。这就是DeskcommCRM和传统CRM在体验上的区别好用的系统不需要提醒人去记录而是把人做过的动作在后台自动沉淀下来。整个项目过程中我反复用这条标准衡量每一个功能如果这个功能需要额外提醒一线人员去操作那它大概率会在真实业务中被跳过。所以后面所有设计包括数据模型、状态机、导入清洗流程都是围绕让沉淀自动发生让流程自然闭环这两个原则展开的。1.2 为什么选择自研而不是直接买现成SaaS关于为什么不自研的讨论当时团队内部也认真进行过。通用SaaS确实能快速覆盖客户管理、工单、报表这些常规功能但我们有几个硬条件直接排除了它。第一是通信链路要深度集成电话回调、邮件解析、IM机器人事件都要落到同一个客户时间线上SaaS的OpenAPI不一定覆盖这么细而且很多接口有配额限制第二是数据私有化要求通话录音、聊天记录和客户资料都属于敏感数据放在私有环境里才能统一做加密和审计第三是业务流程定制会越来越多售前、售后、投诉三条流程的状态机差异很大用SaaS的配置项一个个去凑成本并不比自研低。考虑到团队里有两位后端和一位前端可以牵头我们就决定用大约十周时间做一版核心功能把客户、沟通、工单、跟进四个模块先跑起来。对比维度通用 SaaS自研 DeskcommCRM定制灵活度有限受厂商配置模型约束高业务流程可随时调整数据私有化多数为多租户敏感字段受限数据在自己环境可统一加密审计通信集成深度依赖厂商开放接口和配额可深度对接电话、邮件、IM成本结构坐席年费长期偏高前期开发成本高后期边际成本低交付周期1-2周开通核心版本约10周适合团队无研发能力、业务标准化有研发、业务定制要求高不过这里我要给一个清醒的建议如果你们团队现在没有一位能独立改后端代码的工程师自研这个选项可以直接划掉。CRM的复杂不在页面交互而在数据一致性、权限边界和接口稳定性这些都需要有后端能力的人持续投入。我们当时的判断是即便算上后续两个月的迭代和维护自研成本仍低于在SaaS基础上做定制集成的隐性成本但这个结论只对开发能力还行的团队成立。1.3 整体架构不高大上但很稳的组合选型上我们没有追新。后端用Java 17加Spring Boot 3数据库用PostgreSQL 15前端是Vue 3加TypeScript文件对象存储用MinIO缓存和轻量消息用Redis。没有上微服务也没有引入Kafka因为在一个单体能扛住几千日活的内部系统里微服务和消息中间件带来的运维复杂度远大于收益。Redis Stream已经够做webhook事件的缓冲等到业务量撑到需要独立队列和异步海量处理时再抽出去单独部署一套中间件也不迟。下面是各模块的选型理由都写清楚了。模块选型理由后端Java 17 Spring Boot 3生态成熟事务、权限、定时任务方案齐全招人容易前端Vue 3 TypeScript Element Plus工作台类界面开发效率高组件覆盖度好数据库PostgreSQL 15JSON字段、全文检索、行级安全适合CRM缓存/消息Redis 7缓存热数据和webhook缓冲Stream机制够用对象存储MinIO兼容S3接口保存录音、邮件附件部署Docker Compose Nginx单机即可承载内部系统减少运维成本这套组合没有用到任何所谓前沿技术但有三点我一直觉得很重要。第一数据库尽量选PostgreSQL而不是MySQL因为CRM里经常要做模糊搜索、JSON过滤和行级权限PostgreSQL的pg_trgm全文检索和RLS能省掉很多应用层代码。第二附件类文件不要直接进数据库统一放MinIO数据库只存URL和MD5后续做备份和容量控制都方便。第三所有服务都容器化哪怕是个人开发环境也用Docker Compose起一套避免在我电脑上能跑的尴尬重复上演。1.4 核心用户与业务流程从客户进线到回款DeskcommCRM的用户角色不多但权限边界必须清晰。坐席负责接听电话、处理在线会话和维护沟通记录销售主管负责派单、查看团队统计和处理升级运营管理员负责流程配置、客户合并和导入导出财务和管理层只读报表。角色划分直接绑定后面的行级权限设计普通坐席只能看到自己名下的客户和工单主管能看到本部门管理员才有全局视图。从业务链路来看核心流程是这样的客户通过电话、邮件、IM或官网表单进来系统自动识别号码、邮箱或用户标识先做查重命中则直接弹出已有客户360视图未命中就自动创建客户档案坐席在统一工作台完成接待并把需求转成工单主管在工单池里指派给对应处理人销售跟进后把有购买意向的需求升级为商机最终赢单或输单原因和过程全部沉淀在系统里。这条链路看起来不复杂但真正跑顺之后团队不再需要问这个单现在卡在谁手里所有答案都写在工单状态和跟进记录里。2. 核心细节解析数据模型是 CRM 的灵魂2.1 客户与联系人两张表而不是一张大宽表在DeskcommCRM里客户和联系人从第一天起就是两张表。很多团队为了省事把客户名称、联系电话、联系人姓名全塞进一张宽表等业务跑起来就会发现问题一个公司客户有销售总监和采购专员两个联系人他们的决策角色完全不同宽表根本放不下联系人换了客户的基本信息也得跟着改字段相互污染。我们的做法是customer表管客户主体contact表管联系人一个客户可以挂多个联系人并且通过is_primary标记主要联系人。下面是简化后的建表语句CREATE TABLE customer ( id BIGSERIAL PRIMARY KEY, customer_no VARCHAR(32) UNIQUE NOT NULL, company_name VARCHAR(200), customer_type VARCHAR(20) NOT NULL DEFAULT company, -- company | person industry VARCHAR(50), source_channel VARCHAR(20), owner_id BIGINT NOT NULL, risk_status VARCHAR(20) DEFAULT normal, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), updated_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE contact ( id BIGSERIAL PRIMARY KEY, customer_id BIGINT NOT NULL REFERENCES customer(id), name VARCHAR(50) NOT NULL, mobile VARCHAR(30), email VARCHAR(120), role VARCHAR(50), is_primary BOOLEAN DEFAULT false, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE INDEX idx_contact_customer ON contact(customer_id); CREATE INDEX idx_contact_mobile ON contact(mobile); CREATE INDEX idx_contact_email ON contact(email);字段设计上还有几个容易忽略的点。customer_no建议用业务编号而不是直接暴露自增id否则客户容易被猜到规模或其他信息owner_id标记当前维护人客户离职转移时只需要改这个字段。索引方面contact表的mobile和email是最高频的查询条件必须建索引如果数据量超过百万email建议用小写表达式索引更稳。关于mobile是否唯一我们没有做数据库唯一约束因为真实业务里会出现同一个人在不同阶段被不同同事录入两次的情况因此这里只建普通索引用于查重而不是直接做唯一限制。2.2 沟通记录的统一抽象所有渠道都是同一类事件设计初期我们曾经想过给电话、邮件、IM各建一张表后来被统计需求劝退了。销售要一份这个客户最近30天的所有互动时间线如果分表就得写三套查询再合并而且各渠道字段还不一致排序会乱。最终我们把所有沟通统一成一张communication_log表channel字段区分来源关键内容统一用content_text和content_file_url承载录音、邮件原文、聊天截图都放对象存储数据库只存元数据。这背后的思路是不管客户是从哪个渠道路过每一次互动在CRM里都是一条不可变的事件记录只能追加不能篡改。表结构简化如下CREATE TABLE communication_log ( id BIGSERIAL PRIMARY KEY, conversation_id BIGINT NOT NULL REFERENCES conversation(id), external_msg_id VARCHAR(100) NOT NULL, channel VARCHAR(20) NOT NULL, -- phone | email | im | visit direction VARCHAR(10) NOT NULL, -- inbound | outbound summary VARCHAR(500), content_text TEXT, content_file_url VARCHAR(500), duration_seconds INT, staff_id BIGINT, started_at TIMESTAMPTZ NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), CONSTRAINT uq_comm_channel_msg UNIQUE (channel, external_msg_id) ); CREATE INDEX idx_comm_conversation_time ON communication_log(conversation_id, started_at DESC);这个唯一约束是整张表最重要的设计channel加external_msg_id唯一用来挡掉网关重试和重复回调。电话用呼叫平台的callId邮件用Message-IDIM用消息服务端的msgId这样不管事件来几遍数据库都只保留一条。实际操作中的经验是communication_log要有summary字段但不强制一线人员长篇大论。我们允许留空但系统会在电话结束后根据通话转写自动生成一句话摘要坐席确认或修改即可。千万不要把沟通记录设计成只能靠手工完成否则系统里的沟通记录会严重失真。2.3 工单与跟进任务状态机比自由文本更可靠工单是整个系统的行动核心。一开始我们用varchar存状态结果客服把状态写成了已处理、销售写处理中同一个意思三种写法统计口径完全对不上。后来直接改成数据库枚举类型并且加一张状态变更流水表记录每一步变更。只要你经历过一次客户投诉工单是怎么被关闭的这种追问就会明白审计留痕有多重要。工单相关表结构简化如下CREATE TYPE ticket_status AS ENUM ( NEW, ASSIGNED, PROCESSING, WAITING_CUSTOMER, RESOLVED, CLOSED, REOPENED ); CREATE TABLE ticket ( id BIGSERIAL PRIMARY KEY, ticket_no VARCHAR(32) UNIQUE NOT NULL, type VARCHAR(20) NOT NULL, -- pre_sale | after_sale | complaint priority VARCHAR(10) NOT NULL DEFAULT medium, status ticket_status NOT NULL DEFAULT NEW, customer_id BIGINT NOT NULL REFERENCES customer(id), contact_id BIGINT REFERENCES contact(id), owner_id BIGINT NOT NULL, team_id BIGINT NOT NULL, version INT NOT NULL DEFAULT 0, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), updated_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE ticket_event ( id BIGSERIAL PRIMARY KEY, ticket_id BIGINT NOT NULL REFERENCES ticket(id), from_status ticket_status, to_status ticket_status, operator_id BIGINT NOT NULL, remark TEXT, created_at TIMESTAMPTZ NOT NULL DEFAULT now() );工单表里的version字段是乐观锁后面并发问题排查会专门讲。ticket_event则类似数据库的binlog每一步状态变化都留下痕迹出现纠纷时能还原完整过程。状态机本身不复杂但要符合业务新建工单必须有人接主管指派后坐席开始处理如果中途需要客户补充资料就进WAITING_CUSTOMER防止SLA计时把等待时间也算进处理时长。我们还在这个基础上建了跟进任务表任务字段包括负责人、截止时间、状态每天早上自动扫描到期任务并推送待办解决跟进靠记性的典型问题。2.4 为什么核心主键选会话IDcommunication_log里的conversation_id是整个系统的关键外键。所谓会话是指同一客户、同一渠道、同一业务主题下的一系列沟通消息它可以是一通电话、一个邮件线程、一次IM会话也可以是一次线下拜访记录。我们的conversation表大概是这样的CREATE TABLE conversation ( id BIGSERIAL PRIMARY KEY, customer_id BIGINT NOT NULL, contact_id BIGINT, channel VARCHAR(20) NOT NULL, external_thread_id VARCHAR(100), status VARCHAR(20) DEFAULT open, last_message_at TIMESTAMPTZ, created_at TIMESTAMPTZ NOT NULL DEFAULT now() );为什么强调conversation_id而不是直接用customer_id做分组举个例子客户早上邮件问报价销售回复后又发了一封追问这两封邮件属于同一个会话但一周后客户换了个新问题来投诉就应该开新会话。如果所有沟通都挂在customer_id下时间线会混在一起业务上下文就丢了。用会话聚合之后客户360视图自上而下分成三层客户档案、会话线程、沟通事件每一层都有清晰粒度后面做智能摘要、关联工单甚至统计一次售后需要来回几轮消息都变得非常方便。我们后期只额外花了一天就实现了每个会话自动生成摘要的功能就是因为conversation已经自然聚好了消息。3. 实操过程把 DeskcommCRM 从零跑起来3.1 三步完成基础环境部署DeskcommCRM的部署没我们想象中复杂。最开始我想直接在一台生产服务器上逐个装PostgreSQL、Redis、MinIO后来想想维护成本还是主动加了Docker Compose。下面这份文件就是上线时用的基础环境前端和后端通过镜像单独编排这里只展示依赖服务version: 3.8 services: db: image: postgres:15-alpine environment: POSTGRES_DB: deskcomm POSTGRES_USER: deskcomm POSTGRES_PASSWORD: change_me volumes: - db_data:/var/lib/postgresql/data ports: - 5432:5432 healthcheck: test: [CMD, pg_isready, -U, deskcomm] interval: 10s timeout: 5s retries: 5 redis: image: redis:7-alpine ports: - 6379:6379 volumes: - redis_data:/data minio: image: minio/minio command: server /data --console-address :9001 environment: MINIO_ROOT_USER: deskcomm MINIO_ROOT_PASSWORD: change_me ports: - 9000:9000 - 9001:9001 volumes: - minio_data:/data volumes: db_data: redis_data: minio_data数据库初始化建议使用Flyway启动时自动执行版本化脚本把建表、枚举、初始数据全部纳入版本管理。Redis这里的角色主要是缓存热数据和转发webhook数据量不大不需要持久化配置太复杂。MinIO启动后要建bucket并设置权限为私有文件访问统一走应用层预签名URL不能直接开放匿名读。生产密码无论如何都要改成强密码最好通过环境变量注入不要写死在Compose文件里。整条部署链路我们控制在半小时以内从一台裸机到核心服务可用基本上是跑一条脚本的事情。3.2 接入通信链路先电话和邮件再接入 IM接入顺序我们反复讨论后定成了先电话再邮件最后IM。电话是最难但也最有价值的一环通话是实时发生的信息最容易丢只要电话能自动落库后面接入邮件和IM只是在重复同一套模式。我们用的是云呼叫中心坐席通过SIP软电话登录通话结束后平台会向webhook地址推送事件包含callId、主叫、被叫、开始时间、结束时间、录音地址。我们在回调里做两件事根据主叫号码反查客户没有就创建客户把通话信息写入communication_log并且用channel和external_msg_id的唯一约束兜底。这里贴一段处理逻辑的核心代码PostMapping(/webhook/phone) public ResponseEntityVoid handlePhoneCallback(RequestBody PhoneEvent event) { Long conversationId conversationResolver.resolveByCallId(event.getCallId()); CommunicationLog log new CommunicationLog(); log.setConversationId(conversationId); log.setExternalMsgId(event.getCallId()); log.setChannel(phone); log.setDirection(event.getDirection()); log.setStartedAt(event.getStartTime()); log.setDurationSeconds(event.getDurationSeconds()); try { communicationLogRepo.save(log); } catch (DuplicateKeyException ex) { // 平台重推或者网关重试直接忽略 log.warn(duplicated phone event ignored, callId{}, event.getCallId()); } return ResponseEntity.ok().build(); }这段代码的关键是try-catch重复键异常而不是先查再插。查了再插在高并发重试下仍可能重复数据库唯一约束才是真正的保险。收到回调后还要把录音文件拉到MinIO这一步是异步任务建议放进Redis Stream排队失败时允许重试录音文件名继续用callId关联方便出问题后核对。邮件接入比电话简单一些我们让每个坐席有一个系统专属邮箱通过IMAP拉取新邮件或者在邮件服务商的回调事件里接收通知。邮件天然有Message-ID所以幂等约束直接用邮件服务端消息ID。IM接入我们早期只接企业微信机器人事件回调里带MsgId同样走唯一约束不同IM平台的字段差异比较大建议在适配层统一转换后再落库不要在业务代码里散落各种平台字段名。3.3 配置销售跟进流程从工单到商机通信记录沉淀只是数据基础真正让业务跑起来的是工单和跟进任务的自动流转。我们一开始把状态变更后的动作写死在代码里结果销售主管每周都会提新需求这类工单关闭后要自动创建商机高优先级工单要自动生成4小时任务。写死逻辑根本响应不过来于是改成表驱动的自动化规则把触发事件、条件、动作都配置在automation_rule表里工单状态变化时由事件监听器执行规则这样新增规则不需要改代码。常见的规则包括工单类型为pre_sale且状态变为RESOLVED时自动创建商机归属当前处理人工单优先级为high时自动生成4小时内必须完成的跟进任务所有新增工单按类型生成对应SLA任务任务逾期自动置为overdue在主管工作台标红。CREATE TABLE automation_rule ( id BIGSERIAL PRIMARY KEY, trigger_event VARCHAR(50) NOT NULL, -- TICKET_STATUS_CHANGED condition_json JSONB NOT NULL, action_json JSONB NOT NULL, enabled BOOLEAN DEFAULT true, created_at TIMESTAMPTZ NOT NULL DEFAULT now() );后端处理逻辑很简单核心是事件监听和规则匹配解耦EventListener public void onTicketStatusChanged(TicketStatusChangedEvent event) { ListAutomationRule rules ruleRepo.findByTriggerAndEnabled(TICKET_STATUS_CHANGED); for (AutomationRule rule : rules) { if (rule.matches(event)) { automationExecutor.execute(rule, event); } } }这个设计最直接的收益是业务人员能自己配规则。我们上线后第一个月销售主管就通过后台界面自己加了一条投诉工单关闭后自动给客户发满意度问卷的规则没动一行代码。跟进任务我们独立建表字段包括assignee_id、due_at、status每天早上8点半由定时任务扫当天到期任务生成待办推送逾期任务会逐级上报到团队主管。这套机制上线后工单逾期率肉眼可见地降了下来原因不是大家变勤快了而是系统会定期提醒逾期还瞒不过主管。3.4 老客户数据迁移历史Excel和通话记录怎么清洗旧数据迁移是最容易被低估的工作。我们当时的存量不算大大概一万多个客户和三年通话记录但Excel的清洗仍然花掉了两周里将近四天。第一件事是去重同一个人被不同销售录了两次同一家公司简称和全称并存手机号有的带空格有的带86这些都得先处理。我们写了一个Python脚本做标准化手机号统一成E.164格式邮箱小写去空格公司名去掉括号差异然后按规则匹配出疑似重复客户生成人工确认清单。第二件事是重新分配归属离职员工的客户全部暂时转到主管名下后续再分批调整。第三件事是确定导入顺序先导客户再导联系人然后导沟通记录最后导未关闭的工单。这个顺序为什么不能乱因为沟通记录要挂在customer_id和conversation_id上工单又要挂在customer、contact上。如果先导沟通记录客户还没建外键根本落不进去如果先导工单联系人还没导进来相关负责人对不上。每次导入都建议开一个显式事务并且导入脚本支持断点续跑出错了能从失败批次重来不用从头再来。迁移完成后一定要抽样验证我一般按客户维度随机抽10%检查时间线顺序、客户字段完整性、录音链接是否能正常打开。抽到问题就回头修清洗脚本千万不要带着错误数据继续冲。4. 常见问题与排查技巧实录4.1 电话记录重复计入第一次压力测试时就发现一通电话在测试环境里被计了三次。查下来原因很直接云呼叫中心的webhook在超时后会重推Nginx层面也会对响应做重试而我们的处理逻辑是先查一遍库再插入恰好有一次查询发生在第一次提交之前两次插入都通过了。这个场景几乎在所有回调类系统里都会出现解决方式不是去调整网关重试次数而是在数据库层做唯一约束。我们后来在communication_log上加了channel和external_msg_id的唯一索引插入时用INSERT ON CONFLICT DO NOTHING效果立竿见影。INSERT INTO communication_log ( conversation_id, external_msg_id, channel, direction, content_file_url, started_at ) VALUES ( 123, call_abc_001, phone, inbound, http://minio/record/abc.mp3, now() ) ON CONFLICT (channel, external_msg_id) DO NOTHING;这里要记住唯一约束的列必须是网关真正稳定的消息标识不能是时间戳或手机号。时间戳同样的秒可能重复手机号一次通话可能产生呼入呼出两条都不能当唯一键。如果网关注册的事件里没有唯一的messageId在接入阶段就要先让网关方补上否则这个坑未来会反复踩。测试时也建议专门模拟一次同一条回调连续推三次确保库表始终只有一条记录这个用例应该写进回归测试。4.2 工单状态被并发更新覆盖运营过程中碰到最多的问题是两个人同时打开一个工单主管把状态从NEW改成ASSIGNED坐席同时把负责人改成自己并提交因为前端显示的都是旧版本后提交的人把先提交的覆盖掉了状态和负责人错乱。这是典型的丢失更新问题。我们没有引入复杂锁而是在ticket表加了version字段更新时带上version条件UPDATE ticket SET status PROCESSING, owner_id 1002, version version 1, updated_at now() WHERE id 123 AND version 4;如果影响行数是0就说明工单在打开期间被其他人改过前端弹出工单已被他人更新请刷新后重试而不是强行覆盖。所有状态更新提交后再往ticket_event写入一条变更记录记录操作人、前后状态和备注。这套方案虽然不是分布式锁那样复杂但对一个内部系统来说足够可靠也容易让前端同事理解。后来我们还在工单详情页做了一个很人性化的功能如果检测到工单是10秒内被两个人先后打开会显示当前有同事正在查看此工单从源头减少了并发编辑的频率。4.3 客户查重误伤率高客户查重如果做得太激进会把两个同名公司自动合并后果相当严重做得太松又会出现一堆重复档案。我们最终的设计是精确匹配和模糊匹配结合但合并动作一律交给人工。精确匹配针对手机号和邮箱命中即标记为高疑似公司名用PostgreSQL的pg_trgm扩展计算相似度比如CREATE EXTENSION IF NOT EXISTS pg_trgm; SELECT id, company_name, similarity(company_name, 某科技有限公司) AS sim FROM customer WHERE company_name % 某科技有限公司 ORDER BY sim DESC LIMIT 10;这个查询返回相似度超过阈值的候选列表阈值我们调了几轮最终定在0.4左右太高会漏掉简称太低会全是噪音。对命中的候选系统会给坐席弹提示已有相似客户请确认是否关联但绝不自动合并。合并功能本身要小心把备用客户的联系人、沟通记录、工单全部改到主客户ID下然后给备用客户打上merged标记而不是物理删除否则历史外键引用会断。操作前导出两份数据备份操作后人工抽查主要客户的360视图。这个小流程我们用了很久没有再出现误合并导致翻车的事故。4.4 会话突然丢失刚上线两周客服反馈有一通电话明明打完了客户时间线里看不到记录。排查这类问题我一般按一条链路往下走网关回调日志、应用webhook接收日志、Redis Stream消息、消费任务日志、数据库记录。大多数时候问题出在消费线程异常后没有正确记录failed状态。我们后来给所有webhook入口加了一个inbox表原始回调先原样落库并生成唯一接收ID再由消费者处理这样即使处理失败原始事件还在可以回放。inbox表看起来像这样CREATE TABLE webhook_inbox ( id BIGSERIAL PRIMARY KEY, source VARCHAR(50) NOT NULL, raw_payload JSONB NOT NULL, received_at TIMESTAMPTZ NOT NULL DEFAULT now(), processed BOOLEAN DEFAULT false, process_note TEXT, UNIQUE (source, raw_payload) );保留原始payload非常重要。有了它即使消费者逻辑写错了把这段事件重新消费一遍就能恢复。另外排查会话丢失时我建议先从最小粒度入手不用管页面为什么没显示直接查communication_log里有没有这一条数据。如果库里有但页面没有就是查询或接口问题如果库里都没有再向上游排查网关和inbox。按这个思路曾经半小时都定位不了的问题现在五分钟内能锁到具体环节。4.5 权限和越权问题怎么防DeskcommCRM的权限分两层功能权限控制能不能点这个按钮数据权限控制能看到哪些客户和工单。功能权限通过角色菜单配置数据权限则尽量下沉到数据库。PostgreSQL的行级安全RLS是一个好选择可以在不侵入业务代码的情况下限制查询范围。例如普通坐席在ticket表上只能看到自己创建或分配给自己的记录主管能看到本部门管理员不加限制。我们给后端数据访问层也加了同样的过滤条件做到双重保险。CREATE POLICY ticket_staff_select ON ticket FOR SELECT USING ( owner_id current_setting(app.current_user_id)::bigint OR EXISTS ( SELECT 1 FROM team_member WHERE user_id current_setting(app.current_user_id)::bigint AND team_id ticket.team_id ) );这里需要注意RLS使用要小心如果统计报表需要全量数据就不能简单套同一个策略需要单独给报表查询用管理员角色执行。我们早期因为所有接口共用同一个数据库账号RLS策略切换很头疼后来改为应用层设置app.current_user_id每个请求通过拦截器设置再配合只读账号跑报表问题才解决。上线前建议用不同角色账号做一轮越权测试尤其是列表接口和详情接口最容易出现列表拦了详情没拦的漏洞。最后再说一点个人的体会。DeskcommCRM上线半年让我印象最深的不是某个技术方案而是统一带来的复利销售不再问上个月那个客户聊了什么主管不再问这个工单为什么卡着客户资料和沟通记录终于成了一笔可持续复用的资产。技术层面确实没有太多新奇的东西但能把客户档案、沟通记录、工单闭环这三块底座做扎实已经能解决日常90%的协作问题。如果你们也在规划类似的系统我建议先别急着加报表、AI摘要、自动外呼这些亮点功能先把最基本的查重、幂等、权限、审计做对再谈其他。毕竟CRM的长期价值不在于界面炫不炫而在于数据准不准、流程断不断、责任清不清。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
