企业官网建设流程全解析

1. 项目背景：为什么会有 DeskcommCRM 这个项目

我接手团队客户管理系统的升级是在年初，当时团队规模不大，销售加客服十几个人，客户信息管理基本靠Excel表格和个人微信。销售手里各有一份自己的联系人清单，打电话跟进到哪一步，全凭记忆和聊天记录，别说管理层看不到全局，连同一个客户是否已经被同事联系过都很难判断。最头疼的是每次有员工离职，他手头的客户资源就跟着流失一大半，公司完全没办法接手。当时市面上能用的CRM产品不少，像蝉鸣CRM、飞鱼CRM这类SaaS产品我们也试用过，功能确实齐全，但按月按人头的收费方式，加上很多定制字段需要升级套餐才能用，算下来成本不低。后来我决定自己搭建一套内部使用的系统，代号就叫DeskcommCRM。

DeskcommCRM这个名字拆开看就是Desk + Communication + CRM，直译是“桌面上的客户沟通管理系统”。为什么强调桌面和通讯？因为销售和客服的真实工作场景就是坐在电脑前打电话、回消息、记跟进，工具必须打开浏览器就能用，不能像Excel那样还要手动维护表格、手动上传共享文件。我们当时定下三个核心目标：第一，客户资源必须沉淀在公司自己的服务器里，不能放在员工私人电脑和个人微信上；第二，每一次跟客户沟通的内容都要留痕，方便交接、复盘和仲裁；第三，团队协同时要有权限边界，每个人看到自己权限内的客户信息，但主管又能对全局数据一目了然。DeskcommCRM整套系统都是围绕这三个目标做的。

写这篇复盘的时候，我自己也查了不少跟“免费CRM”和“私人网站”有关的讨论，发现很多人还在纠结到底选哪条路。如果你也是二三十人以内的小团队，老板亲自抓销售，或者你正在运营私域、做B端服务，这套自建CRM的思路会有参考价值；如果你只是想找一个工具代替Excel，完全不想碰服务器和代码，那后面免费CRM和自建系统的对比部分也能帮你少踩一些坑。

2. 核心功能设计：DeskcommCRM 解决的不是“放客户”，而是“管过程”

很多人一听说CRM，第一反应就是电子通讯录，把客户姓名、电话、公司名称存下来就够了。但实际跑业务之后会发现，通讯录只是最表层的东西。DeskcommCRM真正要解决的是“过程管理”——客户是从哪个渠道来的，谁在跟进，聊到了什么阶段，下一步计划什么时候做。这些过程信息才是客户资产的核心。

我们当时也纠结过要不要直接买商业SaaS，省事。但后来发现几个问题：SaaS产品虽然功能多，但很多是我们用不上的，反而把界面塞得密密麻麻；而真正想调整的流程，比如自定义一个“预算等级”字段，或者改一下列表默认排序，要么需要买更高套餐，要么需要等官方排期。自建系统从一开始就把可定制性放在首位，后面用起来确实顺手得多。

2.1 客户档案：要能自定义，不能套模板

标准CRM里客户档案基本是姓名、电话、公司、备注这些固定字段，但实际业务里每个团队的需求都不一样。我们做企业服务，需要记录客户所属行业、公司规模、预算等级、意向产品、获客渠道。这些字段在默认模板里根本不存在，所以DeskcommCRM第一件事就是把字段配置做成完全可自定义。

我们实际配置了这些字段：

字段这东西不是越多越好。我见过有人一上来就加了三十多个自定义字段，结果销售录入时烦得不行，最后大部分字段都填“无”，统计报表反而变成一堆噪音。字段设计有个原则：只放“筛选和分组时要用”的数据，描述性的信息写在跟进记录里就行。这一步看起来简单，但决定了后面做客户分类和业绩统计时效率高不高。

2.2 跟进记录：所有沟通都要留痕

DeskcommCRM里使用率最高的功能就是跟进记录。每次打完电话、发完微信、拜访完客户，销售要在对应的客户档案下新建一条跟进记录，内容包括沟通方式、沟通内容、客户反馈、下一步动作。这一点刚推行的时候很遭人抱怨，觉得是增加额外工作量。坚持一段时间后，价值就出来了。

第一个价值是防撞单。两个销售同时联系同一个客户时，只要查看跟进记录就知道对方已经聊到哪一步，避免重复打扰客户。第二个价值是防离职断层。以前有销售离职，他手机微信里的客户基本就带走了，自从启用系统后，所有跟进记录都在公司服务器上，新人接手时翻一遍历史记录就能快速了解客户情况，不用从头问“之前聊到哪了”。第三个价值是给管理提供依据。月底复盘的时候，看跟进记录数量和内容质量，基本能判断出销售是在认真推进客户还是磨洋工。

