开头先从真实场景切入我接手公司销售管理的时候客户资料散落在十几个销售的个人微信、Excel表格和手机通讯录里撞单、漏跟、离职交接断档各种问题天天上演。后来我花了三周时间从零搭了一个客户管理系统也就是DeskcommCRM上线到现在已经稳定跑了快一年团队从12人扩到40人这套系统一直在用。这篇文章想把整个项目的选型思考、核心设计、部署经验和踩过的坑完整写出来给正在纠结“买现成CRM还是自建”的朋友一个真实的参考样本。需要先说清楚DeskcommCRM不是一个挂出来的开源项目而是我们内部自研、私有化部署的crm客户管理系统。它能管理线索、客户、跟进记录、商机状态和合同回款支持多角色权限和数据隔离会生成销售漏斗和业绩报表。文章会重点拆解四个部分为什么放弃免费CRM选择自建、DeskcommCRM的核心数据模型和权限设计、员工邀请与团队落地实操、永久在线部署的具体方案。如果你想做同类系统或者正在评估“免费crm与私人网站的区别”这篇应该对你有直接用处。1. 为什么在免费CRM和自建系统之间我最终选了DeskcommCRM1.1 免费CRM看着省钱算完账之后最烧钱市面上免费CRM不少飞鱼CRM、纷享销客、销售易都提供免费版或试用版。当时我也下载过两三个让销售先用发现问题并不在功能而是在“它的免费版根本不是给你公司用的”。免费版的典型限制几乎一致客户数量卡在几百到一千条超过就要付费高级报表、批量导入、自定义字段、API接口这些真正影响效率的功能全部锁在付费墙后面数据存在服务商服务器上导出虽然能做但格式和字段损耗严重。最让我不能接受的是销售在免费版上辛辛苦苦录了几百条客户一旦停用或者升级收费版本导出数据结构对不上等于推倒重来。免费CRM的真正成本是迁移成本和信任成本。客户数据是公司最核心的资产放在别人服务器上服务商随时可以调整免费策略这不是危言耸听过去几年已经有好几家CRM厂商大幅收缩免费版权益。对一个小团队来说一开始省下的那点订阅费远不够弥补后续迁移、断供、定制折腾的代价。1.2 所谓“私人网站”本质是私有化部署的选择热搜里那句“免费crm与私人网站的区别在哪”其实戳中了关键很多人在搜索“私人CRM网站”这个概念。这里的“私人网站”指的就是自建、自部署、自有数据库的系统对应到我们做的就是这类。免费云CRM和私有化部署CRM的区别我用一张表讲清楚对比维度免费云CRM私有化部署CRMDeskcommCRM数据存储服务商服务器自己的数据库数据所有权归服务商/平台可被用于分析完全归公司字段定制受限需付费解锁完全自定义功能扩展依赖官方API和生态自己改代码想加就加部署成本低注册即用需要服务器开发维护人力长期成本付费后不便宜数据锁定风险高一次性研发固定运维上线速度当天即可2-3周起步这个对比不是否定云CRM而是要看场景。如果你只要一个“记录客户名字电话”的工具那免费版够用如果你想真正把销售过程管起来并且希望数据沉淀成为公司资产私有化是必然方向。DeskcommCRM就是从“数据必须在自己手里”这个底线出发做的。1.3 最终拍板前我算过一笔三年期总成本账当时公司给我预算上限是每年三万第三方CRM的中档版本按15个坐席算一年差不多两万五三年7.5万而这还是销售人数不变的情况。一旦团队扩张到30人三年成本直接奔着15万以上走而且买到的永远是通用模板定制还得额外收费。我自己评估的自建方案是两台云服务器加域名证书一年不到6000块开发时间三周按我工资折算约1.5万后续维护每周最多半天。三年总成本约4万业务特殊需求随时能改数据完全自主。这笔账算完之后我几乎没有犹豫就决定动手做DeskcommCRM。当然前提是我本身是开发出身如果公司没有技术人力这个方案不成立请人开发或者深度配置开源系统更合适。2. DeskcommCRM核心设计客户模型、跟进闭环与销售漏斗2.1 技术栈选择基本是照着RuoYi的思路来的很多做Java后端的朋友都刷过RuoYi Office CRM这个项目我也参考过。RuoYi体系成熟用户、部门、角色、菜单权限一套齐全但对我来说偏重。我要的是一个轻量、和销售使用习惯完全匹配的系统所以最终DeskcommCRM采用了Spring Boot 3 MySQL 8 Redis Vue 3的组合。选Spring Boot是因为团队熟悉Java生态部署方便社区资料多Redis用来做登录会话和扫码登录的token缓存MySQL存业务数据。前端没有用重型UI框架直接Vue 3 Element Plus表格和表单组件够用销售用起来的学习成本低。整体架构非常简单——单体应用前后端分离没有上微服务和消息队列因为一个几十人用的内部系统根本不需要那套复杂度。2.2 客户表和线索表分开设计避免数据和权限混乱第一版DeskcommCRM我把客户和线索混在一张表结果很快出问题。销售每天录入的有电话咨询的陌生线索也有已经成单的老客户两者状态、跟进节奏、权限归属完全不同。后来拆成两张表线索表lead字段id、来源渠道、姓名、电话、微信、省份城市、产品意向、状态未分配/跟进中/已转化/无效、归属销售ID、创建时间、转化时间。客户表customer字段id、公司名称、联系人、电话、地址、行业、客户等级A/B/C/D、状态潜在/合作中/停用、归属销售ID、来源线索ID。拆分之后权限逻辑也清晰了线索默认公海池销售主管可以批量分配给销售转化后的客户归属到对应销售名下客户表按归属人做数据隔离。这是整个系统里最基础也最关键的一步如果一开始图省事不分表后面所有统计、漏斗、权限全部会拧巴。2.3 跟进记录是CRM的灵魂设计成独立流水表很多CRM系统把跟进记录只是当成客户详情页里的一个备注文本框这是巨大的反模式。跟进记录必须是一条一条的流水每次跟进都要有独立时间、方式、内容摘要和下一次计划时间。DeskcommCRM的跟进表follow_record字段id、客户ID、销售ID、跟进方式电话/微信/上门/其他、沟通摘要、下次跟进时间、关联商机ID、创建时间。每次新建跟进之后系统会自动更新客户表里的“最近跟进时间”和“下次跟进时间”销售首页的待跟进列表就是基于这个字段实时查出来的。这个设计带来的直接效果是销售每天打开系统就知道今天要联系谁不会出现“感觉这个客户好久没聊了但说不上来哪个该联系”的模糊感。管理者也能看到每个销售的跟进数量、覆盖客户数、平均响应时长数据化考核变得顺理成章。2.4 销售漏斗用状态机统计SQL实现不引入复杂引擎销售漏斗是商机阶段的体现。一个线索转化成客户之后如果近期有购买意向销售会为客户建立商机商机表opportunity字段包括客户ID、商机名称、预计金额、阶段初步接洽/需求确认/方案报价/谈判/赢单/输单、预计成交日期、赢单概率、归属销售ID。这里我走过的弯路是第一版想用工作流引擎把事情做得“完美”比如阶段变更要自动触发提醒、通知等。后来发现小团队根本不需要阶段就是一个状态字段更新时写SQL把对应记录update一下再统计每个阶段的金额总和漏斗就出来了。首页报表用一个SQL完成SELECT stage, COUNT(*) AS deal_count, SUM(expected_amount) AS total_amount FROM opportunity WHERE deleted 0 AND status 1 GROUP BY stage ORDER BY FIELD(stage, 初步接洽, 需求确认, 方案报价, 谈判, 赢单);不夸张地说DeskcommCRM有五成价值在这张漏斗图上。周会打开投影哪个阶段堆积了多少商机金额一目了然销售总监拍板优先级也有了数据依据比拍脑袋强太多了。3. 员工邀请与权限分配让团队顺畅用起来的关键设置3.1 从“飞鱼CRM怎么邀请员工”说起邀请流程设计在决定自研前我也研究过飞鱼CRM等产品“飞鱼crm怎么邀请员工”这个操作其实很简单——管理员在后台添加员工手机号系统发短信员工点链接激活账号。这个思路我当时借鉴了但做了改进因为对内部系统来说把手机号暴露给管理员再输入也够烦更顺滑的做法是邀请码注册。DeskcommCRM的员工邀请流程是管理员在系统“组织管理”页面点击“邀请成员”生成一个邀请链接链接里带一次性token。将链接发给新同事新同事打开后填写姓名、手机号、设置密码即可激活。激活时如果管理员已经提前选了“所属部门”和“岗位角色”新同事登录后界面即按权限展示如果没选默认归入“待分配”组。新同事第一登录时系统强制修改初始密码并绑定微信扫码开启二次验证。这个流程比逐个录入员工信息更快也避免离职员工账号仍挂在部门下没人管的场面。邀请链接的有效期我建议设置成24小时内有效一次性使用防止链接被转发滥用。3.2 角色权限不止“管理员/普通员工”两档数据范围是关键DeskcommCRM权限模型借鉴了RuoYi的通用设计但没有直接用它的全部逻辑因为销售场景需要更细的数据可见性控制。我最终采用的是RBAC 数据范围两层过滤。角色分为三类销售顾问、销售主管、超级管理员。销售顾问只能看自己名下的客户、线索、商机以及公海池中未分配的线索销售主管可以看本部门所有销售的数据并执行客户重新分配操作超级管理员可以看全部包括操作日志、登录记录、数据导出、系统设置。数据范围不是靠前端隐藏按钮实现的而是在后端所有查询SQL里强制带上了数据权限条件。比如销售顾问查询客户列表时MyBatis拦截器会自动在SQL后追加AND customer.owner_user_id #{currentUserId}这个必须由后端拦截不能依赖前端代码否则绕过前端请求就能越权查数据。这是整个系统里安全级别最高的一条红线谁都不例外。3.3 权限踩坑实录注解和拦截器同时开启导致的越权漏洞这里分享一个真实踩坑很有代表性。第一版DeskcommCRM的接口用了Spring Security的注解做权限校验同时又配置了一个全局拦截器统一判断登录状态。本来两者各管一摊但问题出在一个开放接口上导出客户Excel的Controller方法标了PreAuthorize(hasRole(admin))而全局拦截器里对部分URL做了“白名单”放行结果导出接口的URL碰巧在白名单中导致拦截器直接放行注解虽然还在但Spring Security的过滤器链在拦截器之后执行某些配置下注解校验被跳过了。这件事让我明白全局拦截器和注解权限不要混用更应该统一走Spring Security的过滤链用PreAuthorize做方法级校验全局拦截器只负责记录日志和基础 token 校验不要再重复判断角色。同时权限相关配置改动后必须做越权自测用低权限账号尝试访问高权限接口这个动作应该写进上线清单。3.4 操作日志和数据导出权限合规的最后一道防线销售团队对于数据导出这件事向来有争议销售希望导出自己客户名单做离线跟进管理担心客户资料外泄。DeskcommCRM的做法是导出功能仅主管及以上角色可用销售顾问只能在线查看不能批量导出所有导出操作都记录操作日志内容包含操作人、时间、导出条数、筛选条件。一旦出现离职员工带走客户名单的情况可以快速定位到是谁在什么时间导出了什么数据。操作日志表设计很简单一个接口层面的AOP切面对所有写了Log注解的接口统一记录。日志字段包括用户ID、方法名称、请求参数、执行时长、IP地址、操作时间。这个设计投入小但价值极大也是后来信息安全审查时能拿出证据的基础。4. 永久在线的crm网站部署架构与运维血泪4.1 “永久在线”不是口号部署最怕的是半夜宕机没人管很多人搜“永久在线的crm网站”其实是想要一个随时能访问、不会因为电脑关机就断线的CRM。自建系统最怕的就是“只有开发者的电脑开机时系统才在线”——一开始我确实犯过这个错把系统跑在自己的开发机上同事一访问就把我电脑卡死下午我关电脑下班所有人就用不了系统。所以DeskcommCRM必须部署到云服务器。我选的是两台4核8G的云服务器一台跑应用和数据库一台做备份和冷备切换。操作系统用的CentOS 7当时的主流选择现在建议Alibaba Cloud Linux / Ubuntu 22.04 LTS应用通过Docker容器化部署MySQL数据目录挂载到宿主机磁盘Redis做了持久化配置。4.2 用Nginx做反向代理再加域名和HTTPS很多内部系统上线后不太注意公网访问的安全直接IP端口访问。我的经验是不能用裸IP访问必须上域名HTTPS不只为了那个绿锁更是因为互联网上自动化扫描工具每时每刻都在扫3306、8080这些默认端口裸奔随时可能被入侵。DeskcommCRM的Nginx配置核心段如下server { listen 443 ssl http2; server_name crm.example.com; ssl_certificate /etc/nginx/cert/crm.pem; ssl_certificate_key /etc/nginx/cert/crm.key; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } server { listen 80; server_name crm.example.com; return 301 https://$host$request_uri; }4.3 数据库备份才是“永久在线”的真正底线在线是持续性要求备份是灾难恢复要求。我最担心的是数据库磁盘损坏、误删数据、被勒索脚本盯上。DeskcommCRM上线第一天就做了自动备份策略每天凌晨2点使用mysqldump导出全量SQL保留最近30天每周末一次全量备份并同步到另一台服务器的备份目录同步使用rsync加密传输。备份脚本核心逻辑#!/bin/bash BACKUP_DIR/backup/mysql DATE$(date %Y%m%d_%H%M%S) mysqldump -u backup -p密码 --single-transaction --quick --databases deskcomm $BACKUP_DIR/deskcomm_$DATE.sql find $BACKUP_DIR -type f -name *.sql -mtime 30 -delete rsync -avz --delete $BACKUP_DIR/ backup192.168.1.10:/backup/deskcomm/没人愿意在半夜经历数据丢失但没做备份之前你永远不知道这个恐惧有多具体。有次我误操作drop了一张分区表多亏前一天晚上的备份前后只用20分钟就恢复了99%的数据那之后再也没为数据安全性焦虑过。4.4 外网访问的内部系统安全组只放行必要端口安全组是云服务商提供的第一道墙这块不能省。我的规则只放行80、443端口MySQL的3306端口只有内网IP可以访问SSH的22端口改成了非默认端口并且只允许公司固定IP连接。Docker容器里数据库端口不映射到宿主机应用通过容器网络直接访问外部完全无法直接触碰数据库。在互联网上暴露的crm系统我每天都会看安全告警三个月下来发现被尝试扫描和暴力破解的行为有几千次大部分集中在22端口和常见Web路径。没有安全组和HTTPS这些扫描一旦命中弱口令后果就是整个客户数据裸奔。安全不是上线的最后一步而是部署架构的一部分。5. 与RuoYi Office CRM、飞鱼CRM的对比以及复盘后的几条教训5.1 开源方案和商业方案都研究过最后决定自研的真实原因做DeskcommCRM之前团队也认真讨论过直接用RuoYi Office CRM。RuoYi Office CRM功能确实全客户、商机、合同、回款、审批流程都有而且代码开放理论上可以二次开发。但它也有两个实际问题一是模块太重光菜单就有上百个销售反感复杂的操作路径二是它本身建立在通用后台管理框架之上销售场景的交互细节没有充分打磨需要改动的东西几乎等于重写前端。飞鱼CRM这类商业产品功能成熟、体验也不错邀请员工等功能开箱即用。但我还是担心数据安全和长期订阅成本。最终答案其实很清楚省时间买商业版省成本用RuoYi改要数据主权和完全贴合业务的系统就自研。DeskcommCRM走的是第三条路适合有技术团队、业务逻辑特殊、不想被厂商绑定的公司。5.2 实测效果撞单率从每周3次降为0销售响应速度提升8倍复盘DeskcommCRM上线后的业务数据最直观的变化有四个客户的录入动作从销售“愿意记”变成了“系统要我记”。因为线索分配后如果3天内没有首次跟进公海池会自动收回重新分配这个规则倒逼销售及时录入并跟进系统里的客户数据从上线前的约500条变成了现在的超过12000条。撞单率的问题以前每周至少发生2-3次销售为了一个客户争吵、甚至影响合作。现在客户录入系统即锁定归属另外一个客户如果要被第二个人操作系统会提示“该客户已被xx占用”并自动发送私信提醒真正做到了零撞单。销售对新客户的首次响应时长上线前靠微信回复平均要8小时上线后系统自动提醒新分配线索销售基本10分钟内就会查看实际响应时间降到了1-2小时。主管看板也能实时看到哪些线索超过2小时还没有人处理管理动作滞后问题大幅缓解。月度业绩统计原来需要运营同事占半天时间从Excel汇总现在报表页一键导出各销售、各产品的业绩数据财务和销售总监都省了不少事。这些数字不算夸张但我认为已经充分证明了小团队自建CRM的可行性。5.3 自建CRM最容易犯的错过度设计复盘整个DeskcommCRM项目最想提醒大家的是不要过度设计。第一版开发时我一度想加任务管理、项目协作、审批流程、知识库、工单系统后来冷静下来全部砍掉。CRM的价值在于把客户数据、跟进过程、销售结果管起来而不是做一个“大而全”的企业软件。我的建议是第一版只做线索池、客户列表、跟进记录、商机漏斗、员工权限、简单报表这六个模块跑通之后看业务反馈再加东西。DeskcommCRM上线近一年真正高频使用的功能也就是那六块。增加的字段和筛选基本是通过后台配置完成的没有频繁改代码。5.4 另外几条花钱买不来的经验一是别让销售觉得系统是在监控他们更有效的做法是让系统帮他们省时间。比如自动生成今日待跟进列表、自动同步下次跟进时间、自动提醒公海回收做完这些销售自然愿意用。强制要求他们每天填一堆没价值的字段只会让系统沦为形式主义。二是每次发版前把数据备份做了再发别问我是怎么知道的。有次更新SQL脚本里少写了个where条件导致状态字段被批量更新花了一上午恢复。三是定期给团队做轻量培训。我在DeskcommCRM落地后专门给销售开了三次短会每次只讲一个场景怎么建客户、怎么记跟进、怎么看自己的业绩目标。别丢一本操作手册让他们自己看效果基本为零。四是要有一个“用户反馈群”销售在使用中遇到的问题哪怕是“这个按钮颜色太浅找不到”这种细节也要记录下来及时改。系统是给人用的不是炫技术的小细节的优化往往最能赢得用户口碑。走到这一步DeskcommCRM已经从最初的一个应急工具变成了公司销售管理体系里不可缺失的基础设施。它未必适合所有公司但如果你也面临着客户数据分散、撞单频繁、团队扩大之后管理失控的问题我的经验是自建一套轻量CRM的ROI远高于直接订阅通用付费CRM。先跑通最小闭环再迭代优化这套思路对我适用大概率也适合你。
开头先从真实场景切入我接手公司销售管理的时候客户资料散落在十几个销售的个人微信、Excel表格和手机通讯录里撞单、漏跟、离职交接断档各种问题天天上演。后来我花了三周时间从零搭了一个客户管理系统也就是DeskcommCRM上线到现在已经稳定跑了快一年团队从12人扩到40人这套系统一直在用。这篇文章想把整个项目的选型思考、核心设计、部署经验和踩过的坑完整写出来给正在纠结“买现成CRM还是自建”的朋友一个真实的参考样本。需要先说清楚DeskcommCRM不是一个挂出来的开源项目而是我们内部自研、私有化部署的crm客户管理系统。它能管理线索、客户、跟进记录、商机状态和合同回款支持多角色权限和数据隔离会生成销售漏斗和业绩报表。文章会重点拆解四个部分为什么放弃免费CRM选择自建、DeskcommCRM的核心数据模型和权限设计、员工邀请与团队落地实操、永久在线部署的具体方案。如果你想做同类系统或者正在评估“免费crm与私人网站的区别”这篇应该对你有直接用处。1. 为什么在免费CRM和自建系统之间我最终选了DeskcommCRM1.1 免费CRM看着省钱算完账之后最烧钱市面上免费CRM不少飞鱼CRM、纷享销客、销售易都提供免费版或试用版。当时我也下载过两三个让销售先用发现问题并不在功能而是在“它的免费版根本不是给你公司用的”。免费版的典型限制几乎一致客户数量卡在几百到一千条超过就要付费高级报表、批量导入、自定义字段、API接口这些真正影响效率的功能全部锁在付费墙后面数据存在服务商服务器上导出虽然能做但格式和字段损耗严重。最让我不能接受的是销售在免费版上辛辛苦苦录了几百条客户一旦停用或者升级收费版本导出数据结构对不上等于推倒重来。免费CRM的真正成本是迁移成本和信任成本。客户数据是公司最核心的资产放在别人服务器上服务商随时可以调整免费策略这不是危言耸听过去几年已经有好几家CRM厂商大幅收缩免费版权益。对一个小团队来说一开始省下的那点订阅费远不够弥补后续迁移、断供、定制折腾的代价。1.2 所谓“私人网站”本质是私有化部署的选择热搜里那句“免费crm与私人网站的区别在哪”其实戳中了关键很多人在搜索“私人CRM网站”这个概念。这里的“私人网站”指的就是自建、自部署、自有数据库的系统对应到我们做的就是这类。免费云CRM和私有化部署CRM的区别我用一张表讲清楚对比维度免费云CRM私有化部署CRMDeskcommCRM数据存储服务商服务器自己的数据库数据所有权归服务商/平台可被用于分析完全归公司字段定制受限需付费解锁完全自定义功能扩展依赖官方API和生态自己改代码想加就加部署成本低注册即用需要服务器开发维护人力长期成本付费后不便宜数据锁定风险高一次性研发固定运维上线速度当天即可2-3周起步这个对比不是否定云CRM而是要看场景。如果你只要一个“记录客户名字电话”的工具那免费版够用如果你想真正把销售过程管起来并且希望数据沉淀成为公司资产私有化是必然方向。DeskcommCRM就是从“数据必须在自己手里”这个底线出发做的。1.3 最终拍板前我算过一笔三年期总成本账当时公司给我预算上限是每年三万第三方CRM的中档版本按15个坐席算一年差不多两万五三年7.5万而这还是销售人数不变的情况。一旦团队扩张到30人三年成本直接奔着15万以上走而且买到的永远是通用模板定制还得额外收费。我自己评估的自建方案是两台云服务器加域名证书一年不到6000块开发时间三周按我工资折算约1.5万后续维护每周最多半天。三年总成本约4万业务特殊需求随时能改数据完全自主。这笔账算完之后我几乎没有犹豫就决定动手做DeskcommCRM。当然前提是我本身是开发出身如果公司没有技术人力这个方案不成立请人开发或者深度配置开源系统更合适。2. DeskcommCRM核心设计客户模型、跟进闭环与销售漏斗2.1 技术栈选择基本是照着RuoYi的思路来的很多做Java后端的朋友都刷过RuoYi Office CRM这个项目我也参考过。RuoYi体系成熟用户、部门、角色、菜单权限一套齐全但对我来说偏重。我要的是一个轻量、和销售使用习惯完全匹配的系统所以最终DeskcommCRM采用了Spring Boot 3 MySQL 8 Redis Vue 3的组合。选Spring Boot是因为团队熟悉Java生态部署方便社区资料多Redis用来做登录会话和扫码登录的token缓存MySQL存业务数据。前端没有用重型UI框架直接Vue 3 Element Plus表格和表单组件够用销售用起来的学习成本低。整体架构非常简单——单体应用前后端分离没有上微服务和消息队列因为一个几十人用的内部系统根本不需要那套复杂度。2.2 客户表和线索表分开设计避免数据和权限混乱第一版DeskcommCRM我把客户和线索混在一张表结果很快出问题。销售每天录入的有电话咨询的陌生线索也有已经成单的老客户两者状态、跟进节奏、权限归属完全不同。后来拆成两张表线索表lead字段id、来源渠道、姓名、电话、微信、省份城市、产品意向、状态未分配/跟进中/已转化/无效、归属销售ID、创建时间、转化时间。客户表customer字段id、公司名称、联系人、电话、地址、行业、客户等级A/B/C/D、状态潜在/合作中/停用、归属销售ID、来源线索ID。拆分之后权限逻辑也清晰了线索默认公海池销售主管可以批量分配给销售转化后的客户归属到对应销售名下客户表按归属人做数据隔离。这是整个系统里最基础也最关键的一步如果一开始图省事不分表后面所有统计、漏斗、权限全部会拧巴。2.3 跟进记录是CRM的灵魂设计成独立流水表很多CRM系统把跟进记录只是当成客户详情页里的一个备注文本框这是巨大的反模式。跟进记录必须是一条一条的流水每次跟进都要有独立时间、方式、内容摘要和下一次计划时间。DeskcommCRM的跟进表follow_record字段id、客户ID、销售ID、跟进方式电话/微信/上门/其他、沟通摘要、下次跟进时间、关联商机ID、创建时间。每次新建跟进之后系统会自动更新客户表里的“最近跟进时间”和“下次跟进时间”销售首页的待跟进列表就是基于这个字段实时查出来的。这个设计带来的直接效果是销售每天打开系统就知道今天要联系谁不会出现“感觉这个客户好久没聊了但说不上来哪个该联系”的模糊感。管理者也能看到每个销售的跟进数量、覆盖客户数、平均响应时长数据化考核变得顺理成章。2.4 销售漏斗用状态机统计SQL实现不引入复杂引擎销售漏斗是商机阶段的体现。一个线索转化成客户之后如果近期有购买意向销售会为客户建立商机商机表opportunity字段包括客户ID、商机名称、预计金额、阶段初步接洽/需求确认/方案报价/谈判/赢单/输单、预计成交日期、赢单概率、归属销售ID。这里我走过的弯路是第一版想用工作流引擎把事情做得“完美”比如阶段变更要自动触发提醒、通知等。后来发现小团队根本不需要阶段就是一个状态字段更新时写SQL把对应记录update一下再统计每个阶段的金额总和漏斗就出来了。首页报表用一个SQL完成SELECT stage, COUNT(*) AS deal_count, SUM(expected_amount) AS total_amount FROM opportunity WHERE deleted 0 AND status 1 GROUP BY stage ORDER BY FIELD(stage, 初步接洽, 需求确认, 方案报价, 谈判, 赢单);不夸张地说DeskcommCRM有五成价值在这张漏斗图上。周会打开投影哪个阶段堆积了多少商机金额一目了然销售总监拍板优先级也有了数据依据比拍脑袋强太多了。3. 员工邀请与权限分配让团队顺畅用起来的关键设置3.1 从“飞鱼CRM怎么邀请员工”说起邀请流程设计在决定自研前我也研究过飞鱼CRM等产品“飞鱼crm怎么邀请员工”这个操作其实很简单——管理员在后台添加员工手机号系统发短信员工点链接激活账号。这个思路我当时借鉴了但做了改进因为对内部系统来说把手机号暴露给管理员再输入也够烦更顺滑的做法是邀请码注册。DeskcommCRM的员工邀请流程是管理员在系统“组织管理”页面点击“邀请成员”生成一个邀请链接链接里带一次性token。将链接发给新同事新同事打开后填写姓名、手机号、设置密码即可激活。激活时如果管理员已经提前选了“所属部门”和“岗位角色”新同事登录后界面即按权限展示如果没选默认归入“待分配”组。新同事第一登录时系统强制修改初始密码并绑定微信扫码开启二次验证。这个流程比逐个录入员工信息更快也避免离职员工账号仍挂在部门下没人管的场面。邀请链接的有效期我建议设置成24小时内有效一次性使用防止链接被转发滥用。3.2 角色权限不止“管理员/普通员工”两档数据范围是关键DeskcommCRM权限模型借鉴了RuoYi的通用设计但没有直接用它的全部逻辑因为销售场景需要更细的数据可见性控制。我最终采用的是RBAC 数据范围两层过滤。角色分为三类销售顾问、销售主管、超级管理员。销售顾问只能看自己名下的客户、线索、商机以及公海池中未分配的线索销售主管可以看本部门所有销售的数据并执行客户重新分配操作超级管理员可以看全部包括操作日志、登录记录、数据导出、系统设置。数据范围不是靠前端隐藏按钮实现的而是在后端所有查询SQL里强制带上了数据权限条件。比如销售顾问查询客户列表时MyBatis拦截器会自动在SQL后追加AND customer.owner_user_id #{currentUserId}这个必须由后端拦截不能依赖前端代码否则绕过前端请求就能越权查数据。这是整个系统里安全级别最高的一条红线谁都不例外。3.3 权限踩坑实录注解和拦截器同时开启导致的越权漏洞这里分享一个真实踩坑很有代表性。第一版DeskcommCRM的接口用了Spring Security的注解做权限校验同时又配置了一个全局拦截器统一判断登录状态。本来两者各管一摊但问题出在一个开放接口上导出客户Excel的Controller方法标了PreAuthorize(hasRole(admin))而全局拦截器里对部分URL做了“白名单”放行结果导出接口的URL碰巧在白名单中导致拦截器直接放行注解虽然还在但Spring Security的过滤器链在拦截器之后执行某些配置下注解校验被跳过了。这件事让我明白全局拦截器和注解权限不要混用更应该统一走Spring Security的过滤链用PreAuthorize做方法级校验全局拦截器只负责记录日志和基础 token 校验不要再重复判断角色。同时权限相关配置改动后必须做越权自测用低权限账号尝试访问高权限接口这个动作应该写进上线清单。3.4 操作日志和数据导出权限合规的最后一道防线销售团队对于数据导出这件事向来有争议销售希望导出自己客户名单做离线跟进管理担心客户资料外泄。DeskcommCRM的做法是导出功能仅主管及以上角色可用销售顾问只能在线查看不能批量导出所有导出操作都记录操作日志内容包含操作人、时间、导出条数、筛选条件。一旦出现离职员工带走客户名单的情况可以快速定位到是谁在什么时间导出了什么数据。操作日志表设计很简单一个接口层面的AOP切面对所有写了Log注解的接口统一记录。日志字段包括用户ID、方法名称、请求参数、执行时长、IP地址、操作时间。这个设计投入小但价值极大也是后来信息安全审查时能拿出证据的基础。4. 永久在线的crm网站部署架构与运维血泪4.1 “永久在线”不是口号部署最怕的是半夜宕机没人管很多人搜“永久在线的crm网站”其实是想要一个随时能访问、不会因为电脑关机就断线的CRM。自建系统最怕的就是“只有开发者的电脑开机时系统才在线”——一开始我确实犯过这个错把系统跑在自己的开发机上同事一访问就把我电脑卡死下午我关电脑下班所有人就用不了系统。所以DeskcommCRM必须部署到云服务器。我选的是两台4核8G的云服务器一台跑应用和数据库一台做备份和冷备切换。操作系统用的CentOS 7当时的主流选择现在建议Alibaba Cloud Linux / Ubuntu 22.04 LTS应用通过Docker容器化部署MySQL数据目录挂载到宿主机磁盘Redis做了持久化配置。4.2 用Nginx做反向代理再加域名和HTTPS很多内部系统上线后不太注意公网访问的安全直接IP端口访问。我的经验是不能用裸IP访问必须上域名HTTPS不只为了那个绿锁更是因为互联网上自动化扫描工具每时每刻都在扫3306、8080这些默认端口裸奔随时可能被入侵。DeskcommCRM的Nginx配置核心段如下server { listen 443 ssl http2; server_name crm.example.com; ssl_certificate /etc/nginx/cert/crm.pem; ssl_certificate_key /etc/nginx/cert/crm.key; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } server { listen 80; server_name crm.example.com; return 301 https://$host$request_uri; }4.3 数据库备份才是“永久在线”的真正底线在线是持续性要求备份是灾难恢复要求。我最担心的是数据库磁盘损坏、误删数据、被勒索脚本盯上。DeskcommCRM上线第一天就做了自动备份策略每天凌晨2点使用mysqldump导出全量SQL保留最近30天每周末一次全量备份并同步到另一台服务器的备份目录同步使用rsync加密传输。备份脚本核心逻辑#!/bin/bash BACKUP_DIR/backup/mysql DATE$(date %Y%m%d_%H%M%S) mysqldump -u backup -p密码 --single-transaction --quick --databases deskcomm $BACKUP_DIR/deskcomm_$DATE.sql find $BACKUP_DIR -type f -name *.sql -mtime 30 -delete rsync -avz --delete $BACKUP_DIR/ backup192.168.1.10:/backup/deskcomm/没人愿意在半夜经历数据丢失但没做备份之前你永远不知道这个恐惧有多具体。有次我误操作drop了一张分区表多亏前一天晚上的备份前后只用20分钟就恢复了99%的数据那之后再也没为数据安全性焦虑过。4.4 外网访问的内部系统安全组只放行必要端口安全组是云服务商提供的第一道墙这块不能省。我的规则只放行80、443端口MySQL的3306端口只有内网IP可以访问SSH的22端口改成了非默认端口并且只允许公司固定IP连接。Docker容器里数据库端口不映射到宿主机应用通过容器网络直接访问外部完全无法直接触碰数据库。在互联网上暴露的crm系统我每天都会看安全告警三个月下来发现被尝试扫描和暴力破解的行为有几千次大部分集中在22端口和常见Web路径。没有安全组和HTTPS这些扫描一旦命中弱口令后果就是整个客户数据裸奔。安全不是上线的最后一步而是部署架构的一部分。5. 与RuoYi Office CRM、飞鱼CRM的对比以及复盘后的几条教训5.1 开源方案和商业方案都研究过最后决定自研的真实原因做DeskcommCRM之前团队也认真讨论过直接用RuoYi Office CRM。RuoYi Office CRM功能确实全客户、商机、合同、回款、审批流程都有而且代码开放理论上可以二次开发。但它也有两个实际问题一是模块太重光菜单就有上百个销售反感复杂的操作路径二是它本身建立在通用后台管理框架之上销售场景的交互细节没有充分打磨需要改动的东西几乎等于重写前端。飞鱼CRM这类商业产品功能成熟、体验也不错邀请员工等功能开箱即用。但我还是担心数据安全和长期订阅成本。最终答案其实很清楚省时间买商业版省成本用RuoYi改要数据主权和完全贴合业务的系统就自研。DeskcommCRM走的是第三条路适合有技术团队、业务逻辑特殊、不想被厂商绑定的公司。5.2 实测效果撞单率从每周3次降为0销售响应速度提升8倍复盘DeskcommCRM上线后的业务数据最直观的变化有四个客户的录入动作从销售“愿意记”变成了“系统要我记”。因为线索分配后如果3天内没有首次跟进公海池会自动收回重新分配这个规则倒逼销售及时录入并跟进系统里的客户数据从上线前的约500条变成了现在的超过12000条。撞单率的问题以前每周至少发生2-3次销售为了一个客户争吵、甚至影响合作。现在客户录入系统即锁定归属另外一个客户如果要被第二个人操作系统会提示“该客户已被xx占用”并自动发送私信提醒真正做到了零撞单。销售对新客户的首次响应时长上线前靠微信回复平均要8小时上线后系统自动提醒新分配线索销售基本10分钟内就会查看实际响应时间降到了1-2小时。主管看板也能实时看到哪些线索超过2小时还没有人处理管理动作滞后问题大幅缓解。月度业绩统计原来需要运营同事占半天时间从Excel汇总现在报表页一键导出各销售、各产品的业绩数据财务和销售总监都省了不少事。这些数字不算夸张但我认为已经充分证明了小团队自建CRM的可行性。5.3 自建CRM最容易犯的错过度设计复盘整个DeskcommCRM项目最想提醒大家的是不要过度设计。第一版开发时我一度想加任务管理、项目协作、审批流程、知识库、工单系统后来冷静下来全部砍掉。CRM的价值在于把客户数据、跟进过程、销售结果管起来而不是做一个“大而全”的企业软件。我的建议是第一版只做线索池、客户列表、跟进记录、商机漏斗、员工权限、简单报表这六个模块跑通之后看业务反馈再加东西。DeskcommCRM上线近一年真正高频使用的功能也就是那六块。增加的字段和筛选基本是通过后台配置完成的没有频繁改代码。5.4 另外几条花钱买不来的经验一是别让销售觉得系统是在监控他们更有效的做法是让系统帮他们省时间。比如自动生成今日待跟进列表、自动同步下次跟进时间、自动提醒公海回收做完这些销售自然愿意用。强制要求他们每天填一堆没价值的字段只会让系统沦为形式主义。二是每次发版前把数据备份做了再发别问我是怎么知道的。有次更新SQL脚本里少写了个where条件导致状态字段被批量更新花了一上午恢复。三是定期给团队做轻量培训。我在DeskcommCRM落地后专门给销售开了三次短会每次只讲一个场景怎么建客户、怎么记跟进、怎么看自己的业绩目标。别丢一本操作手册让他们自己看效果基本为零。四是要有一个“用户反馈群”销售在使用中遇到的问题哪怕是“这个按钮颜色太浅找不到”这种细节也要记录下来及时改。系统是给人用的不是炫技术的小细节的优化往往最能赢得用户口碑。走到这一步DeskcommCRM已经从最初的一个应急工具变成了公司销售管理体系里不可缺失的基础设施。它未必适合所有公司但如果你也面临着客户数据分散、撞单频繁、团队扩大之后管理失控的问题我的经验是自建一套轻量CRM的ROI远高于直接订阅通用付费CRM。先跑通最小闭环再迭代优化这套思路对我适用大概率也适合你。
