企业官网建设流程全解析

1. 项目起源：为什么我要折腾一个叫 DeskcommCRM 的东西

先说结论：DeskcommCRM 是我自己从零搭的一套轻量级客户管理系统，核心就三个词——客户资料集中管、跟进记录不断档、团队协作不靠吼。如果你也是那种客户一多就混乱、跟进全靠微信聊天记录、每周靠翻手机回忆"上次跟这个客户说到哪了"的销售或小团队管理者，这个系统就是冲着解决这些问题去的。

先说下我自己的背景。我既不是大厂架构师，也不是专业运维，就是一家十来个人的小公司的业务负责人，带着三个销售和两个客服。几年下来，客户的联系方式、报价记录、合同进度、售后问题全散落在 Excel 表格、企业微信聊天记录和纸质笔记本里。最痛苦的是：业务员离职，客户关系直接断层；有同事休个假回来，根本不知道某个客户之前聊到什么阶段；月底想统计一下销售转化率，得靠人工去翻聊天记录，翻到怀疑人生。

市面上不是没有现成的 CRM 工具，我当时也试用过不少。但问题也很现实：免费的 SaaS 版功能阉割严重，客户量稍微上来一点就要付费；付费版一年上千甚至几千，对一个小团队来说是一笔实打实的支出；而最让我犹豫的，是数据完全放在别人服务器上，客户资料这种核心资产，万一平台政策调整或者账号出问题，想导出都麻烦。就是在这样的背景下，我决定自己动手做一个——这就是 DeskcommCRM 的由来。

这篇文章我会把整条路走一遍：从需求梳理、方案选型，到技术实现、部署上线，再到实际使用中的各种坑和解决方案，全部展开讲。内容对完全没有技术基础的读者也友好，术语我会用大白话解释；如果你本身就是搞技术的，可以直接跳到第 3 章看架构设计和代码实现，那里有你最关心的东西。

2. 需求梳理：先搞清楚"要什么"，再做系统

2.1 核心需求拆解：我和团队真正缺的是什么

动手之前，我花了大概两周时间，把团队所有人的日常动作观察了一遍，也逐一问了一圈"你希望有个什么东西来帮你管客户"。汇总下来，需求其实非常集中，就是下面这四件事：

• 客户资料统一管理：不光是姓名、电话、公司，还包括来源渠道、所属行业、客户状态（潜在、跟进中、已成交、已流失），以及最重要的是——跟进历史。
• 跟进记录和提醒：谁在什么时间跟进了哪个客户，聊了什么，下一步计划是什么，下次跟进时间是什么时候。到点了系统要主动提醒，不能让销售凭记忆。
• 团队协作和数据权限：客户不是一个人的，是公司的。但不同角色能看什么、能改什么，要有区分。比如普通销售只能看自己的客户，主管能看全组，老板能看全部。
• 数据统计和可视看板：成交了多少、每个销售的跟进量、客户转化率、本月新增客户数。光有数据不够，还得有直观的展示，不然月底写总结还是靠拍脑袋。

这些需求看起来简单，但实际操作中你会发现一个隐藏前提：系统必须"永久在线"。所谓永久在线，不是指你电脑开机它就能用，而是指不管你在公司、在家、还是出差在外，打开浏览器输入网址就能访问，数据实时同步，不用装客户端，也不用担心关机了别人用不了。这就决定了它是一个 Web 应用，而不是本地软件。

2.2 免费 CRM 与自建系统怎么选：算清楚这笔账

在决定自建之前，我认真比较过三条路：直接用免费 CRM、买商业 CRM、自己搭一个。我拿了一张表，把优劣势列出来对比：

看到这里你可能发现了，自建的最大代价不是钱，而是"维护负担"。你得自己搞定服务器、数据库、安全更新、数据备份。但对我来说，这笔账是划算的：服务器一年租金几百块，比一个商业 CRM 坐席一年的钱还少；而数据在自己手里，备份、导出、迁移都是我说了算；功能上我还能按团队的脾气随时改。

还有一个很容易被忽略的点：商业 SaaS 产品为了覆盖更多客户，功能越做越重，页面层级非常多，每天录入客户信息要点五六次鼠标。而自建系统可以做到极简，几个核心字段一遍页就录完了，这对每天要录大量客户资料的销售来说，体验差别是巨大的。DeskcommCRM 的第一个原则就是"输入路径最短"。

3. 技术选型和整体架构设计

3.1 技术栈的选择逻辑：不追新，只求稳

说实话，作为一个小型业务系统，技术选型最大的忌讳就是"为了用新技术而用新技术"。团队要的是稳定、能改、有现成生态，而不是炫技。DeskcommCRM 最终选择了非常成熟的一套组合：