我还额外做了一个小优化：跟进记录支持手机端语音录入，自动转文字保存。销售在外面跑客户的时候，拿出手机说几句话就能生成一条记录，不用在车里还要打一堆字。这功能基于第三方语音识别接口实现，成本很低，但员工接受度一下子高了不少。

2.3 工单流转：把“人肉跟踪”变成流程驱动

除了销售跟进之外，DeskcommCRM还承接了一部分售后工单的流转。客户报障或者提出新需求后，客服在系统里创建工单，指定负责人、优先级和截止时间。负责人处理完，上传结果，工单自动进入已完成状态。整个过程在系统里一目了然，谁在处理、卡在哪一步，不用再群里吼一圈。

这里要提醒一个常见坑：很多人一开始会把工单系统和CRM分开采购，结果客户信息在CRM里，工单又在另一个系统里，两边数据对不上。我们在设计的时候特意把工单和客户档案做成了关联关系，同一个客户下面可以看到所有历史服务工单。后续做老客户回访和复购分析的时候，这个关联关系帮了大忙。

2.4 永久在线网站：数据在自己手里，访问不受平台限制

DeskcommCRM做成了永久在线的网页端，这是当时经过了一番考虑后才确定的方案。第一个考量是数据归属，系统部署在公司自己的服务器上，客户资料、成交金额、沟通记录这些核心数据不经过第三方SaaS平台，商业机密外泄的风险更小。第二个考量是访问便利性，网页端打开浏览器就能访问，不需要安装客户端，Windows、Mac、手机浏览器都兼容。第三个考量是可以绑定独立域名，比如crm.company.com，对外显得专业，客户也可以通过公网链接看到部分被授权的项目进度。

“永久在线”的反面其实就是很多免费CRM的坑。免费产品可能哪天调整政策、停止服务、限制导出，甚至直接把非付费用户的某些功能砍掉。自建系统只要服务器续费稳定，系统就一直在线，数据导出权限完全由自己控制，这才是“永久”的真正含义。

3. 实操部署：从0搭建 DeskcommCRM 的完整过程

很多人一听自建CRM就头大，觉得这是程序员才能干的事。其实现在部署一套开源系统门槛已经很低了，关键步骤比想象中少。我当时用的方案是基于Linux + Nginx + MySQL + PHP环境部署，再根据团队需求改字段和模板。下面按步骤记录一下实际操作，给有同样想法的人一个参考。

3.1 服务器和域名准备

服务器我选了2核4G的云服务器，操作系统用的CentOS 7。这个配置支撑二十人以内的小团队完全够用，高峰期同时在线不卡。数据库用的MySQL 5.7，Web服务器用的Nginx，后端语言选了PHP，主要原因是生态成熟、网上资料多，遇到问题好搜到解决方案。

域名方面建议使用独立域名，比如crm.company.com。域名买好后，在云服务商的DNS管理后台添加一条A记录，指向服务器IP，解析生效一般几分钟到几小时。这个步骤不复杂，但很重要，后续启用HTTPS和发送邮件通知都要用到域名，所以不要省略。

3.2 安装Web环境

我用的宝塔面板来管理服务器，图形化界面操作Nginx、MySQL和PHP的安装，省去很多手工命令行配置。有人觉得面板不够“专业”，其实生产环境只要做好安全配置，面板一样可以很稳定。我自己的原则是：用工具是为了省事，不是为了炫技。

步骤如下：

• 安装宝塔Linux面板，安装完成后进入后台。
• 在软件商店安装Nginx 1.22、MySQL 5.7、PHP 7.4。
• 创建网站，绑定crm.company.com，根目录指向 /www/wwwroot/deskcomm。
• 创建数据库，库名deskcomm，账号密码单独设置，不要用默认的root账号。
• 上传源码包到网站根目录，解压。
• 浏览器访问安装向导，填写数据库信息，完成安装。

整个流程大约半小时。需要特别提醒的是：服务器SSH默认端口22和宝塔面板默认端口建议都改掉，再配上复杂的登录密码或密钥登录，不然很容易成为扫描攻击的目标。

3.3 启用HTTPS和永久在线配置

没有HTTPS的网站打开后会提示不安全，销售和客户都不敢登录。我用宝塔面板申请Let's Encrypt免费证书，或者用云服务商提供的免费SSL证书，都是一键部署。启用HTTPS后，还要开启HTTP自动跳转到HTTPS，这样访问http://crm.company.com时也会自动变成https，避免用户打开错误地址。

“永久在线”还有一个很容易被忽略的环节：云服务器一定不要随意关机或释放公网IP，尤其是包年包月的实例到期要记得续费。服务器是系统运行的基石，这方面的成本不能省。另外一定要配置定时自动备份数据库，我每天凌晨3点执行一次备份，命令大致是：

mysqldump -u deskcomm_user -p deskcomm --single-transaction --quick --lock-tables=false > /backup/deskcomm_$(date +%F).sql

