从免费SaaS到自建CRM：DeskcommCRM实践指南与永久在线部署全记录

开始之前，先说说我为什么会碰DeskcommCRM这个项目。我在一家十来人的企业服务公司做销售支撑，CRM这个词听了无数遍，但真正上手用过的免费CRM产品一只手数不过来，结局基本都是用着用着就没人碰了，数据和聊天记录一起沉底。今年年初我腾出两个周末，自己搭了一套名叫DeskcommCRM的客户管理系统，跑在一台云服务器上，从客户录入、跟进记录、待办提醒到订单回款统计，整套逻辑自己完全说了算。这篇文章就把我在这个过程中的选型思路、功能拆解、部署流程和踩坑记录完整写出来，给那些正在纠结“免费CRM到底能不能用”“自建系统值不值得搞”的人做个参考。

1. 免费CRM的账算清楚之后，我决定自建一个DeskcommCRM

1.1 一年免费CRM用下来，问题不是功能少，而是“那个东西不是我的”

最开始我们用的是免费版CRM，理由很简单：预算有限，团队小，先用免费版跑通流程。这个决策在前面两个月确实没毛病，基础的客户录入、跟进记录、简单报表都有，销售们在PC端用起来也没有太大抵触。

但用满三个月后，问题开始密集出现。首先是数据导出这件事，免费档通常只允许导出部分字段，后面一看导出记录就没权限，页面弹窗引导你升级到付费套餐。其次是成员数限制，免费版一般卡在5到10个账号，多一个销售进来就得先在“踢人”和“升级”之间做选择。还有一次印象很深，某个周末销售总监想拉一下本周新增客户数据，发现后台的筛选条件被锁住了，提示“专业版功能”，他当时在群里甩了一句“这系统到底是给谁用的”，我当时就意识到，免费CRM的隐形门槛不是写在价格页上的。

最让我心里没底的还不是这些锁，而是数据的所有权。免费服务说到底是别人的产品，平台的规则今天这样明天那样，哪天服务调整或者产品线收缩，我们的客户跟进记录、历史报价、联系人资料，都存在一个我并不完全可控的容器里。销售数据是公司的核心资产，把它长期放在一个我不掌握底层逻辑的系统里，这个风险不是几百块钱订阅费能对冲掉的。

1.2 15人团队的账目算盘：自建真的更划算吗

决定自建之前，我先老老实实算了一笔账。假设一个15人的销售团队，免费CRM用着用着必然要升级付费版，市面上的SaaS产品按人头收费，一年下来少说5000块，多的一两万。这笔钱对公司来说不是付不起，问题是付完钱之后，依然解决不了字段想改改不了、流程想调调不动的问题。

自建的账单就简单多了：一台2核4G的云服务器，一年几百块；一个域名，一年几十块；HTTPS证书用免费的，数据库软件用开源的，整套系统没有License费用。真正贵的是时间，满打满算，我从设计表结构到部署上线，投入了大概两个周末，运营期内又断断续续修了几个小问题。把这些时间算成钱，第一年的总成本可能不比SaaS便宜多少，但第二年开始，边际成本几乎是零，而且想加什么功能，自己说了算。

这笔账算完之后，我更确定了一个判断：对于有一定技术底子，或者愿意请人搭一次的团队来说，自建CRM要解决的不是“能不能做出来”，而是“想清楚做到什么程度就收手”。如果一上来就想着要做成Salesforce那种庞然大物，这个项目必死；如果定位成“比Excel好用一点、比SaaS自由一点”的内部工具，它就能活得很好。

1.3 立项时给自己划定的功能边界

为了避免项目失控，我在动手前给自己写了三条边界。第一，只做客户管理相关的事，不做考勤、不做审批、不做进销存，那些是OA和ERP的领域，混在一起只会让系统变得臃肿。第二，第一版的目标是两周内上线，所以所有功能都朝“够用”去设计，不追求一次到位。第三，所有数据必须能随时完整导出，哪怕其他功能之后再补，这个底线首先得保住。

