1. 为什么我最终选了 DeskcommCRM 而不是继续用 SaaS 免费版CRM 这个词在国内其实被说烂了。市面上的免费 CRM 一抓一大把蝉鸣、飞鱼、还有各种挂着免费标签的 SaaS 系统注册就能用。但你真正把客户资料录进去之后心里总会有点不踏实。尤其是当你带着团队一起用数据越存越多你会发现所谓免费其实是有隐性成本的。我自己的经历是这样的一开始用的是某款 SaaS 免费 CRM客户数到了上千条之后原本的免费额度突然不够用了要么付费要么删历史数据。再想导出客户资料后台给的是加密格式转出来乱成一团。那时候我就意识到客户数据这种命根子不能放在别人手里。后来开始折腾自建方案最后选择了 DeskcommCRM一套我能完全掌控、永久在线、免费部署的客户管理系统。先说明一下 DeskcommCRM 的定位它不是那种需要你自己写代码的框架而是开箱即用的客户管理应用支持客户资料、商机跟踪、工单处理、员工协作这些核心模块。部署在自己的服务器或者云主机上数据在自己的地盘里想怎么折腾都行。这个过程里我踩了不少坑但也摸出了一条比较顺的路这篇文章就当作一份完整的落地笔记分享出来。1.1 SaaS 免费 CRM 的隐形代价你其实在给平台打工很多人用 SaaS CRM 的直观感受是注册即用、界面漂亮、更新快这些确实是优势。但免费版通常有几个绕不开的坎客户数量上限。一旦你的客户池超过一定量级系统会提示你升级而升级价格通常不便宜。自定义字段非常有限。销售团队最需要的客户来源成交概率下次跟进时间等等免费版往往只给固定字段改不了。数据导出不自由。有的平台允许导出但格式混乱有的平台干脆不支持完整导出你进去的是数据出来的是一个个不能关联的表格。员工席位限制。免费版往往只能开 2-3 个账号团队稍微大一点就必须付费。我个人的观点是如果你只是一个人做点小生意SaaS 免费版完全够用。但如果你要长期积累客户资产或者需要和团队一起协作那数据掌控权比好用二字重要得多。这也是我转向自建 CRM 的根本原因。1.2 自建 CRM 与私人网站的核心区别不是好不好看而是数据归谁热词里有个很有意思的问题免费 CRM 与私人网站的区别在哪。我理解这个私人网站指的就是自己拥有域名、服务器、程序的独立站点。其实很多搞不清这件事的人会误以为 CRM 是某种网站后台或者在线表格。实际上两者的区别非常实在私人网站自建站点的核心是我自己控制一切——域名是我的服务器是我的程序装在我手里数据库的读写备份都由我负责。CRM 是运行在私人网站之上的一种业务应用它解决的问题是客户信息怎么管理、销售流程怎么推进、团队怎么协作。自建 CRM 除了具备私人网站的所有权优势还多了一层业务逻辑的定制能力。比如 DeskcommCRM 的客户字段、审批流、通知规则我可以直接改配置文件甚至二次开发。简单类比一下SaaS CRM 就像住酒店拎包入住但房间里的东西不是你的退房时只能拿走随身物品自建 CRM 就像自己盖房子装修、布局、门锁都由你决定住一辈子也没人赶你走。1.3 DeskcommCRM 在选型中的位置比框架轻比表格重我在选型时对比过几类方案直接用低代码平台搭、用开源的通用型 CRM 二次开发、以及用 DeskcommCRM 这样的成品系统。最终选择 DeskcommCRM原因是它在灵活度和上手速度之间找到了一个平衡点。如果用语言来形容低代码平台像积木什么都能搭但搭出来总是有种临时感性能和数据结构也不够扎实开源通用型 CRM 像毛坯房功能很全但需要装修配置起来非常耗时DeskcommCRM 则更像一套精装修交付的房子你可以直接住进去也能在局部重新规划。它内置了客户管理、联系人、商机、工单这些常见模块并且提供了比较清晰的权限机制。对大多数中小团队来说这已经覆盖了日常销售和售后服务的大部分场景。2. 部署前必须想清楚的三个问题服务器、域名、长期在线很多人一听说自建 CRM第一反应是很难吧。其实部署本身没有那么复杂真正需要提前想清楚的是下面这三件事服务器放哪、域名怎么配、以及如何保证系统永久在线。这三件事如果没想明白后面会不断返工。2.1 服务器选型与配置别贪便宜买最低配DeskcommCRM 这类系统对服务器的要求不算高但也不是随便一台 1核1G 的小机器就能流畅跑起来。我第一台测试服务器就是最低配的 1核1G装完之后系统占用长期在 80% 以上客户列表一刷新要等两三秒体验很差。我建议的最低配置是这样的场景CPU内存硬盘带宽个人试用1核2G20G SSD3Mbps小团队正式使用2核4G50G SSD5Mbps50人以上团队4核8G100G SSD10Mbps以上内存是关键。CRM 背后一般有数据库和 Web 服务内存不够会频繁触发 swap表现就是卡。硬盘一定要选 SSD机械盘在数据库随机读写时差距极其明显。如果你的用户在国内服务器地域优先选国内需要备案或者香港不需要备案但有网络波动风险。我不建议为了省几十块钱选太冷门的区域晚高峰延迟会让你怀疑人生。2.2 域名与 HTTPS永久在线的基础体验系统装好后如果你用 IP 地址直接访问会面临两个问题一是浏览器会拦截因为现代浏览器对非 HTTPS 的站点越来越不友好二是你发链接给同事IP 地址很难记也容易被当成垃圾链接。所以域名不是选配是标配。国内云厂商买一个 .com 域名一年也就几十块钱然后通过 Lets Encrypt 等工具签免费 SSL 证书配置好 HTTPS 之后就一劳永逸了。我这里有一个实际操作建议解析域名时把裸域example.com和 www 子域都指向服务器然后在 Web 服务器配置里把 www 统一重定向到裸域避免同事一会儿用 www 访问、一会儿不用登录态来回跳。2.3 永久在线的底层逻辑进程守护比手动重启靠谱永久在线的 CRM 网站这个热词其实反映了一个刚需系统不能动不动就挂掉。自建系统最大的不稳定因素并不是程序本身而是进程会不会因为内存溢出、异常退出等原因死在后台没人管。解决这个问题的标准做法是使用进程守护工具比如 systemd 或者 Supervisor。我自己用的是 Supervisor配置非常简单[program:deskcomm] command/usr/bin/php /var/www/deskcomm/artisan serve --host0.0.0.0 --port8000 directory/var/www/deskcomm autostarttrue autorestarttrue startsecs3 stderr_logfile/var/log/deskcomm_err.log stdout_logfile/var/log/deskcomm_out.log这样配置后只要进程异常退出Supervisor 会在几秒内自动拉起。配合一个简单的定时健康检查脚本比如每隔 5 分钟访问一次某个监测 URL如果返回异常就重启服务基本能做到很长时间不用人工干预。要注意的是进程守护工具本身也需要设置为开机自启。我用systemctl enable supervisor一步搞定这样云主机重启后CRM 也能自动恢复在线状态。3. DeskcommCRM 安装与初始化用 Docker 一次性搞定环境环境准备是自建系统最勸退人的环节。我最早手动安装 Nginx、PHP、MySQL折腾了一整天最后还是因为 PHP 扩展版本不对出了问题。后来换了 Docker 方案无论是安装速度还是可复现性都有了质的提升。这里我推荐直接走 Docker 路线省下大量重复配置的时间。3.1 快速部署一条命令拉起整套环境在服务器上安装好 Docker 和 Docker Compose 之后准备一个docker-compose.yml文件内容大致如下version: 3.8 services: app: image: deskcomm/deskcomm:latest ports: - 8000:8000 environment: - DB_HOSTmysql - DB_DATABASEdeskcomm - DB_USERNAMEdeskcomm - DB_PASSWORDchange_me depends_on: - mysql volumes: - deskcomm_storage:/var/www/deskcomm/storage mysql: image: mysql:8.0 environment: - MYSQL_DATABASEdeskcomm - MYSQL_USERdeskcomm - MYSQL_PASSWORDchange_me - MYSQL_ROOT_PASSWORDroot_change_me volumes: - mysql_data:/var/lib/mysql volumes: deskcomm_storage: mysql_data:然后执行docker compose up -d等服务启动完成后浏览器访问http://服务器IP:8000就能看到安装界面。第一次安装需要填数据库连接信息按上面环境变量里的内容填就行。这个过程看起来简单但有几个特别容易被忽略的地方。第一服务器防火墙要放行 8000 端口否则外部访问不到。第二MySQL 8.0 默认的认证插件在某些老版本客户端下会连不上如果你用远程可视化工具连接数据库遇到报错时记得检查认证方式。第三Docker 卷的备份一定要保留数据都存在这些卷里容器删了重启都没关系卷误删就真完蛋了。3.2 初始化配置管理员账号和公司信息安装完成后第一步是创建管理员账号。这里我强烈建议管理员账号不要用 admin 这种通用用户名因为自动化攻击脚本会优先尝试这类账号。用一个带字母数字组合的用户名密码长度至少 12 位并且包含大小写和特殊符号。接下来是公司信息设置。DeskcommCRM 默认的时区是 UTC如果你用的是国内服务器或者面对国内客户记得在后台把时区改成Asia/Shanghai日期格式改成Y-m-d否则系统里记录的跟进时间会比实际时间慢 8 小时很容易误判客户最后联系时间。3.3 默认模块梳理先别急着改跑通默认再定制初始化完成后系统会自带客户、联系人、商机、工单等模块。我的建议是第一次登录时不要急着去改各种字段、加各种状态先用默认配置跑一遍完整流程。原因很简单默认配置是经过大量使用场景验证的你先顺着它录几个测试客户、创建一条商机、模拟走一遍工单就能发现哪些地方适合你的业务哪些地方需要改。如果你一开始就按自己的想法大量定制后面反过来查问题时很难分清是配置问题还是系统问题。我自己就是先跑通了录入客户 → 建立商机 → 跟进记录 → 关闭商机这条链路之后才对字段和流程做了调整。这比空想配置要高效得多。4. 核心业务配置客户字段、商机阶段与工单流转DeskcommCRM 真正好用的地方在于它允许你把销售和售后过程拆成可见的流程。但默认配置只是通用模板具体到不同行业你需要根据实际业务做适配。这一节我分享一些我自己在配置过程中总结出来的经验。4.1 客户字段设计少而精准别把 CRM 做成 Excel客户模块是最容易被人为搞复杂的。很多团队一开始恨不得把所有信息都塞进去公司注册号、法人姓名、税号、地址、多个联系电话、备注……结果真正录数据的时候谁都嫌麻烦最后表格里全是空字段。我建议每个团队做一次字段清理只保留三个维度第一是联系维度电话、邮箱、微信/企微第二是业务维度客户来源、所处行业、客户等级第三是跟进维度负责人、下次跟进时间、最近跟进日期。在 DeskcommCRM 里你可以把不需要的字段隐藏而不是删除这样既不影响历史数据又能让录入界面清爽不少。我给团队规定的原则是录客户资料的时间不要超过 30 秒如果超过说明字段太多了。4.2 商机阶段与权限把流程感做出来商机模块是整个 CRM 的核心它决定了销售团队怎么看待自己的业绩。DeskcommCRM 默认商机阶段一般是初步沟通 → 需求确认 → 方案报价 → 商务谈判 → 赢单/输单这是一个标准的销售漏斗。但不同行业阶段差别很大。做项目制销售和做快消品销售漏斗是两回事。所以务必要把阶段改成自己团队实际用的那一套并且每一步都要有明确的动作要求比如方案报价阶段必须上传报价单附件否则不能进入下一阶段。权限设置是个容易被忽视的点。我的建议是普通销售只能看到自己名下的商机销售主管可以看到团队所有商机老板和管理员可以看到全部。DeskcommCRM 的角色权限支持到字段级别你可以设置敏感字段比如成交金额仅限管理员查看。这样既保护了数据安全也避免了团队成员之间的互相攀比心理。4.3 工单流程与通知售后别靠微信语音很多小团队做售后都是用微信群客户一发消息客服就在群里艾特技术。这种方式在客户量小的时候勉强能转客户一多必乱。DeskcommCRM 的工单模块可以解决这个问题客户提交问题生成工单分配给指定工程师整个过程有记录、有状态、有超时提醒。我配置时给工单设了几个状态待分配、处理中、等待客户反馈、已解决、已关闭。每个状态都有对应的通知规则比如待分配如果超过 2 小时没人处理系统就自动提醒主管。这比人工盯着微信群可靠多了。还有一点很实用工单和客户、联系人、商机是关联的。你点开一个客户资料能看到这个客户名下所有历史工单包括上次解决了什么问题、处理人是谁。这个能力是微信沟通完全无法替代的。5. 团队协作员工邀请与权限分配的完整操作热词里有人问飞鱼 CRM 怎么邀请员工其实这个问题在所有 CRM 里都很常见。你部署完系统只是第一步真正让团队用起来关键在于员工账号怎么开通、权限怎么给、数据怎么隔离。DeskcommCRM 在这块的做法是清晰的但也需要管理员花点心思。5.1 添加员工账号两种方式各有适用场景DeskcommCRM 支持两种员工账号添加方式管理员手动创建。在后台用户管理里点击添加用户填入姓名、邮箱、初始密码然后勾选角色即可。头像可以先不传员工自己登录后修改。邀请链接注册。管理员开启邀请功能后生成一个带有效期的邀请链接发给员工。员工通过链接自己注册填写基本信息后提交管理员审核通过后才算正式激活。我的建议是如果团队人数不多5人以内直接手动创建最省事如果团队成员经常变动就用邀请链接避免离职员工的账号信息散落在各处。5.2 角色权限配置实例销售、主管、售后、管理员DeskcommCRM 的角色权限模型比较典型我一般按四个角色来搭角色客户权限商机权限工单权限数据范围销售查看/编辑查看/编辑查看仅自己创建的销售主管查看/编辑查看/编辑/关闭查看部门下属所有售后专员查看查看查看/处理被分配的工单管理员全部全部全部全部数据具体在权限界面配置时每个模块都有查看自己的、查看团队的、查看全部的三个档位还有增加、删除、导出等独立权限。我的原则是最小够用你先给员工最小权限如果他说某个功能用不了再开。反过来一开始就给全部权限后面收权时容易引发矛盾。5.3 员工登录与安全二次验证不是可选项账号开通之后要让员工养成一个好习惯开启二次验证。DeskcommCRM 支持基于时间的一次性密码验证用常见的身份验证器 App 扫码绑定就能开启。我强烈建议强制所有员工开启原因很简单CRM 里沉淀的是整个公司的客户资产一旦销售同事的账号被人登录进去所有客户信息、报价记录都会泄露。这个损失远超让人多输入一遍验证码的成本。另外还要注意员工离职时要在禁用账号的基础上第一时间转移他们名下的客户和商机负责人。DeskcommCRM 支持批量转移功能管理员可以把离职员工的数据一键移交给接任者避免客户跟着人走。这个操作一定要在员工离职当天完成别拖。6. 实测中的常见问题与排查记录用了半年多DeskcommCRM 整体很稳但也不是没有遇到问题。这一节我把自己实际踩过的几个坑和处理思路整理出来如果你也遇到类似情况可以参考排查链路而不是直接搜报错。6.1 邮件通知发不出去不是程序 bug是发信配置问题第一次配工单通知时系统提示邮件发送失败我第一反应是去看代码日志。折腾了半小时最后发现问题出在 SMTP 配置上我用的邮箱服务商要求必须开启客户端授权码才能通过 SMTP 发信单纯用登录密码是不行的。解决思路先去后台邮件配置里填对 SMTP 服务器、端口和加密方式然后检查服务商是否允许使用客户端授权码。如果还是失败用命令行工具单独跑一次 SMTP 测试脚本确认是服务器到邮件服务商的网络问题还是认证信息问题。我就是用这种方式一步步排除掉的千万别上来就改程序文件。6.2 备份恢复后数据不完整容器卷备份的细节有一次我手动备份了 MySQL 容器的数据卷然后在另一台机器上恢复结果客户资料都在但上传的附件全丢了。后来才意识到附件存在的是应用容器的 storage 卷里和数据库卷是分开的我备份时漏掉了它。正确的备份姿势是备份时同时导出 MySQL 数据和deskcomm_storage卷里的附件目录。如果你用 Docker 命令备份应该把两个卷都打包或者干脆直接用docker compose配置里的卷目录做全量快照。恢复时也要先恢复数据库再恢复附件否则附件路径对不上。6.3 移动端打开界面错乱临时用手机壳 pwa 模式解决默认界面在手机浏览器上打开时表格会因为屏幕太窄而错位。这个问题我一开始以为要专门写一套移动端页面后来发现 DeskcommCRM 自带响应式布局只需要在浏览器里把页面缩放到合适比例或者在手机上用桌面版模式访问就能获得不错的体验。如果你希望员工在手机上更方便地使用可以把系统添加到手机主屏幕。支持 PWA 的应用在浏览器菜单里选择添加到主屏幕后打开后是全屏显示体验接近原生 App。DeskcommCRM 在这方面做得不错我的几个销售同事就是靠这个方式在外面拜访客户时直接在手机上报备进展工作效率提升明显。6.4 定期维护清单每天看备份每周查日志最后分享一个我自己的维护习惯。每天花 5 分钟确认备份任务是否执行成功看有没有失败的邮件告警每周花 10 分钟翻一下访问日志重点关注异常登录尝试每月做一次数据库清理把已完成超过一年的工单归档保持系统运行流畅。这套系统部署到现在已经稳定运行了大半年。客户数据全部掌控在自己手里团队协作有了统一平台员工权限清晰售后流程也没有再漏单。直到现在我都觉得当初从 SaaS 免费 CRM 转到自建方案的决策是对的。如果你也在纠结要不要自建 CRM我希望这份笔记能帮你少走点弯路。别被部署两个字吓到按照上面这些步骤一天之内完全可以跑起来。
