DeskcommCRM 这个名字最初只是我给自己写的一个内部工具随手起的代号。起因很直接——团队换了好几款在线客户管理工具最后都卡在同一个地方数据导不出来、字段怎么调都不顺手、销售跟进的过程跟黑盒一样。后来我干脆自己动手写了一个跑了大半年想把这套从需求梳理、数据建模、后端实现到前端交互、部署上线的完整思路整理出来。这篇内容适合两类人看一是想自建 CRM 但不知道从哪里下手的技术负责人二是刚接触客户管理系统、想搞清楚这类系统核心逻辑的开发者。反正在我看来DeskcommCRM 的真正价值不在代码量而在于把销售流程这件事用系统语言重新讲清楚了。1. 先想清楚DeskcommCRM 到底要解决什么问题1.1 从我需要的不是功能是流程说起大多数团队决定上 CRM 的时候第一反应是去对比市面上的 SaaS 产品这个有电话集成那个有邮件营销这个有 BI 报表。但真到用的时候才发现销售根本不愿意打开系统。原因不是界面丑而是系统里的字段和流程跟真实销售动作对不上。我当时问了一圈团队里的一线销售得到的反馈高度一致他们只想知道三件事——今天该联系谁、上次跟客户聊到哪里、下一步做什么。至于客户来源是广告还是转介绍、合同金额归属哪个季度这些都是管理层关心的问题销售自己并不在乎。所以 DeskcommCRM 的第一版需求特别朴素把散落在 Excel、微信聊天记录和个人通讯录里的客户信息收敛到一个地方并且让客户跟进这件事有明确的下一步。如果这个系统不能让销售觉得用了它我每天能少想一件事那做再多功能都是白搭。从技术侧看CRM 系统的核心并不复杂一张客户表、一张跟进记录表、一张用户权限表再加一个待办提醒。难的是这些表之间的状态怎么流转以及不同角色的人在同一个数据上怎么协作。DeskcommCRM 的所有设计都是围绕这两个问题展开的。1.2 功能裁剪的三个判断标准我见过不少自建 CRM 失败的项目死因几乎都不是技术而是功能越做越多。一开始想做活动管理接着想做工单后来又想把财务对账也放进来最后系统臃肿到没有人愿意用。我在 DeskcommCRM 里定了一个比较务实的筛选标准每个功能在进入开发之前都要过这三关是否影响核心闭环线索录入 → 跟进 → 转化一线销售每天是否真的会用现有工具是否能低成本替代按这个标准下面这个表格基本就是我当时的功能取舍结果。功能模块是否保留决策理由客户列表与全局搜索保留所有操作的入口没有它系统就不成立线索池与分配规则保留解决销售抢单和线索回收问题跟进记录与待办提醒保留让销售每天知道该干什么商机阶段管理暂缓团队流程简单用客户状态字段就能覆盖工单系统不做已有独立客服工具重复建设发票与合同管理不做与财务系统、法务流程重叠接入成本高这套筛选标准最重要的作用是帮我挡住了大量听起来很合理但实际没人用的需求。比如当时有人提客户生日自动发短信祝福听着很贴心但团队客户量不到一千手动发效果反而更好。这种功能做进去后期维护短信模板、计费、退订逻辑的成本远远大于收益。2. 数据模型设计一组关系表如何支撑销售流程2.1 核心表与关系设计DeskcommCRM 的数据模型没有采用市面上常见的大宽表设计而是拆成了几张职责清晰的关系表。用户表、线索表、跟进记录表、任务表、操作日志表这五张表构成整个业务闭环。用户表不光是存账号密码更重要的是承担了权限分组和团队归属的职责。每个用户都有 role_id 和 department_id 两个字段后面的数据隔离全靠这两个字段过滤。线索表则承担了最重的业务状态owner_id 记录这条线索当前归属谁source 记录来源渠道status 用来表达线索当前处于什么阶段。实际设计和普通通讯录最大的区别是 DeskcommCRM 把线索和跟进记录严格拆成了两张表。很多初级的 CRM 会把上次跟进内容直接做成客户表里的一个文本字段但这样会遇到两个问题一是历史跟进内容会被覆盖二是无法统计每个销售的跟进行为。拆成独立表之后客户详情页只需要按 lead_id 倒序拉最近的二十条记录列表性能和数据完整性都能兼顾。字段设计上我有一个比较深的体会业务主键和展示字段要分开。比如客户编号我用了自增 id但对外展示又单独留了一个 client_no 字段。因为自增 id 一旦暴露别人能通过修改 URL 里的 id 去遍历客户数据配合权限过滤失误就可能造成数据泄露。单独做一个不可预测的随机编号至少能少一层风险。2.2 状态机与流转规则把散装流程收紧客户管理最怕的就是状态字段乱填。同一个客户有的人在备注里写已微信联系有的人在标签里写初步沟通还有的人干脆不改状态导致管理层看到的数据永远是滞后的。DeskcommCRM 在状态设计上直接借鉴了状态机的思路把线索流转约束成一条明确的路径new新线索→ following跟进中→ converted已转化或 invalid无效线索。任何状态变更都必须走代码里定义好的转换方法不允许直接写任意字符串。这里最关键的一个业务规则是线索回收。如果一条线索长时间没有新增跟进记录系统会自动把 owner_id 清空并放回公共线索池让其他销售可以重新领取。这个规则在数据库层其实是一次很简单的 UPDATE但要想清楚时间阈值和通知机制。我当时的做法是线索超过 7 天无跟进进入即将回收状态并提醒当前负责人超过 10 天仍无新增跟进自动回收。实现上会涉及一个定时任务的状态判断示意逻辑大概是expired_leads Lead.query.filter( Lead.status following, Lead.updated_at now - timedelta(days10), Lead.owner_id.isnot(None) ).all() for lead in expired_leads: lead.owner_id None lead.status new add_operation_log(userNone, actionrecycle, lead_idlead.id)这段逻辑看着简单但它其实是整个系统里最能促进销售行动的功能。没有回收机制的时候很多销售会把客户占在名下不跟进有了回收机制销售每天上班第一件事就是去看自己的待办列表因为谁也不想辛苦领到的线索被别人捡走。3. 后端实现登录鉴权、线索池与权限模型3.1 技术栈选型与理由DeskcommCRM 后端选型是 FastAPI PostgreSQL RedisORM 用 SQLAlchemy。这个组合在当时的团队里并不是什么追新纯粹是务实的决定。FastAPI 的好处是类型提示和自动文档。写完一个接口Swagger 文档自动生成前端同事不用再天天来问这个接口参数是什么类型。Pydantic 做请求体校验又省掉了一大批手工判断比如手机号格式、枚举值范围在进业务逻辑之前就被拦截了。PostgreSQL 在这个项目里几乎是不可替代的不仅是因为事务和行级锁稳定更因为后面要讲的 SKIP LOCKED 特性。MySQL 也有类似能力但 PostgreSQL 在这类并发控制场景下用起来更顺手。Redis 则承担了三件事接口限流、验证码临时存储、高频读取的小字典比如部门列表、渠道列表这些变化不频繁的数据。这里我想提醒一句技术栈没有绝对的好坏只有适不适合当前团队。如果团队全员都是 Java 背景硬上 Python 反而会埋坑。DeskcommCRM 当时选择 Python是因为我自己最熟后续维护不用再请人。3.2 线索池并发分配SKIP LOCKED 才是关键线索池分发是个典型的并发场景销售各自打开线索池页面同时点击领取按钮系统必须保证同一条线索不会被两个人同时抢走。最直观的写法是先 SELECT 一条未分配的线索再 UPDATE 它的 owner_id。但这两个操作之间如果没有锁保护两个请求的 SELECT 可能拿到同一条记录然后各自 UPDATE最后一条线索被分配给了两个人逻辑就崩了。正确姿势是使用 PostgreSQL 的SELECT ... FOR UPDATE SKIP LOCKED。它能把查询符合条件的记录和给这条记录加排他锁合并成一个原子操作同时跳过已经被其他事务锁定的行。实际 SQL 长这样BEGIN; SELECT id FROM leads WHERE status new AND owner_id IS NULL ORDER BY id LIMIT 1 FOR UPDATE SKIP LOCKED; -- 业务代码拿到 id 之后执行归属更新 UPDATE leads SET owner_id :current_user_id, status following WHERE id :id; COMMIT;我第一次写这段逻辑的时候犯过一个低级错误把 SELECT 和 UPDATE 分开放在两个事务里中间又做了一些耗时操作导致锁持有时间过长高并发下数据库连接池被占满。后来把事务边界收窄只保留 SQL 执行和必要的业务校验问题就解决了。还有一点值得注意SKIP LOCKED 适合的是多个人抢有限资源的场景。但如果每秒钟有几万个领取请求数据库压力还是很大那时候才需要考虑把线索池提前加载到 Redis 队列里。对于小团队来说数据库层加锁已经绰绰有余没必要为了想象中几十倍的峰值流量把架构搞复杂。3.3 权限模型岗位角色和数据范围分开做权限这块DeskcommCRM 的切入点是先做粗粒度再考虑细粒度。角色只分了四类管理员 admin、销售主管 leader、普通销售 sales、只读访客 viewer。管理员能看所有数据、改所有配置销售主管能看本部门数据普通销售只能看自己名下线索访客只能看被明确共享的看板。真正决定数据可见范围的核心不是角色字符串而是数据范围这个概念。判断逻辑永远是根据角色找到数据范围再在查询条件里拼上对应的过滤条件。def filter_leads_by_permission(user, query): if user.role admin: return query if user.role leader: return query.filter(Lead.department_id user.department_id) return query.filter(Lead.owner_id user.id)这段代码看起来简单但实际项目里最容易出问题的点是列表接口、详情接口、导出接口、统计接口各写了一套判断逻辑结果有的接口漏了过滤。我的建议是把这个过滤函数做成所有查询的公共入口不允许业务代码里直接裸查 Lead 表否则早晚会漏。权限模型上线后我还发现一个有意思的现象销售对数据安全的敏感度远低于管理员的想象。很多销售觉得反正都是自己团队的客户让别人看到也没关系但一旦出现客户被同事抢走的情况他们对权限的态度就会一百八十度转弯。所以在做权限功能时宁可一开始严格一些也不要先松后紧因为收紧权限一定会引起反感。4. 前端交互让销售愿意每天打开的界面4.1 页面布局与信息优先级DeskcommCRM 的前端没有用复杂的可视化配置也没有炫酷的拖拽面板设计逻辑就一条把销售每天最高频的动作放在最容易点到的地方。主界面采用三栏布局左侧是客户列表和筛选器中间是当前客户的详情右侧是跟进记录和待办事项。顶部只有一个全局搜索框和新增客户按钮。第一版我甚至砍掉了侧边导航栏因为对一个销售来说除了客户他几乎不需要访问其他页面。报表页面被放到了二级入口这样管理层看数据的入口还在但不会干扰一线销售的操作动线。今日待办是整套界面里使用率最高的模块。它直接从任务表和线索表的 next_follow_at 字段里拉取当天需要跟进的客户按时间顺序排列。销售打开系统不需要思考我该干什么列表已经告诉他答案。这里有一个很小的交互细节值得一提客户列表默认的排序规则不是创建时间而是 next_follow_at 的升序同时过滤掉已经完成任务的客户。这样保证排在列表最前面的永远是我现在最应该联系的人而不是昨天刚录入的那批数据。4.2 极简快捷录入一次回车完成跟进销售人员普遍不愿意填写复杂表单这是所有 CRM 落地的最大阻力。DeskcommCRM 做了一个快速新增客户的浮层但实际最常用的其实是另一个功能从全局搜索框直接输入手机号或客户名称如果系统里没有回车就直接弹出新增客户并写首次跟进的界面。这个界面被我压缩到极致必填项只有客户姓名和联系方式跟进内容一个多行文本框下一步动作一个单行文本框总共三个字段。写完跟进内容后按 Enter 保存按 CtrlEnter 保存并关闭弹窗回到列表页。整套操作只需要十秒。为了把十秒录入这件事做扎实前端还做了一层容错当销售输入的联系方式已经在系统中存在时不直接报错而是提示该客户已存在是否跳转到详情页这样既避免了重复客户又减少了销售的不满。第 4 章快结束的时候我想强调一下前端交互的优先级永远应该排在让系统显得专业之前。很多 CRM 做了一堆华丽的图表和仪表盘销售却连一条跟进记录都懒得写这就是本末倒置。DeskcommCRM 之所以能坚持用下来最大功臣就是那个十秒录入的快捷面板。5. 部署上线Docker Compose 一把梭背后的细节5.1 docker-compose 配置的落地版本DeskcommCRM 的部署没有上 Kubernetes因为一个三五十人团队使用的系统Kubernetes 的运维成本完全是浪费。我用 Docker Compose 把四个服务编排在一起前端静态资源由 Nginx 提供后端 API 单独跑一个容器数据库用 PostgreSQL缓存用 Redis。配置文件的骨架大致是services: db: image: postgres:15 environment: POSTGRES_DB: deskcomm POSTGRES_USER: deskcomm POSTGRES_PASSWORD: ${DB_PASSWORD} volumes: - pgdata:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U deskcomm] interval: 5s timeout: 3s retries: 10 redis: image: redis:7-alpine api: build: ./api environment: DATABASE_URL: postgresql://deskcomm:${DB_PASSWORD}db:5432/deskcomm REDIS_URL: redis://redis:6379/0 depends_on: db: condition: service_healthy nginx: image: nginx:1.25 ports: - 80:80 volumes: - ./web/dist:/usr/share/nginx/html - ./nginx.conf:/etc/nginx/conf.d/default.conf depends_on: - api volumes: pgdata:我要特别提醒一个坑Nginx 默认的请求体大小限制是 1MB。如果销售要从 Excel 批量导入客户文件稍微大一点就会收到 413 Request Entity Too Large。后来我在 Nginx 配置里加了 client_max_body_size 20m问题才解决。另外API 容器一定不要直接暴露端口到宿主机只让 Nginx 能访问到它就行这样外部流量入口只有 80 一个点排查问题也简单。5.2 数据备份与安全加固数据备份这件事我交过学费。DeskcommCRM 上线第二个月有一次数据库容器所在磁盘满了PostgreSQL 直接进入只读模式。因为之前没有配置自动备份我只能从开发环境的旧数据里恢复白丢了两天的跟进记录。从那以后我把备份脚本放进了 crontab每天凌晨两点执行一次0 2 * * * pg_dump -U deskcomm deskcomm | gzip /backup/deskcomm_$(date \%F).sql.gz find /backup -name *.sql.gz -mtime 30 -delete备份要保留多久取决于团队习惯我保留 30 天因为 CRM 的历史数据很少会被改到每天的增量变化其实不大。如果条件允许最好把备份文件定期复制到另一台机器或对象存储防止服务器本身出现故障导致备份跟着一起丢。安全加固方面除了常规的密码哈希和 JWT 过期策略我最想强调的是登录接口限流。没有限流时系统上线几天就会收到来自各种来源的暴力破解尝试。我用 Redis 给登录接口加了简单的计数器同一 IP 一小时内失败超过五次就拒绝登录同一用户名则执行全局限制。这个策略简单粗暴但效果不错。5.3 单租户还是多租户按规模决策关于多租户的问题我接到的建议大多是为了以后扩展要先做成多租户。但在 DeskcommCRM 这个项目里我果断选择了单租户。单租户意味着整个系统只服务于我们一个公司部门之间的数据隔离靠 department_id 字段实现。如果真的有一天需要把系统卖出去给别的公司独立部署那么每部署一个客户就起一套全新的 Docker Compose数据完全隔离反而比在同一个库里做多租户隔离更安全。多租户带来的复杂度和收益在几十人规模下不成正比。租户级别的数据隔离、配额管理、升级灰度、跨租户统计每一项都是额外的开发负担。小团队的自建系统应该追求能简单就不复杂等业务真的到了需要多租户的那一天再重构也来得及。6. 上线后的真实数据与迭代记录6.1 两个月的使用数据DeskcommCRM 上线两个月后我拉过一组数据很能说明问题。团队一共 5 名销售系统里沉淀了 300 多条有效线索跟进记录总数超过 800 条平均每天新增跟进 15 条左右。线索转化率从原先凭感觉估计的 5%逐渐稳定到可统计的 12%。我印象最深的变化是待办完成率。原来用共享表格的时候销售们嘴上说每天跟进但实际上很难追踪。上线 DeskcommCRM 之后今日待办成了每天晨会的内容哪个销售有 5 个待办没完成一眼就能看到。到了第二个月待办完成率从最初的 40% 提升到了 85%这个数字比任何功能都能说明系统价值。当然也存在反面数据。权限最宽松的那段时间有销售把客户备注当成聊天工具来用在一个客户的跟进记录里写了几十行无关对话。后来我们把跟进记录做了最小长度限制同时要求下一步动作必填这种灌水现象才明显减少。6.2 踩过的三个大坑第一个坑是字段开放导致数据不可信。最开始客户渠道字段是自由文本结果出现了微信、WeChat、微、VX 四种写法。后来把所有这种维度字段全部改成枚举类型并在接口层做了 Pydantic 校验数据才慢慢统一起来。我现在的经验是能用下拉框的字段绝不用文本框。第二个坑是删除操作没有留痕。某天销售误删了一条重要线索当时直接执行的物理 DELETE谁删的、什么时候删的完全无从查起。后来我把删除全部改成逻辑删除状态字段标记为 deleted同时记录操作日志。虽然数据表会越来越大但 CRM 这种系统对审计追溯的需求远超那点存储成本。第三个坑是通知提醒变成了骚扰。最初每个字段变更都会给负责人推送结果不到一周所有人把通知权限关了重要提醒也被一起屏蔽。后来我把通知收敛到两个场景今日待办提醒、线索即将被回收提醒。这样每天最多一两条反而打开率特别高。迭代到第三个月的时候我给 DeskcommCRM 加了一个外面很多系统都有的功能跟进记录的最近联系人时间轴。它最大的作用不是展示而是让销售在客户详情页能快速回忆起上次聊到哪里、对方说过什么避免电话接通后还要翻半天聊天记录。如果让我重新做一次我会在第一天就把字段枚举和操作日志先写进基础框架而不是等数据脏了之后再补。数据规范这件事越晚补代价越高。DeskcommCRM 不是什么高深的技术项目但真正让团队养成每天知道该跟谁、下一步做什么的习惯之后它就远比那些功能堆砌的商业系统更值得用下去。