有了这三条边界，DeskcommCRM这个名字也就顺势定了下来。Deskcomm是我们小组的叫法，CRM就是客户关系管理，合在一起，它就是一套专门给我们业务场景用的内部客户管理系统。后面所有模块的演进，都是在这三条边界之内完成的。

2. DeskcommCRM只做六件事：功能清单和数据库设计

2.1 六件事分别是什么，为什么是这六件

整个系统的核心被我压缩成六个功能块：客户档案、标签分组、跟进时间线、待办提醒、订单回款、数据看板。这六件事对应的是一条完整的销售闭环——客户从哪来，谁在跟，聊到哪一步，下一步干什么，最后成交了没有，回款到了没有。

客户档案是地基，存储公司名称、行业、来源、等级、联系人信息这些基本盘。标签分组是对客户进行粗粒度的分类，比如“高意向”“需回访”“老客户转介绍”，方便后续批量筛选。跟进时间线是每一段沟通的记录，打电话聊了什么、微信发了什么、上门拜访的结果是什么，都按时间串起来。待办提醒解决的是“该联系谁”的问题，系统每天把到期需要跟进的客户列出来，提醒对应销售。订单回款模块记录成交金额、回款状态，告别月底手工对账。数据看板把前面所有数据汇总成几个关键指标，比如今日新增客户、本月新签金额、每个销售员的有效跟进数。

刚开始也有人建议我加上工单模块或者售后模块，我全部顶了回去。对一个十来人规模的业务团队来说，多一个模块就多一份录入负担，销售每天要面对一堆必填项的时候，他们会直接用脚投票，回到Excel和微信聊天里去。功能少的另一个好处是，每一处交互都做得很简单，新员工培训成本几乎为零。

2.2 customers表设计：字段宁少勿多

数据库是这套系统的骨架，我见过不少自建系统死在过度设计上，字段加了二十几个，最后常用的撑死五六个。DeskcommCRM的客户主表一开始只有十一个字段，关键字段都有索引：

