1. 先想清楚DeskcommCRM到底解决什么问题DeskcommCRM这个名字字面上拆开就是Desk加Comm意思很直白坐在办公桌前面把日常沟通全部沉淀下来。我做完这套系统之后最大的感受是很多团队缺的根本不是CRM缺的是一个能让他们“少切窗口”的工作台。销售手里同时开着微信、企业邮箱、Excel表格和记事本客户信息散落得到处都是跟了三个月的客户换个人对接就得从头问一遍这种状态谈什么客户关系管理。DeskcommCRM是我给团队做的一套轻量级客户关系管理系统定位很明确围绕客户档案、沟通记录、工单跟进三个核心场景把销售和客服日常工作流串起来。和市面上动辄几十万、上百个字段的通用CRM不一样DeskcommCRM从一开始就只做几件事——客户档案统一管理、沟通记录全量留痕、工单进度实时同步、全局搜索一秒钟找到人。如果你现在面临的情况和我当时差不多比如销售团队用Excel管客户数据存在每个人电脑里离职带走一大半客服和销售的沟通记录散落在邮件、微信、电话里事后翻聊天记录翻到崩溃客户反馈的问题跟到一半就没有下文没人知道卡在哪个环节老板问起重点客户进展没人能当场说清楚那这篇博文里讲的思路和实现路径应该正好是你需要的。我会把DeskcommCRM从需求拆解、数据模型设计、核心代码实现到上线后的坑完整过一遍代码部分不是给你复制粘贴就完事更重要的是理解每一步为什么要这么做。先说一句掏心窝的话做内部系统最怕的不是需求复杂是需求说不清楚。DeskcommCRM之所以能做下去是因为我在动工之前先把边界画死了——什么功能必须做什么功能坚决不做都写进了设计文档。没有这一步后面所有代码都是给自己挖坑。1.1 市面上CRM一堆为什么还要自己搭我知道你现在想什么市面上一大堆现成CRMSalesforce、HubSpot、Pipedrive国内还有一堆SaaS产品为什么非要自己写一套这个问题的答案其实也是我最终决定动手的原因。第一个原因是数据打通和定制的成本。通用CRM的功能动辄几百个字段但真正用得上的就是那么十几个字段。可当你需要把CRM数据和自己的业务系统打通时SaaS产品往往受限于API的开放程度要么不支持要么收费高得离谱。比如我当时的场景是客户报修之后需要自动生成一个跟进工单并且把客户的历史沟通记录都带出来SaaS版的CRM做这种个性化联动要么很难配置要么得付额外费用。第二个原因是使用习惯。销售和客服团队对我强调的“一个页面解决全部操作”有非常强烈的偏好他们不想先打开CRM看客户信息再打开另一个系统建工单再切换邮箱写邮件。DeskcommCRM把客户信息和沟通动作放在同一个工作台里左边是客户列表中间是沟通记录时间线右边是待办工单这个布局在通用产品里很难定制自己做则完全可控。第三个原因更现实——成本。小团队用大平台CRM账号费用、定制开发费用、集成费用加起来一年下来往往够自己养一个小系统了。自己搭一套轻量的只要控制好边界总体成本其实更低而且数据完全在自己的掌控里。当然自己写的坏处我也得说清楚功能成熟度、稳定性、移动端体验都和成熟产品有差距。所以这事适合什么团队做团队规模不大、业务流程相对稳定、有一定技术能力、对数据打通有强需求。如果你的团队超过一两百人部门之间流程差异很大我建议还是老老实实选成熟产品二次开发的坑会让你怀疑人生。1.2 DeskcommCRM的核心能力边界设计和开发之前我把DeskcommCRM的能力边界写了明明白白一共就三个核心模块。客户档案模块统一的客户主数据管理包含基础信息、归属人、层级关系、标签体系和跟进状态。这个模块的核心价值是“一个客户只有一条记录”所有围绕客户的沟通、工单、合同信息都挂在这条记录下。沟通记录模块记录每一次与客户的互动包括电话、邮件、线上沟通。每条记录支持附件、标签和提及同事并且会在客户时间线上按时间排序展示。这个模块的核心价值是“所有沟通都有迹可循”。工单跟进模块把客户的请求、报修、投诉、需求变成可跟踪的工单有明确的处理人、优先级、截止时间和状态流转。工单和客户、沟通记录双向关联谁在处理、卡在哪个环节一目了然。这三个模块之外的东西我都不做像合同管理、回款管理、数据分析报表这类功能第一版统统砍掉。为什么因为每多一个模块数据模型复杂度会指数级上升开发周期和测试成本也跟着上去。小团队最需要的是把核心流程跑通而不是一开始就做一个什么都沾一点但什么都不好用的“大杂烩”。1.3 为什么强调“沟通记录”这件事DeskcommCRM和普通CRM最大的一个区别是把沟通记录放到了和客户档案同等的核心位置。我之前调研过团队的使用习惯发现一个很有意思的现象大部分CRM能把客户资料填得很完整电话、职务、公司规模全都有但问到这个客户最近聊了什么、上次沟通是什么时候就一片空白。原因很简单——人都是懒的如果录入沟通记录要多开一个表单、多填十个字段没人愿意填。所以在DeskcommCRM里沟通记录的交互被我简化到了极致默认有一条记录填写客户、时间、类型、内容就可以保存其他都是选填。技术上看起来没什么特别但这个设计决策直接决定了系统能不能用起来。我的原则是任何需要用户超过15秒才能完成的操作都会成为系统被弃用的理由所以能省则省。2. 业务模型与数据设计先把地基打在数据库里系统能跑多久不看前端多花哨看数据模型扎不扎实。DeskcommCRM的数据模型我大概推翻重构过两版第一版太复杂光是客户类型就设计了十几种结果前端开发和同事使用都懵了第二版砍掉了大量不必要的字段和关联才真正稳定下来。2.1 四张核心表客户、联系人、沟通记录、工单DeskcommCRM的核心数据库表只保留了四张customers客户、contacts联系人、interactions沟通记录、tickets工单。客户表存的是企业或者组织维度的信息字段控制在20个以内。我整理了必填字段客户名称、客户编号、行业、规模、来源渠道、归属销售、状态、创建时间。其余像网址、地址、备注这类非关键字段全放一个扩展字段JSON里去省得频繁改表结构。这样设计有个好处后期加个性化字段不跑SQL迁移改前端配置就行是内部工具保持灵活性的小妙招。联系人表是挂在客户下的子表一个客户可以维护多个联系人。每个联系人包含姓名、职位、电话、邮箱、微信以及是否为决策人的标志位。为什么要单独建表而不是直接塞在客户表里因为一个企业客户往往有多个联系人而且销售在跟进过程中真正说话算话的可能不是最初对接的那个人。把联系人独立出来后面做沟通记录关联时才不会搞混。沟通记录表是整个系统的命脉字段我设计得比较克制关联客户、关联联系人、沟通方式电话、邮件、线上沟通、面谈、沟通时间、内容、操作人、关联工单。沟通内容不搞富文本纯文本加多行就够一方面写起来快另一方面搜索也方便。工单表包含了工单编号、标题、描述、状态、优先级、客户、联系人、处理人、创建人、截止时间、解决时间、关联的沟通记录ID。工单的状态不是简单的“待处理/已处理”两种而是设计了一套具体状态机下一节细说。四张表的关联关系简单明了客户一对多联系人和工单沟通记录可以挂在客户下也可以挂到具体工单下。这样设计查询就很轻量客户详情页就是查一张客户表然后并行查联系人和沟通记录不用做一堆复杂的JOIN。2.2 工单状态机从创建到关闭的六种状态工单模块是DeskcommCRM里业务逻辑最重的地方而状态机设计是我最先确定的方案。工单状态如果随便定义后面做统计和权限控制的时候一定会哭。我最终定义了六个状态状态含义允许的操作open已创建待处理分配处理人、修改优先级assigned已分配处理人开始处理、重新分配in_progress处理中提交阶段性结果、挂起pending等待客户反馈补充信息、重新激活resolved已解决待确认客户确认关闭、重新打开closed已关闭重新打开需理由为什么需要六个状态而不是三个因为在一个真实的客户服务流程里卡住的地方往往不是“有没有在处理”而是“在等谁”。pending这个状态我是专门加进去的用来标明当前在等客户反馈。我发现很多团队的问题不是不干活是活干到一半不知道卡在谁那里加一个pending状态每天扫一眼就知道了。每个状态之间的流转不是随便跳的我在代码里用状态机定义好了合法转换路径。比如resolved状态不能直接跳到in_progress必须走closed或者reopen。第一次做这块时我没做校验结果运营在界面上乱点把工单状态改得一团糟后来老老实实加了状态转换校验情况立刻好转。技术实现上状态机我建议用一张配置表存合法转换关系而不是写死在代码里。虽然代码量多一点但好处是运营人员可以自己调整流程不用每次改状态规则都找你写代码这个弹性对内部系统来说特别重要。2.3 权限模型谁能看谁的客户权限设计是CRM最容易翻车的点。我一开始用的是粗粒度的角色权限就分管理员、销售、客服三种角色结果一上线就出了两个问题销售嫌客服能看到他的客户客服嫌销售能改他的工单。后来我调整成了“角色数据范围”双层模型。第一层是功能权限决定某个人能不能访问某个模块第二层是数据权限决定这个人能看哪些客户。数据范围我分成了四种本人、本部门、全部、指定共享。每个客户都可以单独设置共享给谁共享记录存在单独的customer_shares表里。这里踩过的一个坑是数据权限不能只在前端控制后端API也必须做同样的过滤。我当时前端把“共享客户”的入口藏掉了但后端接口没有加过滤结果懂点技术的同事直接调API把全公司的客户都拉出来了。后端接口的全量参数校验是权限系统的底线绝对不能省。DeskcommCRM的权限实现思路不算复杂核心就是每个查询都强制带一个可见客户ID列表。这个列表由角色和数据权限规则动态生成查询时直接IN条件过滤和业务查询本身解耦。数据量在百万级以下这么干完全没问题再大的量级就得考虑更细的权限剪枝方案了但内部系统一般用不到。3. 实操过程从零搭建DeskcommCRM的关键实现讲完了设计思路这一章开始聊具体实现。我不会贴所有代码系统全部代码量大概有两三万行贴出来你也不想看。我会把每个模块里最关键、最值得讲的部分挑出来讲清楚实现方案和取舍原因。3.1 建表SQL与核心索引设计数据库我用的PostgreSQL为什么不用MySQL个人习惯PostgreSQL的JSON字段支持、全文检索和约束机制都更顺手。建表时不光要定义字段类型索引设计同样重要没有索引的CRM表数据量到几万条之后查询就会慢到怀疑人生。客户表核心建表语句大致是这样的CREATE TABLE customers ( id BIGSERIAL PRIMARY KEY, customer_no VARCHAR(32) NOT NULL UNIQUE, name VARCHAR(128) NOT NULL, industry VARCHAR(64), source_channel VARCHAR(32), owner_id BIGINT NOT NULL REFERENCES users(id), status VARCHAR(16) DEFAULT active, extra JSONB DEFAULT {}, created_at TIMESTAMPTZ DEFAULT now(), updated_at TIMESTAMPTZ DEFAULT now() ); CREATE INDEX idx_customers_owner_status ON customers(owner_id, status); CREATE INDEX idx_customers_name_trgm ON customers USING gin (name gin_trgm_ops);owner_id和status的复合索引解决了“我名下有哪些客户”这个高频查询。客户名称的模糊搜索我用的是pg_trgm扩展这个方案比LIKE %keyword%性能好一个数量级是我实测过最稳的轻量搜索方案。联系方式去重用的是customer_no的唯一索引这个唯一约束后面会说怎么处理。沟通记录表是最容易膨胀的表索引设计更要上心。我建了两个索引一个是(interaction_type, interacted_at)用于按时间和类型筛选一个是(customer_id, interacted_at DESC)用于客户详情页的时间线查询。工单表核心是一个(customer_id, status)的复合索引还有一个处理人的索引用于统计个人负载。3.2 客户去重与合并最容易被低估的模块客户数据随着使用时间变长重复几乎是必然的。同一个客户被销售录了三次名字分别是“某某科技”、“某某科技有限公司”、“某某科技公司”这是我在DeskcommCRM上线第一周就遇到的事。数据一旦重复后面的沟通记录、工单就会跟着重复整个客户时间线就是乱的。去重我分成了两种录入时的实时检查和定期的批量合并。录入时的实时检查实现很简单当用户输入客户名称后前端请求一个接口搜索现有客户名称的相似记录返回可能重复的客户列表让用户确认。后端实现用的还是pg_trgm取相似度大于0.6的结果给用户一个选择要么打开已有客户要么强制创建新客户。这个机制可以拦住80%的低级重复。批量合并则要处理更复杂的情况两个重复客户都存在各自不同的联系人、沟通记录和工单。我的合并策略是指定一个主客户和一个副客户系统自动把副客户下的联系人、沟通记录、工单全部重新关联到主客户下然后对副客户打上merged标记保留一条记录防止历史数据变成孤儿。代码核心就是事务里做这几件事with db.transaction(): update_interactions(ticket_customer_idold_id, new_idnew_id) update_tickets(customer_idold_id, new_idnew_id) update_contacts(customer_idold_id, new_idnew_id) update_customer_status(old_id, merged, merged_intonew_id)关键点是必须在同一个事务里执行否则中途报错会出现一部分数据关联到新客户、另一部分还挂在旧客户下面的情况。我第一次做合并没加事务结果出现了十来个流浪工单光是修复就花了一下午。3.3 沟通记录如何与工单自动联动沟通记录和工单的联动是DeskcommCRM解决“信息割裂”的核心功能。客户打电话来报修客服在系统里创建工单工单编号自动生成这个过程中客服填写的沟通备注自动挂到工单下后续客户再联系时只要有工单号新沟通记录就能自动归到对应工单上。实现思路是这样的工单有一个不可见的关联键ticket_no沟通记录表里有一个可选字段ticket_id。当用户创建工单时前端把工单编号显示出来当用户新建沟通记录时如果内容里包含形如T-2024-0001这样的编号后端会解析出来自动把这条沟通记录和对应工单关联起来。这个设计比下拉选择框更符合实际操作习惯。客服每天要记大量备注让他们在输入内容的同时手动选择关联工单反而增加操作负担。利用工单编号的自动识别客服只需要在备注里写一句“客户回复T-2024-0001已收到”系统就自动关联了。这个交互细节上线后好评率非常高。自动关联逻辑的核心函数不复杂就是正则解析加一次数据库查询def extract_ticket_no(text): match re.search(rT-\d{4}-\d{4}, text) if match: ticket_no match.group(0) ticket Ticket.query.filter_by(ticket_noticket_no).first() if ticket: return ticket.id return None另外一个正向联动是当工单状态从resolved变成closed时系统会自动给客户发送一条短信或邮件通知客户问题已解决。这个通知内容模板可以在后台配置目前内置了几条常见模板。做这个功能的原因很简单——很多客户反馈“问题解决了我都不知道”主动同步状态能明显提升客户满意度。3.4 客户时间线页面所有信息一屏呈现客户详情页是整个系统里用得最多的页面也是我调整次数最多的页面。最初的设计是客户基本信息在上面下面分Tab分别展示联系人、沟通记录、工单结果用户反馈说切换Tab太麻烦看不到全局。后来我改成时间线模式客户基础信息卡固定在上方下面按时间倒序统一展示所有沟通记录和工单动态一条接一条。时间线页面的查询逻辑有点讲究。如果前端发三个请求去查联系人、沟通记录、工单再在浏览器端合并排序数据量稍微大一点就会卡。更合理的做法是后端一次查询出来并合并好前端只负责渲染timeline [] for interaction in get_interactions(customer_id): timeline.append({ type: interaction, date: interaction.interacted_at, title: interaction.subject, content: interaction.content }) for ticket in get_tickets(customer_id): timeline.append({ type: ticket, date: ticket.created_at, title: f工单 {ticket.ticket_no}, content: ticket.title, status: ticket.status }) timeline.sort(keylambda x: x[date], reverseTrue)这个方案在客户数据量几千条的级别运行得很流畅。如果以后客户量到十万级时间线查询可能会慢到时候可以改为游标分页不过当前阶段没有优化的必要。做系统就是这样选一个合适当前规模的方案别提前过度设计。3.5 前端搭建一个偏后端技术人员的取舍坦白说我不是专业前端出身所以DeskcommCRM的前端我选了Vue加Element Plus理由很简单文档全、组件多、社区大遇到问题查得到答案。如果你也和我一样偏后端这个组合是能最快把系统做出来且不太丑的方案。核心页面就四个客户列表页、客户详情时间线页、工单列表页、工单详情页。客户列表页用了Element Plus的表格组件包含搜索、筛选、分页大概两百行代码。详细信息我花的心思基本上都在交互操作效率上比如回车提交表单、快捷键切换Tab、批量操作确认弹窗这些细节。前端要说一个坑表格数据量大之后直接渲染会导致页面卡顿。解决方法就是后端做分页每页二十到五十条前端不要一次性拉全部数据。我在API设计里统一了分页参数格式page和page_size两个参数所有列表接口保持一致后端封了一个BaseQuerySet的通用分页处理省了不少重复代码。还有一个重点是表单校验要在前后端都做。前端的校验是用来提升用户体验的后端的校验才是真正的安全防线。比如邮箱格式校验前后端用同一套正则规则避免前端能过、后端不过的尴尬场景。4. 实施过程中的常见问题与排查技巧实录从开发到上线DeskcommCRM踩过的坑不算少。这一章我把最有代表性的几个问题整理出来每一条都是实际发生过、实际排查到根源的希望你能少走一些弯路。4.1 客户数据重复的根源不在技术在流程数据重复问题我在前面提过但这里要说说更深一层的原因。我做了一堆去重功能之后重复数据依然不断出现后来蹲在客服座位旁边看了一圈才明白有些重复其实是业务场景上合法的。比如同一个客户集团采购业务线和售后服务线分别建了档案两家都不知道对方存在又比如客户A在不同渠道留下了不同联系方式被当成两个客户。这就不是简单的技术去重能解决的需要流程配合。我的做法是每周给管理员发一份“疑似重复客户清单”由管理员人工确认是否合并。技术负责找候选人负责做判断这样最稳妥。4.2 两个人同时编辑同一条工单怎么处理DeskcommCRM上线后遇到的一个实际问题是销售和客服同时打开同一个客户的工单销售改了一下描述客服改了一下优先级后保存的就把先保存的覆盖掉了。查了工单变更时间线才发现之前的改动直接丢了。解决思路其实很常规就是对工单表加一个version字段。更新的时候带上前端读取时的versionSQL更新条件是WHERE idxxx AND version旧版本号如果更新的行数为0就说明文档已经被其他人改过了提示用户重新加载再编辑这是最经典的乐观锁做法。UPDATE tickets SET title $1, priority $2, version version 1 WHERE id $3 AND version $4 RETURNING id;如果返回的行数不对前端就弹窗告诉用户“该工单已被同事修改请刷新后再操作”。这个方案实现成本很低但对内容安全性的提升非常明显。更复杂的并发冲突解决比如字段级合并对内部系统来说没必要乐观锁已经足够了。4.3 时区问题导致沟通记录“穿越”DeskcommCRM上线第二周有同事反馈说“客户昨天下午打的电话系统里显示的却是今天凌晨”。我排查了一圈最后定位到是时区处理的坑。问题是这样的前端把时间戳转成字符串的时候用的是浏览器本地时区但数据库存储的是UTC时间。前端在发送沟通时间时直接传了一个“2024-03-15 09:00”这样的字符串没有带时区信息后端解析的时候就默认当成服务器时区结果就和真实时间差了8个小时。这个问题折腾了我半天最终的解决方案是所有时间字段在后端统一用TIMESTAMPTZ类型存储所有前后端交互的时间参数统一用ISO 8601格式也就是带时区偏移的字符串比如2024-03-15T09:00:0008:00。前端在传给后端之前用JavaScript的Date对象的toISOString方法统一转换因为toISOString本身就有时区偏移后端拿到手就是完整的时间信息。从那以后时间线再没出现过“穿越”问题。4.4 搜索卡顿光加索引还不够客户列表页的搜索框最开始用的是PostgreSQL的ILIKE模糊查询数据量到几万条之后明显变慢了。后来我第一次想到加索引加的是普通B-tree索引结果毫无作用——因为模糊查询的通配符在前面%keyword%B-tree索引根本用不上。这次之后我换成了pg_trgm的GIN索引问题才算真正解决。做这个切换的时候还踩了个坑生产库加pg_trgm扩展需要超级用户权限当时我的账号权限不够还得找DBA帮忙。所以如果要走这个方案务必提前确认数据库账号权限。另一个提升搜索体验的小技巧是使用搜索建议。前端在用户输入过程中做防抖停顿500毫秒才发请求避免每个字符都打一次接口给数据库造成压力。这个优化不仅让后端更轻松用户体感也更好不会觉得打字都卡。4.5 权限问题前端隐藏不等于后端拦截权限方面的第一个大坑就是我在2.3节提到过的后端接口没有加数据权限过滤。当时某个同事直接调API把全阶段数据拉走这让我反思了很久——前端不管怎么控制展示后端API都必须默认“最小可见”原则宁可多写几个JOIN把权限条件带上也不能图省事不看权限。这里有个具体的实现技巧不要在每个查询里手动写权限条件而是在SQLAlchemy模型层配置一个全局的Query过滤器自动把当前用户的可见客户ID范围拼进去。我使用的是Flask-SQLAlchemy的查询事件注册一个监听器在每次查询时动态修改SQLevent.listens_for(Query, before_compile) def add_tenant_filter(query): # 从上下文获取当前用户 user get_current_user() if user is None: return query # 如果是管理员直接放行 if user.is_admin: return query # 其他用户只能查可见客户 visible_customer_ids get_visible_customer_ids(user.id) return query.enable_assertions(False).filter( Customer.id.in_(visible_customer_ids) )这个方案有个前提是全局只有一个系统如果在同一个APP里跑多租户就不太适用那时候需要更严格的租户隔离。但对DeskcommCRM这样的内部系统来说这样一个全局过滤器就能解决绝大部分权限遗漏问题。5. 上线三个月后的一些实际体会DeskcommCRM跑到现在已经有几个月团队规模从最开始5个人到后来20多人系统目前还很稳。但如果说当初设计里有哪些地方现在想改的我也会毫不避讳地说几条。第一是交互上移动端支持太弱了。当初为了快速上线前端只做了响应式适配没有做独立的移动端页面导致销售在外面拜访客户时用手机打开系统体验比较糟糕。如果你也要做类似的系统一开始就把移动端或者至少PWA方案纳入规划值得多考虑。第二是数据分析能力偏弱。目前能看的只有工单完成率和客户跟进频率的简单统计想深入分析客户转化率、团队绩效这些维度就比较吃力。这些功能需要更长时间的数据沉淀之后再做所以我也不后悔第一版没做只是现在确实需要补上了。当初决定自己做这套系统的时候很多人劝我说别重复造轮子现在回头看对于我们的场景来说这个决定是值得的。核心业务流程完全可控新需求从提出来到上线通常只要两天这种响应速度是外部产品给不了的。如果你也在考虑给团队做一套类似的客户管理工作台建议你先花一周时间梳理清楚自己的核心流程然后从最小可行版本开始别追求一步到位CRM这种系统是跟着业务一起长出来的。
从零搭建DeskcommCRM：轻量级客户关系管理系统的设计与实践
1. 先想清楚DeskcommCRM到底解决什么问题DeskcommCRM这个名字字面上拆开就是Desk加Comm意思很直白坐在办公桌前面把日常沟通全部沉淀下来。我做完这套系统之后最大的感受是很多团队缺的根本不是CRM缺的是一个能让他们“少切窗口”的工作台。销售手里同时开着微信、企业邮箱、Excel表格和记事本客户信息散落得到处都是跟了三个月的客户换个人对接就得从头问一遍这种状态谈什么客户关系管理。DeskcommCRM是我给团队做的一套轻量级客户关系管理系统定位很明确围绕客户档案、沟通记录、工单跟进三个核心场景把销售和客服日常工作流串起来。和市面上动辄几十万、上百个字段的通用CRM不一样DeskcommCRM从一开始就只做几件事——客户档案统一管理、沟通记录全量留痕、工单进度实时同步、全局搜索一秒钟找到人。如果你现在面临的情况和我当时差不多比如销售团队用Excel管客户数据存在每个人电脑里离职带走一大半客服和销售的沟通记录散落在邮件、微信、电话里事后翻聊天记录翻到崩溃客户反馈的问题跟到一半就没有下文没人知道卡在哪个环节老板问起重点客户进展没人能当场说清楚那这篇博文里讲的思路和实现路径应该正好是你需要的。我会把DeskcommCRM从需求拆解、数据模型设计、核心代码实现到上线后的坑完整过一遍代码部分不是给你复制粘贴就完事更重要的是理解每一步为什么要这么做。先说一句掏心窝的话做内部系统最怕的不是需求复杂是需求说不清楚。DeskcommCRM之所以能做下去是因为我在动工之前先把边界画死了——什么功能必须做什么功能坚决不做都写进了设计文档。没有这一步后面所有代码都是给自己挖坑。1.1 市面上CRM一堆为什么还要自己搭我知道你现在想什么市面上一大堆现成CRMSalesforce、HubSpot、Pipedrive国内还有一堆SaaS产品为什么非要自己写一套这个问题的答案其实也是我最终决定动手的原因。第一个原因是数据打通和定制的成本。通用CRM的功能动辄几百个字段但真正用得上的就是那么十几个字段。可当你需要把CRM数据和自己的业务系统打通时SaaS产品往往受限于API的开放程度要么不支持要么收费高得离谱。比如我当时的场景是客户报修之后需要自动生成一个跟进工单并且把客户的历史沟通记录都带出来SaaS版的CRM做这种个性化联动要么很难配置要么得付额外费用。第二个原因是使用习惯。销售和客服团队对我强调的“一个页面解决全部操作”有非常强烈的偏好他们不想先打开CRM看客户信息再打开另一个系统建工单再切换邮箱写邮件。DeskcommCRM把客户信息和沟通动作放在同一个工作台里左边是客户列表中间是沟通记录时间线右边是待办工单这个布局在通用产品里很难定制自己做则完全可控。第三个原因更现实——成本。小团队用大平台CRM账号费用、定制开发费用、集成费用加起来一年下来往往够自己养一个小系统了。自己搭一套轻量的只要控制好边界总体成本其实更低而且数据完全在自己的掌控里。当然自己写的坏处我也得说清楚功能成熟度、稳定性、移动端体验都和成熟产品有差距。所以这事适合什么团队做团队规模不大、业务流程相对稳定、有一定技术能力、对数据打通有强需求。如果你的团队超过一两百人部门之间流程差异很大我建议还是老老实实选成熟产品二次开发的坑会让你怀疑人生。1.2 DeskcommCRM的核心能力边界设计和开发之前我把DeskcommCRM的能力边界写了明明白白一共就三个核心模块。客户档案模块统一的客户主数据管理包含基础信息、归属人、层级关系、标签体系和跟进状态。这个模块的核心价值是“一个客户只有一条记录”所有围绕客户的沟通、工单、合同信息都挂在这条记录下。沟通记录模块记录每一次与客户的互动包括电话、邮件、线上沟通。每条记录支持附件、标签和提及同事并且会在客户时间线上按时间排序展示。这个模块的核心价值是“所有沟通都有迹可循”。工单跟进模块把客户的请求、报修、投诉、需求变成可跟踪的工单有明确的处理人、优先级、截止时间和状态流转。工单和客户、沟通记录双向关联谁在处理、卡在哪个环节一目了然。这三个模块之外的东西我都不做像合同管理、回款管理、数据分析报表这类功能第一版统统砍掉。为什么因为每多一个模块数据模型复杂度会指数级上升开发周期和测试成本也跟着上去。小团队最需要的是把核心流程跑通而不是一开始就做一个什么都沾一点但什么都不好用的“大杂烩”。1.3 为什么强调“沟通记录”这件事DeskcommCRM和普通CRM最大的一个区别是把沟通记录放到了和客户档案同等的核心位置。我之前调研过团队的使用习惯发现一个很有意思的现象大部分CRM能把客户资料填得很完整电话、职务、公司规模全都有但问到这个客户最近聊了什么、上次沟通是什么时候就一片空白。原因很简单——人都是懒的如果录入沟通记录要多开一个表单、多填十个字段没人愿意填。所以在DeskcommCRM里沟通记录的交互被我简化到了极致默认有一条记录填写客户、时间、类型、内容就可以保存其他都是选填。技术上看起来没什么特别但这个设计决策直接决定了系统能不能用起来。我的原则是任何需要用户超过15秒才能完成的操作都会成为系统被弃用的理由所以能省则省。2. 业务模型与数据设计先把地基打在数据库里系统能跑多久不看前端多花哨看数据模型扎不扎实。DeskcommCRM的数据模型我大概推翻重构过两版第一版太复杂光是客户类型就设计了十几种结果前端开发和同事使用都懵了第二版砍掉了大量不必要的字段和关联才真正稳定下来。2.1 四张核心表客户、联系人、沟通记录、工单DeskcommCRM的核心数据库表只保留了四张customers客户、contacts联系人、interactions沟通记录、tickets工单。客户表存的是企业或者组织维度的信息字段控制在20个以内。我整理了必填字段客户名称、客户编号、行业、规模、来源渠道、归属销售、状态、创建时间。其余像网址、地址、备注这类非关键字段全放一个扩展字段JSON里去省得频繁改表结构。这样设计有个好处后期加个性化字段不跑SQL迁移改前端配置就行是内部工具保持灵活性的小妙招。联系人表是挂在客户下的子表一个客户可以维护多个联系人。每个联系人包含姓名、职位、电话、邮箱、微信以及是否为决策人的标志位。为什么要单独建表而不是直接塞在客户表里因为一个企业客户往往有多个联系人而且销售在跟进过程中真正说话算话的可能不是最初对接的那个人。把联系人独立出来后面做沟通记录关联时才不会搞混。沟通记录表是整个系统的命脉字段我设计得比较克制关联客户、关联联系人、沟通方式电话、邮件、线上沟通、面谈、沟通时间、内容、操作人、关联工单。沟通内容不搞富文本纯文本加多行就够一方面写起来快另一方面搜索也方便。工单表包含了工单编号、标题、描述、状态、优先级、客户、联系人、处理人、创建人、截止时间、解决时间、关联的沟通记录ID。工单的状态不是简单的“待处理/已处理”两种而是设计了一套具体状态机下一节细说。四张表的关联关系简单明了客户一对多联系人和工单沟通记录可以挂在客户下也可以挂到具体工单下。这样设计查询就很轻量客户详情页就是查一张客户表然后并行查联系人和沟通记录不用做一堆复杂的JOIN。2.2 工单状态机从创建到关闭的六种状态工单模块是DeskcommCRM里业务逻辑最重的地方而状态机设计是我最先确定的方案。工单状态如果随便定义后面做统计和权限控制的时候一定会哭。我最终定义了六个状态状态含义允许的操作open已创建待处理分配处理人、修改优先级assigned已分配处理人开始处理、重新分配in_progress处理中提交阶段性结果、挂起pending等待客户反馈补充信息、重新激活resolved已解决待确认客户确认关闭、重新打开closed已关闭重新打开需理由为什么需要六个状态而不是三个因为在一个真实的客户服务流程里卡住的地方往往不是“有没有在处理”而是“在等谁”。pending这个状态我是专门加进去的用来标明当前在等客户反馈。我发现很多团队的问题不是不干活是活干到一半不知道卡在谁那里加一个pending状态每天扫一眼就知道了。每个状态之间的流转不是随便跳的我在代码里用状态机定义好了合法转换路径。比如resolved状态不能直接跳到in_progress必须走closed或者reopen。第一次做这块时我没做校验结果运营在界面上乱点把工单状态改得一团糟后来老老实实加了状态转换校验情况立刻好转。技术实现上状态机我建议用一张配置表存合法转换关系而不是写死在代码里。虽然代码量多一点但好处是运营人员可以自己调整流程不用每次改状态规则都找你写代码这个弹性对内部系统来说特别重要。2.3 权限模型谁能看谁的客户权限设计是CRM最容易翻车的点。我一开始用的是粗粒度的角色权限就分管理员、销售、客服三种角色结果一上线就出了两个问题销售嫌客服能看到他的客户客服嫌销售能改他的工单。后来我调整成了“角色数据范围”双层模型。第一层是功能权限决定某个人能不能访问某个模块第二层是数据权限决定这个人能看哪些客户。数据范围我分成了四种本人、本部门、全部、指定共享。每个客户都可以单独设置共享给谁共享记录存在单独的customer_shares表里。这里踩过的一个坑是数据权限不能只在前端控制后端API也必须做同样的过滤。我当时前端把“共享客户”的入口藏掉了但后端接口没有加过滤结果懂点技术的同事直接调API把全公司的客户都拉出来了。后端接口的全量参数校验是权限系统的底线绝对不能省。DeskcommCRM的权限实现思路不算复杂核心就是每个查询都强制带一个可见客户ID列表。这个列表由角色和数据权限规则动态生成查询时直接IN条件过滤和业务查询本身解耦。数据量在百万级以下这么干完全没问题再大的量级就得考虑更细的权限剪枝方案了但内部系统一般用不到。3. 实操过程从零搭建DeskcommCRM的关键实现讲完了设计思路这一章开始聊具体实现。我不会贴所有代码系统全部代码量大概有两三万行贴出来你也不想看。我会把每个模块里最关键、最值得讲的部分挑出来讲清楚实现方案和取舍原因。3.1 建表SQL与核心索引设计数据库我用的PostgreSQL为什么不用MySQL个人习惯PostgreSQL的JSON字段支持、全文检索和约束机制都更顺手。建表时不光要定义字段类型索引设计同样重要没有索引的CRM表数据量到几万条之后查询就会慢到怀疑人生。客户表核心建表语句大致是这样的CREATE TABLE customers ( id BIGSERIAL PRIMARY KEY, customer_no VARCHAR(32) NOT NULL UNIQUE, name VARCHAR(128) NOT NULL, industry VARCHAR(64), source_channel VARCHAR(32), owner_id BIGINT NOT NULL REFERENCES users(id), status VARCHAR(16) DEFAULT active, extra JSONB DEFAULT {}, created_at TIMESTAMPTZ DEFAULT now(), updated_at TIMESTAMPTZ DEFAULT now() ); CREATE INDEX idx_customers_owner_status ON customers(owner_id, status); CREATE INDEX idx_customers_name_trgm ON customers USING gin (name gin_trgm_ops);owner_id和status的复合索引解决了“我名下有哪些客户”这个高频查询。客户名称的模糊搜索我用的是pg_trgm扩展这个方案比LIKE %keyword%性能好一个数量级是我实测过最稳的轻量搜索方案。联系方式去重用的是customer_no的唯一索引这个唯一约束后面会说怎么处理。沟通记录表是最容易膨胀的表索引设计更要上心。我建了两个索引一个是(interaction_type, interacted_at)用于按时间和类型筛选一个是(customer_id, interacted_at DESC)用于客户详情页的时间线查询。工单表核心是一个(customer_id, status)的复合索引还有一个处理人的索引用于统计个人负载。3.2 客户去重与合并最容易被低估的模块客户数据随着使用时间变长重复几乎是必然的。同一个客户被销售录了三次名字分别是“某某科技”、“某某科技有限公司”、“某某科技公司”这是我在DeskcommCRM上线第一周就遇到的事。数据一旦重复后面的沟通记录、工单就会跟着重复整个客户时间线就是乱的。去重我分成了两种录入时的实时检查和定期的批量合并。录入时的实时检查实现很简单当用户输入客户名称后前端请求一个接口搜索现有客户名称的相似记录返回可能重复的客户列表让用户确认。后端实现用的还是pg_trgm取相似度大于0.6的结果给用户一个选择要么打开已有客户要么强制创建新客户。这个机制可以拦住80%的低级重复。批量合并则要处理更复杂的情况两个重复客户都存在各自不同的联系人、沟通记录和工单。我的合并策略是指定一个主客户和一个副客户系统自动把副客户下的联系人、沟通记录、工单全部重新关联到主客户下然后对副客户打上merged标记保留一条记录防止历史数据变成孤儿。代码核心就是事务里做这几件事with db.transaction(): update_interactions(ticket_customer_idold_id, new_idnew_id) update_tickets(customer_idold_id, new_idnew_id) update_contacts(customer_idold_id, new_idnew_id) update_customer_status(old_id, merged, merged_intonew_id)关键点是必须在同一个事务里执行否则中途报错会出现一部分数据关联到新客户、另一部分还挂在旧客户下面的情况。我第一次做合并没加事务结果出现了十来个流浪工单光是修复就花了一下午。3.3 沟通记录如何与工单自动联动沟通记录和工单的联动是DeskcommCRM解决“信息割裂”的核心功能。客户打电话来报修客服在系统里创建工单工单编号自动生成这个过程中客服填写的沟通备注自动挂到工单下后续客户再联系时只要有工单号新沟通记录就能自动归到对应工单上。实现思路是这样的工单有一个不可见的关联键ticket_no沟通记录表里有一个可选字段ticket_id。当用户创建工单时前端把工单编号显示出来当用户新建沟通记录时如果内容里包含形如T-2024-0001这样的编号后端会解析出来自动把这条沟通记录和对应工单关联起来。这个设计比下拉选择框更符合实际操作习惯。客服每天要记大量备注让他们在输入内容的同时手动选择关联工单反而增加操作负担。利用工单编号的自动识别客服只需要在备注里写一句“客户回复T-2024-0001已收到”系统就自动关联了。这个交互细节上线后好评率非常高。自动关联逻辑的核心函数不复杂就是正则解析加一次数据库查询def extract_ticket_no(text): match re.search(rT-\d{4}-\d{4}, text) if match: ticket_no match.group(0) ticket Ticket.query.filter_by(ticket_noticket_no).first() if ticket: return ticket.id return None另外一个正向联动是当工单状态从resolved变成closed时系统会自动给客户发送一条短信或邮件通知客户问题已解决。这个通知内容模板可以在后台配置目前内置了几条常见模板。做这个功能的原因很简单——很多客户反馈“问题解决了我都不知道”主动同步状态能明显提升客户满意度。3.4 客户时间线页面所有信息一屏呈现客户详情页是整个系统里用得最多的页面也是我调整次数最多的页面。最初的设计是客户基本信息在上面下面分Tab分别展示联系人、沟通记录、工单结果用户反馈说切换Tab太麻烦看不到全局。后来我改成时间线模式客户基础信息卡固定在上方下面按时间倒序统一展示所有沟通记录和工单动态一条接一条。时间线页面的查询逻辑有点讲究。如果前端发三个请求去查联系人、沟通记录、工单再在浏览器端合并排序数据量稍微大一点就会卡。更合理的做法是后端一次查询出来并合并好前端只负责渲染timeline [] for interaction in get_interactions(customer_id): timeline.append({ type: interaction, date: interaction.interacted_at, title: interaction.subject, content: interaction.content }) for ticket in get_tickets(customer_id): timeline.append({ type: ticket, date: ticket.created_at, title: f工单 {ticket.ticket_no}, content: ticket.title, status: ticket.status }) timeline.sort(keylambda x: x[date], reverseTrue)这个方案在客户数据量几千条的级别运行得很流畅。如果以后客户量到十万级时间线查询可能会慢到时候可以改为游标分页不过当前阶段没有优化的必要。做系统就是这样选一个合适当前规模的方案别提前过度设计。3.5 前端搭建一个偏后端技术人员的取舍坦白说我不是专业前端出身所以DeskcommCRM的前端我选了Vue加Element Plus理由很简单文档全、组件多、社区大遇到问题查得到答案。如果你也和我一样偏后端这个组合是能最快把系统做出来且不太丑的方案。核心页面就四个客户列表页、客户详情时间线页、工单列表页、工单详情页。客户列表页用了Element Plus的表格组件包含搜索、筛选、分页大概两百行代码。详细信息我花的心思基本上都在交互操作效率上比如回车提交表单、快捷键切换Tab、批量操作确认弹窗这些细节。前端要说一个坑表格数据量大之后直接渲染会导致页面卡顿。解决方法就是后端做分页每页二十到五十条前端不要一次性拉全部数据。我在API设计里统一了分页参数格式page和page_size两个参数所有列表接口保持一致后端封了一个BaseQuerySet的通用分页处理省了不少重复代码。还有一个重点是表单校验要在前后端都做。前端的校验是用来提升用户体验的后端的校验才是真正的安全防线。比如邮箱格式校验前后端用同一套正则规则避免前端能过、后端不过的尴尬场景。4. 实施过程中的常见问题与排查技巧实录从开发到上线DeskcommCRM踩过的坑不算少。这一章我把最有代表性的几个问题整理出来每一条都是实际发生过、实际排查到根源的希望你能少走一些弯路。4.1 客户数据重复的根源不在技术在流程数据重复问题我在前面提过但这里要说说更深一层的原因。我做了一堆去重功能之后重复数据依然不断出现后来蹲在客服座位旁边看了一圈才明白有些重复其实是业务场景上合法的。比如同一个客户集团采购业务线和售后服务线分别建了档案两家都不知道对方存在又比如客户A在不同渠道留下了不同联系方式被当成两个客户。这就不是简单的技术去重能解决的需要流程配合。我的做法是每周给管理员发一份“疑似重复客户清单”由管理员人工确认是否合并。技术负责找候选人负责做判断这样最稳妥。4.2 两个人同时编辑同一条工单怎么处理DeskcommCRM上线后遇到的一个实际问题是销售和客服同时打开同一个客户的工单销售改了一下描述客服改了一下优先级后保存的就把先保存的覆盖掉了。查了工单变更时间线才发现之前的改动直接丢了。解决思路其实很常规就是对工单表加一个version字段。更新的时候带上前端读取时的versionSQL更新条件是WHERE idxxx AND version旧版本号如果更新的行数为0就说明文档已经被其他人改过了提示用户重新加载再编辑这是最经典的乐观锁做法。UPDATE tickets SET title $1, priority $2, version version 1 WHERE id $3 AND version $4 RETURNING id;如果返回的行数不对前端就弹窗告诉用户“该工单已被同事修改请刷新后再操作”。这个方案实现成本很低但对内容安全性的提升非常明显。更复杂的并发冲突解决比如字段级合并对内部系统来说没必要乐观锁已经足够了。4.3 时区问题导致沟通记录“穿越”DeskcommCRM上线第二周有同事反馈说“客户昨天下午打的电话系统里显示的却是今天凌晨”。我排查了一圈最后定位到是时区处理的坑。问题是这样的前端把时间戳转成字符串的时候用的是浏览器本地时区但数据库存储的是UTC时间。前端在发送沟通时间时直接传了一个“2024-03-15 09:00”这样的字符串没有带时区信息后端解析的时候就默认当成服务器时区结果就和真实时间差了8个小时。这个问题折腾了我半天最终的解决方案是所有时间字段在后端统一用TIMESTAMPTZ类型存储所有前后端交互的时间参数统一用ISO 8601格式也就是带时区偏移的字符串比如2024-03-15T09:00:0008:00。前端在传给后端之前用JavaScript的Date对象的toISOString方法统一转换因为toISOString本身就有时区偏移后端拿到手就是完整的时间信息。从那以后时间线再没出现过“穿越”问题。4.4 搜索卡顿光加索引还不够客户列表页的搜索框最开始用的是PostgreSQL的ILIKE模糊查询数据量到几万条之后明显变慢了。后来我第一次想到加索引加的是普通B-tree索引结果毫无作用——因为模糊查询的通配符在前面%keyword%B-tree索引根本用不上。这次之后我换成了pg_trgm的GIN索引问题才算真正解决。做这个切换的时候还踩了个坑生产库加pg_trgm扩展需要超级用户权限当时我的账号权限不够还得找DBA帮忙。所以如果要走这个方案务必提前确认数据库账号权限。另一个提升搜索体验的小技巧是使用搜索建议。前端在用户输入过程中做防抖停顿500毫秒才发请求避免每个字符都打一次接口给数据库造成压力。这个优化不仅让后端更轻松用户体感也更好不会觉得打字都卡。4.5 权限问题前端隐藏不等于后端拦截权限方面的第一个大坑就是我在2.3节提到过的后端接口没有加数据权限过滤。当时某个同事直接调API把全阶段数据拉走这让我反思了很久——前端不管怎么控制展示后端API都必须默认“最小可见”原则宁可多写几个JOIN把权限条件带上也不能图省事不看权限。这里有个具体的实现技巧不要在每个查询里手动写权限条件而是在SQLAlchemy模型层配置一个全局的Query过滤器自动把当前用户的可见客户ID范围拼进去。我使用的是Flask-SQLAlchemy的查询事件注册一个监听器在每次查询时动态修改SQLevent.listens_for(Query, before_compile) def add_tenant_filter(query): # 从上下文获取当前用户 user get_current_user() if user is None: return query # 如果是管理员直接放行 if user.is_admin: return query # 其他用户只能查可见客户 visible_customer_ids get_visible_customer_ids(user.id) return query.enable_assertions(False).filter( Customer.id.in_(visible_customer_ids) )这个方案有个前提是全局只有一个系统如果在同一个APP里跑多租户就不太适用那时候需要更严格的租户隔离。但对DeskcommCRM这样的内部系统来说这样一个全局过滤器就能解决绝大部分权限遗漏问题。5. 上线三个月后的一些实际体会DeskcommCRM跑到现在已经有几个月团队规模从最开始5个人到后来20多人系统目前还很稳。但如果说当初设计里有哪些地方现在想改的我也会毫不避讳地说几条。第一是交互上移动端支持太弱了。当初为了快速上线前端只做了响应式适配没有做独立的移动端页面导致销售在外面拜访客户时用手机打开系统体验比较糟糕。如果你也要做类似的系统一开始就把移动端或者至少PWA方案纳入规划值得多考虑。第二是数据分析能力偏弱。目前能看的只有工单完成率和客户跟进频率的简单统计想深入分析客户转化率、团队绩效这些维度就比较吃力。这些功能需要更长时间的数据沉淀之后再做所以我也不后悔第一版没做只是现在确实需要补上了。当初决定自己做这套系统的时候很多人劝我说别重复造轮子现在回头看对于我们的场景来说这个决定是值得的。核心业务流程完全可控新需求从提出来到上线通常只要两天这种响应速度是外部产品给不了的。如果你也在考虑给团队做一套类似的客户管理工作台建议你先花一周时间梳理清楚自己的核心流程然后从最小可行版本开始别追求一步到位CRM这种系统是跟着业务一起长出来的。