最近朋友的工作室在找人搭客户管理系统他上来就问了一句“有没有那种免费的CRM最好不用每个月交钱客户资料也别放在别人服务器上。”这个问题我回答过好多回了干脆把这一轮的调研和落地过程整理出来。我最后选的是DeskcommCRM这套可以自部署的方案把它装在自己的服务器上做成一个真正“永久在线”的CRM网站。下面从选型逻辑讲到部署实操再聊到员工邀请、权限分配最后把踩过的坑一并列出来希望能给同样在纠结CRM选型的人一点参考。1. DeskcommCRM到底是什么先别急着聊功能1.1 它不是SaaS而是一套可以搬回自己家的CRMDeskcommCRM这个项目定位上和动辄按年付费的云端CRM不一样。它本质上是一套基于Web架构的客户关系管理系统你可以把整套代码跑在自己的服务器上浏览器登录就能用。简单说它解决的是“客户数据到底放在谁手里”的问题。我自己的理解是它适合三类人第一类是客户数据比较敏感的小型团队比如做代账、做专利代办、做B端咨询的客户联系方式放到第三方平台总有点不踏实第二类是受够了某些免费CRM各种限制的团队比如用户数超过几个人就要收费、导出数据要开会员、看报表还要单独买模块第三类是有一定技术能力、愿意自己折腾的人或者是愿意花小钱找一个懂服务器的人帮忙搭好的人。核心模块其实不复杂客户档案、线索管理、跟进记录、商机阶段、报表看板。和Salesforce那种重型平台比它少了一堆用不上的高级功能和蝉鸣CRM这类云端产品比它又多了“部署在自己域名下”的自主权。对我来说“够用”加上“数据可控”这两点比功能大而全更打动我。1.2 和传统云端CRM的差别不在功能在归属感传统云端CRM比如蝉鸣CRM好处是上线快注册账号就能用手机端、企业微信集成这些也都现成。代价是什么客户数据存在别人的数据库里你拥有的是“使用权”而不是“所有权”。一旦厂商调整收费策略、停止维护甚至某一天服务下线你的客户资产就很被动。DeskcommCRM这套自部署方案整套系统跑在自己的服务器和域名下数据文件也都在自己手里。数据库里有多少客户、谁登录过、导出过什么自己都能查清清楚楚。它不需要按用户数付费不管团队是5个人还是50个人软件这个层面的费用是固定的。当然有得必有失。自部署意味着你要自己解决服务器、域名、HTTPS证书、数据库备份这些事。如果你完全没碰过Linux没接触过Docker那就得先花半天熟悉环境或者找懂行的朋友帮忙。但一旦把环境跑通后面基本就是一劳永逸的事。2. “永久在线的CRM网站”背后免费与私人自建的账要算明白2.1 免费CRM看起来很香但隐性成本一点不少这几年“永久在线的crm网站”这个说法越来越流行我的理解是大家被免费SaaS的“免费”两个字坑怕了。免费CRM的套路通常是基础功能免费但客户数量上限卡在几百条销售成员超过两人就要付费自定义字段要升级套餐连品牌水印都去不掉。等你把数据录进去、同事都用习惯了再想迁移出来各种导出限制又来了。更麻烦的是数据安全和长期运营问题。免费产品为了活下去要么插广告要么引导你升级付费。哪天这个产品调整方向服务器停掉你的客户数据说没就没。业务数据不是闲聊记录丢一次就可能直接把销售线打垮。所以很多做业务的人最后都转去问“免费crm与私人网站的区别在哪”本质上是想找一个更可控的方案。2.2 私人自建CRM网站一次投入长期受益所谓私人网站在这里指的就是部署在自有服务器、通过自己域名访问的自建CRM。它的核心优势是“自主”。客户数据放在自己的数据库里访问入口是自己的网址员工账号自己管理空间、字段、流程都可以按业务来改。相比免费CRM的“寄人篱下”自建CRM更像是“自己盖房子”。用表格来看两边差别更直观对比维度免费云端CRM自建/私人CRM网站初始成本零门槛注册即用需要服务器费用、域名费用长期费用升级/扩容后按年付费服务器续费为主软件成本固定数据归属在厂商服务器受其政策影响在自己服务器完全可控功能定制受平台限制只能用它给的可改代码、可接数据库、可加字段上线速度半小时搞定需要部署通常半天到一天维护门槛厂商负责无需关心自己负责备份、安全、升级用户数限制常见“限几人免费”只要服务器扛得住不限制2.3 选型结论按团队规模和敏感度来定没有哪个方案是绝对最优的关键看你的业务形态。如果你是单人销售或者对数据敏感度不高只是需要一个记录客户的地方免费CRM完全够用没必要折腾服务器。但如果你和我一样手里积攒了大量客户资料团队又不止你一个人那么“免费CRM与私人网站的区别”就会直接体现到数据安全性上。我的建议是10人以下的微型团队且未来两年不打算扩太多优先考虑自建30人以上、需要复杂审批流和移动端深度集成的团队反而是蝉鸣CRM这类成熟SaaS更省心。规模再大那基本就是企业级采购了不是这篇博客能聊完的。# 3. 实操把DeskcommCRM部署成自己的专属系统3.1 环境准备一台服务器、一个域名、一个清晰地头脑先列一下我这次部署用到的基础设施服务器Ubuntu 22.04的VPS2核4G内存40G SSD这个配置带一个20人以内的团队绰绰有余。域名crm.example.com提前把A记录解析到服务器IP。软件环境Docker和Docker Compose后面会用到。数据库PostgreSQL 15业务数据统一放里面。为什么选Docker而不直接在系统里装依赖DeskcommCRM依赖的组件不少有Web后端、前端静态文件、数据库、缓存。如果直接装原生的每个组件的版本兼容性都能让人折腾一晚上。用Docker Compose把这些容器编排在一起一条命令启动后续升级也方便出错了大不了把容器删了重新拉干净利落。3.2 用Docker Compose一条命令拉起整个环境我习惯先给项目建一个独立目录再在里面写配置文件mkdir -p /opt/deskcomm cd /opt/deskcomm然后创建docker-compose.ymlversion: 3.8 services: db: image: postgres:15-alpine container_name: deskcomm_db restart: always environment: POSTGRES_DB: deskcomm POSTGRES_USER: deskcomm_user POSTGRES_PASSWORD: 用一段足够复杂的密码代替 volumes: - db_data:/var/lib/postgresql/data app: image: deskcomm/crm:latest container_name: deskcomm_app restart: always depends_on: - db environment: DB_HOST: db DB_PORT: 5432 DB_NAME: deskcomm DB_USER: deskcomm_user DB_PASSWORD: 和上面保持一致 SECRET_KEY: 生成一个随机字符串 BASE_URL: https://crm.example.com ports: - 8080:8080 volumes: db_data:两个关键点说一下。POSTGRES_PASSWORD和SECRET_KEY都不是随便填的。密码可以用openssl rand -hex 16生成SECRET_KEY是系统用来加密会话和敏感数据的强度直接关系到账号安全别用admin123这种。文件写好后执行docker compose up -d第一次启动会拉取镜像输出一堆日志。等一两分钟执行docker compose ps看到两个容器都是Up状态就说明服务起来了。3.3 初始化配置公司信息、客户字段、数据导入容器启动后浏览器访问http://服务器IP:8080会看到初始化页面。第一步是创建管理员账号这个账号是全系统的最高权限密码建议用密码管理器生成别指望自己记。第二步是填公司名称和默认币种。这里要提醒一下公司名称会显示在系统所有界面和自己的报表里先确认好英文名还是中文名后面改起来虽然不难但没必要多折腾。第三步是配置客户资料字段。DeskcommCRM默认给的字段是客户名称、联系人、电话、邮箱、来源渠道、所属销售、跟进状态。我建议额外加两个常用字段客户等级高、中、低和下次跟进日期。尤其是“下次跟进日期”这个字段配合列表筛选能直接变成销售人员的待办清单比翻聊天记录高效得多。第四步是历史数据导入。系统支持CSV文件批量导入我给的字段顺序和表头处理方式是这样的客户名称,联系人,电话,邮箱,来源渠道,跟进状态,客户等级,下次跟进日期 某某科技有限公司,王经理,138xxxx0000,wangexample.com,百度推广,意向中,高,2025-03-01 某某贸易公司,李总,139xxxx1111,liexample.com,老客户转介绍,已成交,高,2025-02-20导入的时候有一个坑CSV编码必须是UTF-8如果之前用的是Excel生成的CSV大概率是GBK编码直接导入会乱码。解决方法是先用记事本或VS Code另存为UTF-8格式再上传。3.4 配置域名和HTTPS让CRM网站“永久在线”默认用IP加端口访问自己测试没问题但真要给团队成员每天用还是得把域名和HTTPS配好。我这次直接用Caddy来做反向代理它的一个优势是自动申请和续期SSL证书不用手动碰证书文件。在服务器上装好Caddy后创建一个Caddyfilecrm.example.com { reverse_proxy localhost:8080 }然后启动Caddy。等十几秒访问https://crm.example.com证书自动生效地址栏出现小锁这个配置就算成了。为什么要专门说这一步因为很多人部署完发现只能用IP访问同事在外地用的时候网络环境复杂HTTPS能避免数据被中间人截获登录密码、客户手机号这些都是敏感信息。而且一个正经的域名比一串数字IP好记多了光是让销售同事记住网址这一点就值得花这两分钟。4. 团队协作邀请员工加入的完整流程4.1 员工邀请的第一步不是发链接是先定角色DeskcommCRM在团队协作上的思路很清晰先有角色再有账号。系统里默认有四种角色管理员能改设置、能看所有客户、能导出全部数据。销售主管能查看自己团队所有成员的客户能做数据审批。销售坐席正常操作客户、记录跟进但只看得到分配给自己和共享给自己的客户。只读访客比如老板的助理、财务人员能看报表和客户资料但不能修改跟进记录。这其实和飞鱼CRM邀请员工时的逻辑很像很多老牌CRM都有类似的角色体系。我的建议是一开始别嫌麻烦宁愿多建几个角色把权限边界划清楚。免得半年后团队变大内部为了“谁能不能看这个客户”吵架到时候再调整权限数据边界早就乱套了。4.2 邮件邀请还是手动建号员工加入系统有两种常见方式邮件邀请和手动建号。邮件邀请适合有公司邮箱、团队协作规范的场景。流程是管理员在“成员管理”页面输入员工邮箱点击发送邀请。系统会给员工邮箱发一封带激活链接的邮件员工点进去设置自己的登录密码就算激活了。手动建号适合临时用户、或者还没有配置邮件服务的场景。管理员直接在后台创建账号填一个初始密码发给员工员工第一次登录后强制改密码。4.3 实操SMTP配置和邀请发送步骤邮件邀请需要先配置SMTP服务这样DeskcommCRM才能自己发信。我这次用的是阿里企业邮的SMTP配置项如下SMTP服务器smtp.qiye.aliyun.com端口465SSL加密账号通知邮箱地址密码该邮箱的授权码或独立密码在系统“设置-邮件服务”里填好这些信息然后保存。接下来去“成员管理”页面点击“添加成员”。输入员工姓名和邮箱。选择角色销售坐席、销售主管等。点击“发送邀请邮件”。员工收到邮件后点击链接设置密码就能登录了。整个流程下来两分钟不到比传统的手动建号再重置密码正规多了。如果邮件一直发不出去可以临时用“复制邀请链接”这个功能。系统会生成一个一次性链接私发到员工微信或钉钉上员工点开链接自己设密码效果和邮件邀请几乎一样。4.4 权限落地后怎么让员工快速上手新手最容易困惑的是“我该从哪里开始点”。在DeskcommCRM里我建议给员工发一份最简单的操作指引不要提功能列表只要三步登录后先看“今日待跟进”列表这里是根据你设置的“下次跟进日期”自动过滤出来的每天打开就是当天要打的电话。添加或打开一个客户在“跟进记录”里写清楚沟通结论下次跟进日期要按照这次聊的情况更新。每天下班前看一眼“我的客户”列表确认明天有明确动作没有动作的客户就标记状态让主管能看到。这里特别说一下权限落地后的审计问题。销售团队最怕的不是员工不够勤快而是撞单或者客户资源被带走。所以在系统里要让管理员定期看“操作日志”谁在什么时候导出过客户数据、谁改过客户负责人都有记录。真要出了事至少能查出个来龙去脉。5. 常见问题与排查技巧实录5.1 邀请邮件总是收不到可能是这三个原因第一个原因是邮件服务没配置成功。检查方式很简单在“邮件服务”设置页面点“发送测试邮件”看收件箱能不能收到。如果测试邮件本身收不到优先检查端口和授权码特别是465端口是不是被服务器防火墙拦截了。第二个原因是邮件被丢进了垃圾箱。有些企业邮箱对自带域名的自建系统发信比较敏感容易被判定为垃圾邮件。这个可以在邮箱域名管理里配置SPF和DKIM记录让邮件服务商确认“这封信确实是你家域名发出的”。配置方法各家邮箱不一样搜一下“域名解析 SPF 记录”就能出来。第三个原因是最容易被人忽略的员工邮箱拼写错误。看着简单但团队里同名同姓多的时候把zhang.san发成了zhang.san2就等着对方问“我怎么没收到”。5.2 部署完成但页面打不开怎么排查页面打不开是自建系统最常见的问题先别慌按顺序检查服务器安全组和防火墙有没有放行对应端口我用的是云服务器阿里云和腾讯云都有安全组策略只开放常见端口装Caddy之后要放行80和443。Docker容器是不是真的活着执行docker compose ps如果某个容器状态是Exited去看日志docker compose logs app | tail -100绝大多数错误原因都在里面。数据库连接成功没有DeskcommCRM刚启动时如果连不上数据库Web服务会一直报错。检查一下环境变量里的DB_HOST是不是写成了localhost容器之间通信要用服务名db不是写本机地址。这套排查逻辑同样适用于其他自部署系统把“容器状态、日志报错、端口连通性”过一遍80%的问题都能定位。5.3 多人同时编辑客户资料会不会互相覆盖销售团队同时跟进一个客户或者主管帮下属修正客户信息的时候很可能两个人同时在同一个客户页面里编辑然后后保存的人把先保存的人的内容覆盖掉了。DeskcommCRM在底层做了一部分防冲突机制但更实际的解决办法是提前约法三章谁负责的客户更改资料前先和对方沟通主管改下属的客户信息时在跟进记录里写一句“调整了客户等级理由是什么”。这看起来是管理问题不是技术问题但真出了事去数据库里翻记录远不如当初多点一下记录来得省事。5.4 数据备份没备份的自建系统等于裸奔免费云端CRM的数据安全由厂商负责自建系统的话备份就千万别省略。我用的备份方案是每天凌晨用crontab定时执行数据库备份保留最近30天的备份文件再同步到对象存储。备份脚本大致长这样#!/bin/bash DATE$(date %Y%m%d) docker compose -f /opt/deskcomm/docker-compose.yml exec -T db \ pg_dump -U deskcomm_user deskcomm /opt/backups/deskcomm_$DATE.sql find /opt/backups -name *.sql -mtime 30 -delete写入crontab每天早上3点执行0 3 * * * /bin/bash /opt/backup.sh恢复的时候也很直接cat deskcomm_20250201.sql | docker compose -f /opt/deskcomm/docker-compose.yml exec -T db \ psql -U deskcomm_user deskcomm这个习惯我建议每次部署任何数据库系统都做别信自己“最近不会出问题”的直觉真遇到问题的时候再后悔就没得后悔了。6. 再分享一点个人经验这次把DeskcommCRM部署成自己的CRM网站整个过程不算复杂但也确实要花心思。我的体会是选型这件事功能列表永远是第二位的第一位是你要搞清楚客户数据放在谁手里你会不会睡得踏实。对我这种做服务、做咨询的人来说答案是显而易见的。另外给几个小建议如果团队里没有技术背景的人第一次部署最好找懂服务器的朋友陪着弄一次后面日常维护就是看看备份日志的事别一上来就追求功能大而全先让销售同事们把客户资料、跟进记录、下次跟进日期这三个动作做标准比任何花哨模块都有用最后把管理员密码、服务器SSH密钥这些信息单独存在密码管理器里别用微信收藏夹存。真到要用的时候你会发现这一条价值千金。