CREATE TABLE customers ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, name VARCHAR(120) NOT NULL COMMENT '客户名称', industry VARCHAR(50) DEFAULT '' COMMENT '行业', source VARCHAR(30) DEFAULT '' COMMENT '客户来源', level TINYINT NOT NULL DEFAULT 1 COMMENT '等级 1-5', status TINYINT NOT NULL DEFAULT 1 COMMENT '状态 1跟进中 2已成交 3已流失', owner_id INT UNSIGNED NOT NULL COMMENT '归属销售ID', next_follow_up_at DATETIME NULL COMMENT '下次跟进时间', created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, KEY idx_owner_status (owner_id, status), KEY idx_next_follow (next_follow_up_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里的核心思路是字段宁少勿多。字段一多，录入成本立刻上升，销售在表单面前停留的时间越久，抵触情绪越强。真需要补充的个性化信息，我用了一个扩展属性表去存，而不是一股脑加在主表里，这样常规查询不受影响，又能保留灵活性。

另一个细节是纯数字的枚举字段，比如status、level，我坚持用TINYINT而不是字符串。原因很简单：数字在数据库里占用小、查询快，而且后续调整枚举含义时，只需要改一处映射逻辑，不用动表结构。客户表和联系人表我拆开了，因为一个客户公司通常有多个联系人，拆开后后续做群发邮件、多人对接都方便。

2.3 跟进记录与待办：时间线是CRM的灵魂

客户档案只是静态数据，真正让CRM“活”起来的是跟进记录。每次跟进的交互，包括通话、微信、拜访、邮件，都插入一行follow_ups记录，关联客户的ID、跟进方式、内容摘要和填写的下一步计划。界面上的展示按创建时间倒序排列，形成一个完整时间线。销售打开一个客户的那一刻，过去三个月跟这个客户的沟通轨迹全在眼前，不用再去翻聊天记录和邮件。

待办提醒则直接取自客户表的next_follow_up_at。每天早上系统会跑一次查询，把当天需要跟进的客户按照销售分好，生成一个待办清单。这块的核心不是技术，而是业务约定：每个销售在填写跟进取向后，必须回答一个问题——这个客户下一次最晚什么时间跟进，把这个时间填进系统，否则当天提醒列表就出不来。为了让这个规则落地，我在表单里把“下次跟进时间”设置成了必填项，一个小设置逼出来的数据质量，比任何考核都有用。

2.4 权限模型的两种落地方式

权限设计上我走了最简单的路线。系统里只有三种角色：超级管理员、主管、业务员。超级管理员能看到全部数据和系统设置，主管能看到自己组员的数据，业务员只能看到自己名下客户。落在数据层就是每个业务表都带owner_id，主管带队，所以再加一个leads_to表记录组内成员关系。查询列表时，我会根据当前用户的角色拼不同的WHERE条件，代码逻辑很直白，没有引入复杂的RBAC引擎。

实际用下来，这套简单模型的维护成本极低。对于销售团队来说，真正敏感的只有“谁的客户”和“看得见还是看不见”，角色越少，权限越好解释，出问题的概率也越小。真到了需要细分权限的那天，再扩展RBAC不迟，DBA层面留好了角色表，往上加字段不是什么难事。

3. 部署一台永久在线的CRM网站：从裸服务器到HTTPS

3.1 服务器、域名和成本预期

很多人一听到自建就以为要搞专用服务器、要招运维，其实完全不需要。DeskcommCRM底层就是个Web应用，我用的是一台2核4G的云服务器，硬盘40G，对这套系统的负载来说绰绰有余。初期甚至可以只用2G内存的入门配置，等访问量真正上来了再升级也不迟。

域名我选了一个和自己团队名称贴近的.com，一年的费用也就是一顿饭钱。如果你有精力，可以直接在域名商那里把解析配好，加一条A记录指向服务器IP，访问入口就算有了。考虑到“永久在线”这个需求，我还有两个坚持：一是所有配置文件的修改都做好备注，方便出问题后快速排查；二是每一步部署都写进了团队内部的部署文档，防止某天我请假了，系统就没人能维护。

3.2 一步步部署：Nginx + MySQL + PHP

技术栈选择上，我用了最常见的组合：Ubuntu 22.04服务器、Nginx做Web服务、MySQL 8.0存数据、PHP 8.2跑业务逻辑。选这套不是为了追逐潮流，而是因为文档多、社区活跃，遇到问题能搜到现成答案。服务器是裸机时，先做基础更新：

sudo apt update && sudo apt upgrade -y

然后安装核心组件：

sudo apt install -y nginx mysql-server php8.2-fpm php8.2-mysql php8.2-mbstring php8.2-xml php8.2-curl

MySQL安装完成后，立刻创建一个专用的数据库账号，而不是直接用root。密码也不要写在项目代码里，我会放到环境配置文件里，并通过.env文件注入。接下来创建数据库和账号：

CREATE DATABASE deskcomm DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'deskcomm'@'localhost' IDENTIFIED BY '一个足够复杂的密码'; GRANT ALL PRIVILEGES ON deskcomm.* TO 'deskcomm'@'localhost'; FLUSH PRIVILEGES;

接着把写好的代码上传到服务器目录，并配置Nginx站点。之所以用Nginx而不是Apache，是因为它处理高并发静态文件更省资源，对PHP-FPM的支持也简单直接。站点配置我放在/etc/nginx/sites-available/deskcomm：

server { listen 80; server_name crm.example.com; root /var/www/deskcomm/public; index index.php; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.2-fpm.sock; } }