配合crontab定时任务，备份文件保留30天，基本能应对绝大多数故障场景。记住，数据库备份不是可选项，是必选项。

3.4 员工账号邀请与权限分配

DeskcommCRM的员工管理模块主要做两件事：开通账号和分配权限。

开通账号时，管理员在后台添加员工的邮箱或者手机号，系统会给对方发送邀请邮件。同事点击邮件里的链接，设置自己的登录密码，然后就可以登录系统了。这个方法也适用于常见的SaaS产品里“如何邀请员工”的需求，逻辑都一样：管理员添加成员，系统自动发邀请链接，不需要管理员手动去一个个告诉初始密码。

权限方面我们分了三个层级：

• 管理员：查看所有客户、工单、报表，修改系统配置，管理员工账号。
• 主管：查看所辖团队名下的客户和跟进记录，不能修改系统配置。
• 普通成员：只能查看自己名下的客户和自己参与的工单。

这里要提醒的是，权限分配不能一刀切。把客户可见范围设置得太死，主管没法及时发现问题；设置得太开，普通销售会看到其他同事的敏感客户信息。我们的经验是：客户创建者和被分配跟进权限的成员可见详情，主管可以看整个团队的汇总和明细，管理员兜底。

3.5 数据迁移：把Excel里的客户搬进系统

老客户数据是最重要的资产，必须稳妥迁移。我们当时有一个Excel文件，里面有四千多条历史客户记录，字段和系统初始字段不完全对应，所以我写了一个PHP脚本读取Excel，调用系统API批量导入。如果没有开发能力，也可以使用后台的CSV导入功能，但要注意编码问题，最好把文件另存为UTF-8格式，否则导入后中文会乱码。

迁移前一定要做数据清洗。比如手机号有+86前缀的、有空格的全部统一格式；重复记录按公司名称去重；空值字段先填一个默认值。这些活看起来繁琐，却直接决定系统上线后统计报表的准确性。我见过有人跳过清洗直接导入，结果同一客户出现三四遍，后面合并不说，还影响对客户总量的判断。

3.6 数据同步与多端访问

其实DeskcommCRM还有一个经常被忽略的细节：多端访问的体验。虽然系统是网页端，但在手机浏览器上打开时，如果没有做响应式适配，按钮会变得很小，点起来很费劲。我们后来给前端模板做了一套基础移动端样式，销售在手机上录入跟进信息时顺畅多了。

另外就是企业微信或钉钉的消息通知。我当时接了一个简单的Webhook，在系统里创建跟进任务时，会通过企业微信机器人推送到对应的销售群里，提醒大家“今天有X个客户需要跟进”。这个功能在真正落地的时候很实用，因为系统再强大，如果销售不主动打开后台，提醒还是送不到人眼前。

4. 免费CRM、私人网站与自建系统：到底有什么区别，怎么选

这一章节专门回应一个很多人在搜索引擎里反复问的问题：“免费CRM与私人网站的区别在哪”。其实这个问题的背后，藏着的是对免费工具能不能长期用、数据是否安全、服务会不会突然中断的担心。我自己的结论是：免费CRM适合业务还没有完整闭环的阶段用来试水，一旦业务开始稳定产生收入，最好尽早把客户数据放到自己可控的系统中。

4.1 免费CRM的隐形代价

免费CRM看起来零成本，但关键问题在于数据所有权和服务可持续性。多数免费版本会在数据量、用户数、导出权限、高级功能上做限制，比如数据量到一定规模后无法继续新增、导出Excel需要人工审核、历史记录保存时长受限。另外免费产品总要有盈利模式，有的通过展示广告流量变现，有的会把非付费账户的营销线索用于自身推广，这些都是你无法控制的。

更现实的问题是“永久在线”这个承诺并不可控。以前也有一些免费CRM产品停止运营或者改变免费策略，用户在平台里的数据被迫迁移。不是说所有免费产品都不能用，而是用它必须有心理准备，最好定期导出备份，别把免费当作永久。

4.2 私人网站（自己买域名建的站）的优势与坑

私人网站本质上就是自己买域名、租服务器、搭建系统。优势很明显：数据在自己手里，页面内容、业务流程、字段配置都可以按自己的意图来改。我们对数据字段和审批流程有比较特殊的定制需求，SaaS产品通常只允许固定流程，想改一个按钮、增加一个状态都要等官方排期，自建系统虽然前期投入多一些，后面改起来真的顺手。

缺点也同样明显：技术门槛和维护责任。服务器宕机、数据库损坏、被黑客扫描攻击，这些事在SaaS平台里由服务商替你扛了，自建以后就得自己面对。我们没有专职运维人员，所以系统尽量做得简单、稳定，备份策略和恢复演练一定要先想清楚，否则别贸然自建。

4.3 成本对比：真实账本