• 后端语言：PHP（8.x），原因是部署最简单、资料最多、虚拟主机都能跑，后期换任何服务器都无缝迁移。
• 数据库：MySQL（5.7 以上），客户数据是典型的关系型数据，用 MySQL 的生态最成熟，备份、优化工具一堆现成的。
• 前端：原生 HTML + JavaScript + 少量 CSS 框架，不引入前端工程化那套复杂构建流程。系统核心是表单和表格，原生能力完全够用，还省去了 node_modules 的烦恼。
• 部署方式：云服务器 + Nginx + PHP-FPM，域名走 HTTPS 加密访问。

这套组合不新潮，但有一个非常实际的好处：任何能装 Nginx 和 PHP 的服务器都能跑，将来把整个系统迁移到另一家云服务商，打包搬过去就行，完全不受某家云厂商的绑定。

3.2 数据库设计：客户、跟进、用户的三角关系

DeskcommCRM 的核心数据表非常克制，就三张主表加两张辅助表：

• customers（客户表）：id、name、phone、company、source（来源渠道）、industry（行业）、status（状态）、owner_id（负责员工）、created_at 等字段。
• follow_ups（跟进记录表）：id、customer_id、user_id、content（跟进内容）、next_time（下次跟进时间）、created_at。这张表是系统的灵魂，每一条跟进记录都按时间线挂在对应客户下面。
• users（用户表）：id、username、password_hash、real_name、role（角色：admin / manager / sales）。
• reminders（提醒表）：id、user_id、customer_id、remind_time、is_done。用于实现"到点提醒跟进"功能。
• operation_logs（操作日志表）：记录谁在什么时候新增、修改了哪个客户的什么字段。排查问题全靠它。

为什么要单独拆一张 follow_ups 表，而不是直接把跟进内容塞在客户表里？因为一个客户会有几十条跟进记录，如果都放在客户表里，客户表会膨胀得厉害，而且查询某条跟进记录时要把整个客户信息一起捞出来，性能会很差。拆成两张表之后，客户信息查一次，跟进记录按customer_id索引查询，每次打开客户详情页只要一条 SQL 就能把所有历史记录按时间倒序取出来。这是最基础的关系型数据库设计思路，成本低，效果好。

3.3 "永久在线"的实现：部署方案与注意事项

"永久在线"不是玄学，它由三个层面决定：

• 部署层面：系统跑在云服务器上，而不是某台电脑上。云服务商有电力和网络保障，只要不欠费，它就一直在线。配置不用高，我用的 2 核 2G 内存的机器，带十来个人日常使用绰绰有余。
• 域名和 HTTPS 层面：绑一个自己的域名，配置 SSL 证书，让团队访问的是https://crm.yourdomain.com这样的地址，而不是裸 IP。好处是稳定、安全、好记，浏览器也不会提示"不安全"。
• 数据备份层面：永久在线不等于数据不丢。我设置了每天凌晨自动备份数据库，备份文件保留最近 7 天，定期下载到本地。数据备份这事儿，我后面会专门讲，这是整个系统里最容易出问题也最容易忽略的地方。

4. 核心功能实现与操作实录

4.1 客户管理模块：让录入成为一件快事

客户管理是 CRM 的底座，如果这一步用着别扭，整个系统就会被弃用。我在设计录入界面时只有一个标准：一个客户从打开页面到保存成功，最快只需要三步——打开"新增客户"、填表、点保存。表单字段控制在必填 3 项（姓名、电话、来源），其余全部选填。

实操中发现一个很关键的细节：电话号码唯一性校验必须做。以前用 Excel 的时候，同一个客户被录两条甚至三条，跟进时各记各的，月底盘点才发现重复。系统里我专门对phone字段加了唯一索引，重复录入时直接弹出提示；同时允许"合并客户"操作，把两个重复客户的跟进记录合并到一条。

每天高频使用的客户搜索功能也花了不少心思。销售来找客户时，往往只记得一个电话号码前几位或者一个公司简称。我把搜索框做成了全文模糊匹配：输入任意关键词，只要客户的姓名、电话、公司、备注里任一字段包含这个关键词就能搜出来。这就意味着，哪怕只记得"张工"或者尾号 1234，也能一秒定位到目标客户。体验上是质的提升。

4.2 跟进记录与提醒：把"凭记忆"变成"按流程"

跟进记录是整个 DeskcommCRM 最核心的功能，也是和 Excel 差别最大的地方。过去在 Excel 里写跟进，要么新建一列，要么在备注里追加，时间一长格式一团糟，根本谈不上"时间线"的概念。现在每次跟进，操作流程是这样的：