配置完成后重启Nginx，再执行一次数据库迁移命令，把系统初始化表结构写进去，整个站点就能访问了。这个过程看起来步骤多，但照着文档走一遍，熟练的话一个多小时就能全部搞定。

3.3 域名解析、HTTPS证书与定时备份

域名解析的部分，我在DNS管理后台加了一条A记录，把crm.example.com指向服务器IP。解析生效后，用免费证书工具申请HTTPS证书，推荐certbot，因为申请和自动续期都只需要一条命令：

sudo certbot --nginx -d crm.example.com

certbot会自动修改Nginx配置，把HTTP流量重定向到HTTPS，证书到期前它会自动续期。这一步做完，“永久在线”的通信加密就有了保障，员工在外面用手机访问也安心。

备份是我无论如何都不妥协的一个环节。我用crontab定时任务，每天凌晨3点把MySQL数据库导出并压缩，然后把备份文件传一份到对象存储或另一台不常用的机器上：

0 3 * * * mysqldump -u deskcomm -p密码 deskcomm | gzip > /backup/deskcomm_$(date +\%F).sql.gz && scp /backup/deskcomm_*.sql.gz backup@backup-server:/backup/

数据无价，这句话在自建系统上体现得特别明显。系统可以没有，服务器可以宕机，但客户跟进的历史记录一旦丢了就很难重建。

3.4 什么才算“永久在线”

网上有人搜“永久在线的crm网站”，我理解这种诉求：免费CRM说停就停、说改就改，自建系统要的就是稳定可控。但“永久在线”不是一个魔法开关，它由三件事组成：服务器进程稳定跑、域名持续有效、备份能被恢复。服务器这块我用systemd把PHP相关服务设置成开机自启并允许崩溃后自动拉起，Nginx和MySQL本来就是常驻服务，只要机器不宕机就一直在。域名和证书则靠续费和自动续期来保证。

还有一层容易被忽略的“永久在线”，就是你得知道系统现在正不正常。我在服务器上挂了最简单的监控，每5分钟探一次首页，连续两次探不通就发邮件告警，这样就算半夜出了问题，第二天一早也能发现，不至于等业务人员反馈了才知道系统挂了。

4. 免费SaaS和私人自建CRM的真实差异：一张表看清利弊

4.1 一张表对比六个关键维度

在决定自建之前，我把免费SaaS和自己搭这套系统的差异认认真真梳理了一遍，这里用一张表分享出来：

表格拉出来之后，结论其实很明显：免费SaaS赢在启动成本和便利性，私人自建赢在掌控感和长期成本。没有绝对的好坏，只看你现阶段更缺什么、能付出什么。

4.2 免费SaaS的隐性成本

免费SaaS最大的迷惑性在于首月使用很顺畅。你注册账号，导入几十条客户，叫上团队试用，一切都很好。但不出一两个月，各种“升级引导”就来了：名单里超过几百个客户要升级、导出报表要升级、多人协作要升级、自动提醒要升级。不是说这些收费不合理，而是当你真正依赖上它之后，议价空间几乎为零。

更隐性的成本是数据和流程的绑定。我见过有的团队在免费CRM里跑了半年，累计了几千条线索，结果想迁出来的时候发现，导出的Excel字段对不上，备注信息缺了一大半，连跟进记录都没有完整导出选项。这就是典型的用免费服务的代价——入场免费，离场费却高得离谱。蝉鸣、飞鱼这类产品各有各的优势，但免费档位几乎都离不开“存储空间有限、成员数受限、高级字段锁定”这类设计，本质上就是在等业务量上来之后转化成付费用户。

这个逻辑本身没有对错，但如果你是那种数据敏感、流程要自己掌握的公司，就必须意识到：你选择的不只是一个工具，而是一整套平台规则。规则合适怎么都好，规则一变，你要么跟着改流程，要么花更大的成本搬走。

4.3 决策清单：你的团队适合哪一种