我们把不同的方案摊开算过一笔账，以三年使用周期为例：

这里还没有算人员时间成本。如果团队里完全没有人懂服务器和基础运维，自建的学习曲线会相对陡峭。但如果像我这样，只要愿意花一个周末把手册过一遍，后续日常维护并不费太多精力。两年左右，自建成本就能追平商业SaaS，后面都是省下来的。

4.4 怎么引导员工使用，避免系统“建而不用”

系统搭好了，最大的难点是员工不用。当时我们总结了几条比较有效的经验：

• 强制要求：新客户不允许记录在个人Excel或微信里，必须录入系统，否则不算业绩。这招最直接，逼着大家养成习惯。
• 简化操作：把常用菜单放到首页，跟进记录按钮尽量少点击两次，让录入的路径短一点。
• 管理层带头：主管每天看系统里的跟进数据，跟进记录明显偏少的单独沟通，不要等月底再秋后算账。
• 正向激励：在系统里做了一个“本月跟进之星”的小排名，周会公开表扬，团队氛围马上不一样。

工具永远是给人用的。如果员工不买账，再牛的CRM也是一堆代码。所以前期哪怕牺牲一些管理字段，也要保证录入方便，先让数据流动起来，再慢慢完善维度。

5. 常见问题与排障实录

部署和运营DeskcommCRM大半年，踩了不少坑。我把几个有代表性的问题和解决办法记录在这里，希望能帮你省点时间。

5.1 员工录入懒散，数据质量差

现象：系统上线前两周，录入系统的客户量不到Excel里的三分之一，跟进记录大多是“电话沟通”四个字，没有任何细节。

排查后发现不是系统难用，而是销售觉得录入是额外工作，能省则省。我们做了两个调整：一是把跟进记录模板的必填项压缩到三行，分别是沟通内容、客户反馈、下一步动作；二是把客户标签做成点选式，不用销售手动打字。一个月后数据质量明显提升。

5.2 客户重复，撞单仲裁难

现象：同一个客户被两个销售同时创建，做活动通知时会重复打扰客户，引起反感。

解决方法是增加查重规则，按手机号进行去重，创建重复客户时系统弹出警告；如果管理员确认是同一个客户，可以合并档案，两个销售名下的跟进记录会合并到一起。为了从源头上减少重复，我们还规定销售在创建客户前必须先搜索确认，这条规则写进了团队流程。

5.3 服务器被扫描攻击

现象：运行两周后，查看Nginx访问日志，发现有大量境外IP在尝试登录后台，还有人扫描安装脚本路径。

处理思路是三层加固：修改管理后台入口路径，不用默认的admin，改成随机字符串；在服务器防火墙里限制公司固定IP才能访问后台管理页面，普通登录地址也加上验证码和登录失败次数锁定；关闭文件上传目录的执行权限，防止有人上传恶意脚本。处理之后攻击请求明显减少。

5.4 数据库备份恢复演练

很多人备份完就不管了，真到恢复的时候才发现脚本有问题。我每个月会在测试机上做一次恢复演练：用最新的备份SQL导入新数据库，用测试域名跑一遍，确认数据完整。这个方法帮我发现过好几次备份文件异常的问题。有一次备份失败的原因是MySQL导出时锁表，导致SQL文件不完整，还好提前发现了，不然真到故障恢复就麻烦了。

5.5 系统变卡，数据库连接被打满

现象：月底导出销售报表时，系统突然变得很慢，数据库连接数飙满。

排查后发现是有一个统计页面写SQL时没加索引，全表扫描导致CPU飙高。后来给客户表、跟进记录表加了联合索引，优化了列表查询逻辑，系统恢复了流畅。这个问题的经验是：小团队用的MySQL，数据量过万后就要开始注意索引和查询优化，别等卡了才改。

6. 一些实战心得和扩展可能

用了这半年，我最大的感受是：CRM能不能落地，七成靠管理，三成靠工具。工具再强大，没有数据也分析不出结果；反过来，光有数据但没有自动化的提醒和看板，系统也只是Excel的网页版。

从技术上讲，DeskcommCRM还有很大的扩展空间。我准备在下一阶段接一个企业微信消息推送，客户发消息时系统能自动提醒负责人，并把聊天记录同步归档；另外打算做一个销售漏斗看板，把“意向等级”和“最近跟进时间”综合成预警分值，超过一定时间没有跟进的客户自动推送给主管，避免销售漏单。

最后分享一个让我印象很深的小事。有一个客户从去年咨询到今年四月份才签合同，中间经历三个销售跟进。如果还是用Excel，很多沟通细节早就丢了。因为系统里的跟进记录完整，接手的新人能很快判断客户最在意的点是什么，报价和方案都做得更有针对性，最终成交也比预想顺利得多。这大概就是做CRM项目最有价值的时刻了。