企业官网建设流程全解析

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% 以上，客户列表一刷新要等两三秒，体验很差。

我建议的最低配置是这样的：

内存是关键。CRM 背后一般有数据库和 Web 服务，内存不够会频繁触发 swap，表现就是"卡"。硬盘一定要选 SSD，机械盘在数据库随机读写时差距极其明显。

如果你的用户在国内，服务器地域优先选国内（需要备案）或者香港（不需要备案但有网络波动风险）。我不建议为了省几十块钱选太冷门的区域，晚高峰延迟会让你怀疑人生。

2.2 域名与 HTTPS：永久在线的基础体验

系统装好后，如果你用 IP 地址直接访问，会面临两个问题：一是浏览器会拦截，因为现代浏览器对非 HTTPS 的站点越来越不友好；二是你发链接给同事，IP 地址很难记，也容易被当成垃圾链接。

所以域名不是选配，是标配。国内云厂商买一个 .com 域名一年也就几十块钱，然后通过 Let's 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 --host=0.0.0.0 --port=8000 directory=/var/www/deskcomm autostart=true autorestart=true startsecs=3 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_HOST=mysql - DB_DATABASE=deskcomm - DB_USERNAME=deskcomm - DB_PASSWORD=change_me depends_on: - mysql volumes: - deskcomm_storage:/var/www/deskcomm/storage mysql: image: mysql:8.0 environment: - MYSQL_DATABASE=deskcomm - MYSQL_USER=deskcomm - MYSQL_PASSWORD=change_me - MYSQL_ROOT_PASSWORD=root_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 支持两种员工账号添加方式：

1. 管理员手动创建。在后台用户管理里点击添加用户，填入姓名、邮箱、初始密码，然后勾选角色即可。头像可以先不传，员工自己登录后修改。

2. 邀请链接注册。管理员开启邀请功能后，生成一个带有效期的邀请链接，发给员工。员工通过链接自己注册，填写基本信息后提交，管理员审核通过后才算正式激活。

我的建议是：如果团队人数不多（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，我希望这份笔记能帮你少走点弯路。别被"部署"两个字吓到，按照上面这些步骤，一天之内完全可以跑起来。