根据自己的使用场景，我总结了一个尽量简单的决策清单。如果满足下面任意三条，免费SaaS可能更合适：团队在5人以下；现阶段纯粹想尽快跑通客户管理；公司没有人懂服务器和代码；对CRM的诉求就是最基础的记录和表格；不想在内部工具上花任何时间。

反过来，如果满足下面任意三条，自建就更值得考虑：团队在10人以上，销售数据量明显增大；曾经在免费SaaS里吃过数据导出的亏；公司有技术背景的人能兼职维护；业务上有明显的定制需求；在意品牌形象和数据安全。

这不是一个非黑即白的选择题。有些团队完全可以先用免费SaaS跑三个月，确认流程之后，再找时间把数据迁到自建系统上。关键是想清楚每个阶段的成本上限是多少，以及你最不能失去的是什么。

5. 邀请员工加入DeskcommCRM：从邀请链接到权限生效的完整链路

5.1 为什么“邀请员工”在很多系统里那么难找

“飞鱼crm怎么邀请员工”这类热搜词屡见不鲜，说明很多人第一次接触CRM时，最先卡住的操作不是录入客户，而是怎么让旁边的同事也用起来。原因也很简单：在大多数SaaS产品里，“邀请员工”这个动作其实被拆成了几步，它不是简单发个链接，而是“创建成员账号+分配角色权限+激活确认”的组合流程。入口往往藏在成员管理设置里，而不是员工登录页，新用户找不到很正常。

我在做DeskcommCRM时专门把这个流程做成了三段式，让管理员一看就会：填写邮箱、选择角色、生成邀请链接。员工收到链接，点开设置密码，登录后直接进入系统。这个设计逻辑和飞鱼这类成熟产品殊途同归，区别在于自建系统的每一段逻辑我都能控制，不会出现“明明邀请了，对方却收不到激活邮件”然后找不到人工客服的窘境。

5.2 邀请机制的三段式设计

实现上，我建了一个invitations表，用来存储系统生成的邀请链接：

CREATE TABLE invitations ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, email VARCHAR(120) NOT NULL, role_id TINYINT NOT NULL, token VARCHAR(64) NOT NULL, expired_at DATETIME NOT NULL, created_by INT UNSIGNED NOT NULL, accepted_at DATETIME NULL, UNIQUE KEY uk_token (token) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

管理员在后台填写被邀请人的邮箱，选择角色之后，系统生成一个随机的token，并把这个token拼成完整链接：

$token = bin2hex(random_bytes(32)); $link = 'https://crm.example.com/invite/' . $token;

生成token用的是random_bytes而不是单纯的时间戳，可以避免被猜出来，几小时内有效的过期时间也限制了链接被滥用的风险。员工点击链接进入设置密码页面，密码设置成功后，系统把invitations表里对应的accepted_at字段写入当前时间，同时创建一个状态为活跃的员工账号。整个过程不需要管理员参与，链条清晰。

如果员工反馈没收到邮件，我提供了一个兜底方案：管理员后台可以直接查看邀请链接的当前状态，或者为某个邮箱重新生成新链接。自建系统的好处就是这种“不痛不痒的小功能”不用找客服提工单，自己花10分钟就能补上。

5.3 权限生效与操作留痕的细节

邀请链接接受之后，真正的重点其实是权限的落地。新员工创建账号时会带上管理员预设的role_id，登录后的菜单项、按钮显示、数据范围全部根据这个角色动态渲染。比如业务员登录后，列表页只显示owner_id等于自己的客户；主管能看到自己组员的数据；管理员则拥有全部菜单。

光有权限控制还不够，我还加了操作日志。关键动作，比如导出客户列表、修改客户归属、删除跟进记录、调整订单金额，都会写入operation_logs表。这个表平时不显山露水，但真到了业务纠纷或数据对不上的时候，它是唯一能还原现场的东西。有一次团队里两个销售因为一个客户归属吵起来，查了日志才发现，这个客户最初是由A录入，两周后管理员调整给了B，真相大白，冲突化解。没有这个日志的话，就只能各说各话了。