1. 在客户详情页点击"新增跟进"；
2. 填写跟进内容（比如"客户对 A 方案感兴趣，要求下周出详细报价"）；
3. 选择跟进方式（电话 / 微信 / 上门拜访 / 邮件）；
4. 如果还有下一步动作，设置一个"下次跟进时间"。

系统会自动记录这条跟进的创建人和创建时间，并按时间倒序排列在客户详情页里。这样打开任何一个客户，他的完整来龙去脉一目了然：第一次电话是什么时候、中间因为报价搁置了多久、最后是怎么谈成的，全在时间线上。销售休假回来，五分钟就能接上之前的进度。

"下次跟进时间"这个字段被单独抽出来，每天早上 9 点系统会自动把当天需要跟进的客户推送到每个销售的"今日待办"里。这就是团队协作的核心：不需要任何人在群里喊"别忘了跟进谁"，系统本身就是那个永远不睡觉的提醒器。

4.3 团队管理：怎么把员工加进系统

这也是一个使用频率极高的操作。系统上线之后，老板或者管理员要做的第一件事就是把员工加进来。具体流程我写一下，照着做即可：

1. 用管理员账号登录系统，进入"系统设置 → 用户管理"；
2. 点击"新增用户"，填写员工姓名、设置初始登录密码；
3. 选择角色：销售（sales）只能看见和操作自己名下的客户；主管（manager）可以看见全组客户；管理员（admin）拥有全部权限；
4. 保存后，把分配的登录账号和初始密码发给员工，员工用浏览器打开系统网址即可登录；
5. 员工首次登录后，在"个人设置"里修改自己的密码，并完善手机号，便于找回密码。

权限模型我做得比较朴素但有层级：客户表里有一个owner_id字段，它决定了客户归属；普通销售查询时自动带WHERE owner_id = 当前用户id，主管和管理员不执行这个过滤。曾经有同事问"如果客户转给另一个销售怎么办"，实操中的做法是：在客户详情页提供"转移负责人"按钮，转移后自己的待办里就不再出现这个客户，新负责人接手，所有跟进记录完整保留，客户不需要重新说一遍需求。这一点对项目型团队尤其重要，换人交接的时候，客户体验不会断。

4.4 数据看板：让月底汇报不再靠翻聊天记录

数据统计是我后期加的一个模块，但使用频率意外地高。看板分两层：

• 个人层：每个销售登录后能看到自己本月的"新增客户数、跟进次数、已成交数、成交率"。销售可以随时自检：是不是这个月跟进量下降导致成交没跟上。
• 管理层：主管和老板看到的是一张汇总视图，包含全公司各销售维度的表现对比、线索渠道分布、客户状态分布（潜在 / 跟进中 / 已成交 / 流失）。

看板的数据实现并不复杂，就是定时跑几条 SQL 聚合查询。比如"本月各销售新增客户数"就是SELECT owner_name, COUNT(*) FROM customers WHERE MONTH(created_at) = 当月 GROUP BY owner_id。这类统计对数据库压力很小，数据量在几万级别时毫秒级返回，不需要引入大数据那套东西。

5. 部署上线：从零把系统跑起来的完整流程

5.1 服务器与域名准备

如果你没有技术基础，最省心的方式是买一台云服务器。以腾讯云、阿里云这些主流的云厂商为例，新用户轻量应用服务器一年经常有优惠，2 核 2G 内存 40G 硬盘的配置，跑一个小型 CRM 绰绰有余。操作系统选择 Ubuntu 22.04 或者 CentOS 7 都行，我习惯用 Ubuntu。

域名注册之后，做一个 A 记录解析，把crm.yourdomain.com指向服务器的公网 IP。这里有一个规律：解析生效之后，用浏览器访问这个域名，能 ping 通服务器就算成功了一大半。

5.2 服务器环境安装与系统部署

我把关键的命令写到这里，给大家一个可以直接照抄的版本：

# 更新软件源 sudo apt update && sudo apt upgrade -y # 安装 Nginx、PHP 及常用扩展、MySQL sudo apt install -y nginx php-fpm php-mysql php-mbstring php-curl mysql-server # 启动服务并设置开机自启 sudo systemctl enable nginx sudo systemctl enable mysql sudo systemctl start nginx sudo systemctl start mysql # 数据库创建（进入 MySQL 后执行） CREATE DATABASE deskcomm_crm DEFAULT CHARACTER SET utf8mb4; CREATE USER 'crm_user'@'localhost' IDENTIFIED BY '这里写一个强密码'; GRANT ALL PRIVILEGES ON deskcomm_crm.* TO 'crm_user'@'localhost'; FLUSH PRIVILEGES;