6. 上线三个月踩过的三个坑，以及补救方案

6.1 坑一：手机端打开页面没法用

第一版DeskcommCRM是典型的面朝桌面的系统，我在电脑浏览器里反复调整布局，一排列表加一个编辑弹窗，自己用起来很舒服。结果销售们出去拜访客户，到了客户公司想当场录一条跟进记录，掏出手机一打开，表格挤成一团，按钮重叠，文件传不上去，体验只能用“灾难”形容。

这个坑其实完全可以提前避开，因为团队里有一半人日常不坐办公室。补救方案分两步：第一步，我引入了一套简单易用的响应式CSS方案，把客户列表、客户详情、新增跟进、待办提醒这4个高频页面优先做移动端适配，宽度低于768px时自动切换成单列布局；第二步，在页面底部加了固定快捷栏，把“新增客户”“快速跟进”“待办”三个按钮钉在底部，大拇指正好能点到。

做完之后我复盘过，如果我第一天就把这些页面的最小浏览宽度设成375px，而不是1440px，这个坑大概率不会发生。现在再做任何新功能，我都会先拿手机浏览器看一眼，再回桌面调细节。

6.2 坑二：Excel导入客户，乱码和重复一起出现

上线第二周，行政把往年积累的客户资料整理成Excel，让我一次性导入系统。我写了一个简单的导入脚本，结果第一次跑完，几百条数据里三分之一是乱码，还有不少重复记录，同一个客户电话出现了两三次。查了半天才发现，Excel文件本身是GBK编码保存的，而数据库用的是UTF-8，字符集对不上，中文就全变成了问号。

解决这个问题的思路是双向的。第一，我让脚本在读取时自动判断文件编码，遇到GBK先转成UTF-8再入库；第二，我直接在系统里生成了一个固定的导入模板，要求所有人都用这个模板填写，模板里字段顺序、编码格式、是否必填都提前规定好了。导入逻辑里也加了判重机制，按手机号去重，手机号相同的记录保留最新的，重复项单独列出来让管理员人工确认。

经历过那次乱码导入之后，我再也不敢随便拿一个Excel文件直接灌进数据库。数据清洗虽然琐碎，但它是导入这步操作里面最能体现是否专业的部分。

6.3 坑三：月底集中录入时列表页卡顿

最后一个坑发生在系统上线三个月后的月底。月底是销售集中补录客户资料和跟进记录的时间，有两天下午系统列表页突然变得很慢，打开一个客户列表要转好几秒。我第一时间打开MySQL慢查询日志，发现慢的基本都是同一条SQL，按状态和更新时间查询客户列表，没有走到索引，全表扫描。

原因其实就是前面那句话：我给status和updated_at分别建了单一索引，但查询是按status加上updated_at排序组合使用的，单列索引派不上用场，MySQL只能做全表扫描加文件排序。修复方式很简单，加了一个组合索引：

CREATE INDEX idx_status_updated ON customers (status, updated_at);

加完索引之后，列表页从好几秒降到了几十毫秒。这个坑让我明白了一个道理：小数据量的时候怎么查都快，一旦数据量上来，索引设计就成了最便宜的优化手段。

后来我把页面上的分页改成每页50条，并且加上了按创建时间范围筛选的默认条件，让查询永远在一个可控的范围内跑。到现在，这个列表页再也没出现过超过1秒的加载时间。

自己做一套系统，最占时间的地方不是写功能，而是处理各种“你以为不会发生但就是发生了”的意外。但正是这些意外，让我对DeskcommCRM的每一处细节都心里有数。如果你也想给团队搞一套类似的系统，我的建议是从最简单、每天用三次以上的功能开始，先让系统在你的业务里活起来，再去想那些花哨的扩展。数据在你自己手里，功能按自己的节奏长，这才是自建最大的底气。