把 DeskcommCRM 的程序文件上传到/var/www/deskcommcrm目录，然后配置 Nginx 站点。配置文件的要点是让所有请求都走 PHP 解析，核心部分长这样：

server { listen 80; server_name crm.yourdomain.com; root /var/www/deskcommcrm/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.1-fpm.sock; } }

最后记得用 Certbot 申请免费的 SSL 证书，实现 HTTPS 访问：

sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d crm.yourdomain.com

证书自动续期，配置好就不用管了。整个过程熟练的话半小时内能搞定。系统首次访问会自动进入安装向导，填好数据库连接信息和管理员账号密码，就能开始使用。

5.3 每日自动备份：忘了什么都不能忘了这个

这是我最想强调的一节。系统跑起来之后，最可怕的事情不是功能设计得不好，而是硬盘坏了或者手误删了数据库。没有备份，所有客户数据、跟进记录、团队劳动成果瞬间归零，而且无法挽回。

我的做法是一个简单的 shell 脚本，挂在系统 crontab 里，每天凌晨 3 点执行：

#!/bin/bash BACKUP_DIR="/data/backup/deskcommcrm" DATE=$(date +%Y%m%d_%H%M%S) mysqldump -u crm_user -p'密码' deskcomm_crm > $BACKUP_DIR/db_$DATE.sql find $BACKUP_DIR -type f -name "*.sql" -mtime +7 -delete

这个脚本做了什么？每天把数据库完整导出一份到一个以日期命名的 SQL 文件里，同时自动删除 7 天前的备份，防止磁盘被占满。我还额外做了一步：每周手动把备份文件下载到本地网盘，实现异地备份。正所谓"鸡蛋不能放在同一个篮子里"，数据也一样。

6. 常见问题与排查经验实录

系统上线半年，我遇到的坑不少，但真正有代表性的问题集中在下面几个，我整理成了一张速查表：

这里挑两个最典型的问题展开讲一下。

第一个是"登录后空白页"。这个问题的排查路径非常标准：先看 Nginx 的错误日志（/var/log/nginx/error.log），再查 PHP-FPM 的日志（/var/log/php8.1-fpm.log）。我的情况是 PHP 的mbstring扩展没装，字符串处理函数全部失效，程序直接挂了。安装扩展后重启 PHP 服务就恢复正常。遇到这种问题先不要慌，按日志排查是最快的。

第二个是"早上收不到待办提醒"。当时我以为代码有问题，查了一上午，最后发现是服务器时区是 UTC，和北京时间差了 8 个小时。脚本每天早上 9 点执行，但实际上在服务器本地时间只是凌晨 1 点。解决方法是把服务器时区设成Asia/Shanghai：

sudo timedatectl set-timezone Asia/Shanghai

这类问题很有代表性：很多"诡异"的问题，根源都是环境配置，而不是业务代码本身。所以在新服务器上部署时，我第一件事就是统一时区和字符集这两项基础配置。

7. 给后来者的一些建议

最后说几句掏心窝的话。DeskcommCRM 从立项到上线，用了不到两周；但从"能用"到"好用"，我断断续续调整了快两个月。这两周的开发和两个月的打磨，让我对整个事情有了几层很深的体会。

第一，工具只是工具，落地才是关键。再好的系统，如果团队不愿意用，就是个摆设。我做的第一版界面很简陋，但销售们还是愿意用，为什么？因为录入和查询真的比 Excel 快，快就是最大的动力。后来我所有的功能迭代，都优先考虑"能不能让使用路径更短"，而不是"功能够不够多"。

第二，数据比功能值钱。我见过有人花了大量时间纠结 CRM 的某个统计图好不好看，却从没做过一次数据备份。系统跑着跑着，最值钱的就是里面积累的客户关系和跟进历史，这些是花钱买不来的。所以永远记得备份。

第三，不用一步到位。DeskcommCRM 从第一天能跑起来，到现在也只是把客户管理、跟进提醒、团队权限、数据看板这四件事做扎实了。很多业务上的新需求，比如对接企业微信、做自动报表推送，都是后面逐步加进去的。如果你也想自建一套系统，我的建议是从最小的可用版本开始，先把"客户不丢、跟进不断"这件事跑通，再慢慢生长。

我踩过最深的坑，不是技术问题，而是在最开始花了很多时间纠结"要不要找一个完美的现成方案"。事实证明，没有完美的方案，适合自己团队体量的就是最好的方案。DeskcommCRM 这套思路和代码，你也可以完全复刻，甚至在这个基础上改得比我的更好。只要它真的能帮你把客户管好、把跟进做好，这件事就值得做。