我一开始做DeskcommCRM这套系统的时候其实没想过它会变成现在这种“永久在线”的状态。那会儿团队刚起步客户资料散落在每个人的微信好友、Excel表格和笔记本里谁跟进到哪一步全靠问离职一个人就等于丢了一串客户线索。真正逼我动手的是一天下午一个跟了三个月的重点客户因为同事休假没人接手硬生生泡汤了。那种憋屈感我到现在都记得。所以当我开始搭DeskcommCRM时核心就一件事让客户信息成为公司的公共资产而不是某个人的私人通讯录。这篇文章就把我从零搭建这套系统到正式上线运行期间踩过的坑、验证过的思路、以及那些常用文档里不会写清楚的细节完整地记录下来。不管你是想自己搭一套还是在选型上纠结这篇文章应该都能帮你少走不少弯路。1. 项目整体设计与核心思路拆解1.1 为什么叫DeskcommCRM以及它解决的是什么问题名字里的Deskcomm其实来自Desk Communication也就是“桌面沟通”的意思。我在设计这套系统时一直在想一个问题客户关系管理的本质到底是管理关系还是管理沟通后来实践下来我的结论是关系是静止的标签沟通才是流动的资产。客户愿意跟你签单不是因为他在你数据库里有一条记录而是因为你们之间的每一次跟进、每一次报价、每一次需求确认都留下了有效的沟通痕迹。所以DeskcommCRM从一开始就把“沟通记录”放到了比“客户档案”更核心的位置。这套系统要解决的问题总结起来就是三个防止客户资源私有化所有跟客户的互动记录必须沉淀在系统里而不是留在员工微信聊天记录里。把跟进过程标准化每一个销售阶段都可视化谁在跟进、卡在哪一步、下一步该做什么一目了然。做到真正的随时可访问不仅公司内网能用我可以随时在手机上快速查看客户最新动态所以后来干脆部署成了常驻运行的在线服务。1.2 永久在线这个需求的由来你可能看到热词里有“永久在线的CRM网站”这个说法。这个需求不是我一个人有。本地部署CRM装了数据库、配了环境关机就打不开SaaS版的CRM数据在别人服务器上每年按人头收费用得越多越心疼。所以很多人会动念头能不能自己搞一个一直开着、随时能访问、数据完全在自己手里的CRM我的答案是能但你要想清楚“永久在线”这四个字的代价。永久在线意味着你有一台不关机的设备一个稳定的访问入口以及一套能自动恢复的机制。我在项目里选择了低功耗主机加内网穿透服务加定时备份的组合方案。如果公司没有公网IP也可以用反向代理方案——这两条路的细节我在后面的实操章节里展开。1.3 技术选型的取舍逻辑关于用什么技术栈来搭CRM网上众说纷纭。有人推荐低代码平台有人推荐PHP的经典开源系统有人推荐直接用SaaS。我的经验是不要一上来就比技术优劣而是先问自己三个问题团队里有谁能维护这套系统的代码数据量级大概会到多少未来最可能扩展的功能是什么我当时的答案分别是我自己能做二次开发、客户总数预计在1万以内、未来最可能需要自定义报表和对接企业微信。顺着这三个答案我选择了后端用Python的Django框架前端用经典的服务端渲染模板加少量JavaScript数据库直接用MySQL。虽然这套组合听起来不炫酷但它的优势是生态成熟、资料多、出了问题能找到人问而且Django自带的Admin后台可以让我在前期不写一行前端代码就完成数据管理。如果你只是想快速跑起来不想碰代码那也可以考虑成熟的低代码平台。但如果你跟我一样希望数据、字段、权限都自己说了算那就值得自己折腾一次。2. 核心业务模块拆解与数据模型设计2.1 客户档案与联系人分离设计CRM的第一个坑就是把客户和联系人混成一张表。我最初也这么干过后来发现一个公司有多个对接人的时候数据就会变得非常混乱。比如A公司有采购经理、技术负责人、财务三个人都跟你对接过如果客户和联系人不分开你每次记跟进都要纠结“这条记录该挂谁名下”。所以DeskcommCRM的数据模型里我设计了Customer客户公司和Contact联系人两张独立的表通过外键关联。客户表管公司级的信息比如行业、规模、来源渠道、所属销售联系人表管个人级信息比如姓名、职位、电话、微信、偏好。跟进记录则挂在联系人层面这样谁联系了谁、聊了什么全部能对上号。2.2 跟进记录的动态时间线前面说沟通是核心资产所以在实现上我特别做了“动态时间线”这个视图。每一条跟客户相关的记录无论是电话沟通、微信聊天、邮件往来、线下拜访都会按时间顺序刷在同一个页面上。加上一个双向时间筛选比如只看最近一个月过去半年的互动就会很直观。这个设计带来了一个直接的好处新接手的人不用翻聊天记录打开客户详情页上下滚一遍就能知道这个客户大概是什么情况。客户打电话来问“上次说的报价方案怎么样了”你也不用慌张地翻聊天记录点开时间线几秒钟就能找到上下文。2.3 销售阶段看板与待办提醒看板这个东西听起来像是销售团队的管理工具但实际上我觉得它对个人也极其有用。我把销售流程拆成了五个阶段阶段含义关键动作1. 初步接触已建立联系但需求还不明确记录来源补充完整画像2. 需求确认客户已明确提出需求录入需求细节评估匹配度3. 方案报价完成方案并发出报价记录报价金额、有效期4. 商务谈判双方在条件上博弈记录每一次让步与条件5. 成交/失单最终结果明确复盘原因归档继续维护这其实是一种数据归一化的思路。表达虽然简单但这套看板让我对团队的整体项目情况有了把握不再需要逐一私信询问。待办提醒我用了最简单的方式——基于状态的活跃值模型去标记到期事项。比如一个客户在“方案报价”阶段停留超过7天没有新跟进系统就会自动标记为“沉睡预警”提醒销售赶紧捞一捞。这个功能不需要多高深的技术一个后台定时任务加状态判断就搞定了但效果立竿见影。2.4 权限体系谁能看什么谁能改什么CRM系统最敏感的就是权限设计。权限给多了销售不敢记真实信息怕客户被同事抢走权限给少了管理者对全局失去掌控。我在DeskcommCRM里采用了“角色数据范围”的双层模型。第一层靠角色来控制操作权限。普通销售人员默认拥有“创建客户、跟进客户、查看自己创建的客户”的权限销售主管额外拥有“查看部门所有客户、分配客户、导出报表”的权限管理员则拥有全部权限包括修改系统配置、管理用户账号、删除数据等。第二层靠数据范围来控制可见性。我允许每个客户记录标记为“私有”或“共享”。私有线索只有创建人及其直属主管可见共享线索全公司成员可查看但修改权限仍然受角色限制。这套机制的实现在Django里其实就是用了一个检查用户角色和记录归属的中间件。你不需要特别复杂的逻辑但一定要在设计表结构时就把owner字段和team字段提前规划好否则后期加权限会非常痛苦。3. 实操过程从代码到永久在线的完整搭建记录3.1 环境准备与基础配置我建议选择一台不关机、低功耗的设备。我一开始图方便用了一台日常办公的台式机结果每逢下班断电CRM就跟着下线后来才专门换成低功耗主机24小时运行实测功耗在10瓦左右一个月电费几乎可以忽略。操作系统我选了Ubuntu 22.04 LTS。装好系统后第一件事是执行系统更新把curl、git、build-essential这些基础工具装好。然后安装Docker因为后续的数据库和反向代理服务都准备用容器来跑这样可以避免污染宿主机的环境和污染我自己的Python环境。注意如果你打算在同一台设备上既跑CRM又做其他事情强烈建议用Docker隔离服务。否则一旦环境冲突你要花好几个小时来排查真的得不偿失。3.2 Django项目的初始化和数据模型落地我把代码放在/opt/deskcomm目录下用虚拟环境创建了一个独立的Python环境。核心依赖是Django、djangorestframework、mysqlclient、django-cors-headers、gunicorn。创建项目后我开始定义最核心的模型类。以下是Customer模型的简化版本from django.db import models class Customer(models.Model): name models.CharField(客户名称, max_length255, uniqueTrue) industry models.CharField(所属行业, max_length128, blankTrue) source models.CharField(来源渠道, max_length64, blankTrue) level models.CharField(客户等级, max_length16, defaultA) owner models.ForeignKey(auth.User, verbose_name负责人, on_deletemodels.SET_NULL, nullTrue, blankTrue) status models.CharField(销售阶段, max_length32, default0) created_at models.DateTimeField(创建时间, auto_now_addTrue) updated_at models.DateTimeField(更新时间, auto_nowTrue) class Meta: db_table crm_customer verbose_name 客户公司 ordering [-updated_at] def __str__(self): return self.name跟进记录我差不多也是这样定义的核心字段是customer外键、contact外键、content内容、next_follow_date下次跟进日期。这里我特别加了一个next_follow_date字段它是待办提醒功能的数据基础。每次跟进时销售必须填一个下次跟进日期否则这条记录不保存。联系方式这块我设计了ContentType的通用外键方便未来扩展。但说实话早期项目不建议一上来就用通用外键虽然灵活但查询效率和控制逻辑都会变复杂。我后来为了省事改回了显式字段。3.3 数据迁移与后台配置Django有一个好处就是内置Admin后台。模型定义完之后执行makemigrations和migrate然后在admin.py里把Customer和Contact注册进去后台界面就自动出来了。对这个阶段的快速验证来说省了我不少时间。我当时顺手写了一个给Admin后台批量导入客户数据的功能。如果你是从Excel表格迁移过来可以用Django的管理命令批量导入。核心代码是一个Management Command读取CSV文件逐行创建Customer和Contact记录。这里有一个坑导入前一定要去重否则unique约束会炸。我在脚本里加了按名称去重的逻辑遇到重复则跳过并在日志里标出来。3.4 对外页面与API接口虽然Admin后台能用但给销售团队用的话还是得做一个像样的操作界面。我用了一个轻量型的模板方案页面不多核心就是客户列表、客户详情、跟进记录录入、销售看板这四块。前端架构不复杂用Bootstrap加一点jQuery数据接口用Django REST Framework提供。API接口我主要设计了这么几个GET /api/customers/ 获取客户列表支持按阶段、负责人筛选 POST /api/customers/ 新建客户 GET /api/customers/{id}/ 获取客户详情含跟进记录时间线 POST /api/followups/ 新增跟进记录 PUT /api/customers/{id}/ 修改客户信息或销售阶段接口的权限控制就是用Django REST Framework的permission_classes和过滤函数实现的。普通销售只能操作自己创建的客户主管可以看整个小组逻辑不复杂但要想清楚每个接口的可访问范围。3.5 内网穿透与永久在线的实现这就是“永久在线”的关键一步。我采用的是“云服务器反向代理家里主机内网穿透”的组合方案。具体来说我有一台云服务器公网IP是固定的上面部署了一个Nginx作为反向代理监听80和443端口。家里的低功耗主机上跑着一个内网穿透客户端主动建立到云服务器的加密隧道。外部访问请求到达云服务器后Nginx将请求转发到隧道再穿透到家里的CRM服务。在云服务器的Nginx配置文件里我加了这样一个server块server { listen 80; server_name crm.example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }家里的穿透客户端我用的是开源工具frp。frpc.ini配置[common] server_addr 你的云服务器IP server_port 7000 [crm] type tcp local_ip 127.0.0.1 local_port 8000 remote_port 8080这样设置的好处是就算家里的主机IP变了也不用改配置用户访问的始终是云服务器上的域名。坏处是你需要多维护一台云服务器。如果你没有云服务器也可以用现成的内网穿透服务但免费版稳定性参差不齐核心商业数据不推荐走免费通道。3.6 HTTPS与日常备份策略永久在线不只是能访问还得安全。我在云服务器上用certbot给域名签了免费的HTTPS证书这样所有数据传输都是加密的客户手机号、微信这类隐私信息不会明文暴露在网络上。备份是我踩过坑之后才认真做的。以前我觉得数据量小不备份也没事。结果有一次由于我自己手滑误删了一张表气得差点抽自己巴掌。从那之后我写了一个简单的备份脚本每天晚上3点自动把MySQL数据导出成SQL文件再压缩后传到云服务器上一个专门的备份目录。脚本核心就一行mysqldump -u root -p你的密码 deskcomm_crm | gzip backup_$(date \%Y\%m\%d).sql.gz然后再加一条Cron任务每天自动执行。这个习惯长期坚持下来让我心里踏实很多。说句实话数据备份这件事宁可每天多做一次也别在丢数据的时候后悔一次。4. 常见故障排查与运营心得4.1 无法访问的排查顺序“CRM打不开了”是我接到最多的反馈。我的排查顺序是有讲究的千万不要从最底层开始瞎猜。第一步先从外网试试域名是否通。如果完全不通大概率是云服务器、隧道或者家里的网络出了问题。第二步检查家里的低功耗主机是否在线。因为停电、断网、主机死机都会让它失联。第三步远程登录到主机上先访问本地的8000端口。如果本地可以访问说明Django服务正常问题出在隧道如果本地也打不开说明Django或数据库挂了。第四步重启Gunicorn服务再检查MySQL是否正常不行就查看日志文件。我现在的建议是给云服务器配一个监控告警只要域名响应超时就立刻收到通知这样就不用等销售来反馈问题了。而且这种“主动感知”能力其实是“永久在线”体验中非常关键的一环。4.2 数据重复导入与清理经验数据迁移时重复数据是最让人头疼的。我曾在Excel里复制粘贴时漏掉了一行导致一个客户在系统里出现了两次。后期跟进记录分散在两个重复账号里很麻烦。后来我写了一个清洗脚本按客户名称做分组统计凡是名称完全一样的保留id最小的一条把其余记录的跟进记录都迁移到保留的那条上最后删除重复项。这里必须提醒一点执行删除前一定要先把重复数据导出备份。具体到我的实践就是在清洗之前先导出全表SQL然后再操作。谨慎永远不会错。4.3 权限配置太宽松引起的尴尬有一次我临时把主管的角色权限改宽了结果主管能导出全公司的客户数据。虽然他没有恶意使用但这让我意识到权限的默认值必须是“最小够用”需要用的时候再临时调整用完立刻收回。我还加了一个审计日志功能记录所有导出操作、删除操作和权限变更操作。这个功能不复杂就是你建一张操作日志表在Django的模型save和delete方法里发一个信号把谁在什么时候做了什么记录下来就够了。有审计日志的好处是一旦出问题你可以追溯是谁在哪个环节动的数据。4.4 关于免费CRM与自建系统的一点体会热词里一直有“免费CRM与私人网站的区别”这类搜索我也被问过很多次。我的理解是免费的CRM用来看自建的CRM用来养。免费CRM往往多人共用一个数据库数据属于平台能使用多少高级功能也需要看厂商脸色。自建CRM虽然要自己投入运维精力但数据完全在你手里字段、功能、权限都可以按你自己的业务流程来改。那到底该选择哪个我现在的建议是如果你的客户量很小比如两百个以内又是零成本试水先用免费版完全够。如果客户量开始上来了团队协作频繁数据敏感程度高那就别犹豫自建一条路最踏实。说到底CRM的价值不在软件本身而在于它能不能持续积累你的业务资产。免费工具帮你记录数据但数据不一定真正属于你。自建系统帮你把数据握在自己手里但需要你花精力去维护。4.5 邀请员工加入与使用习惯养成“怎么邀请员工使用”这个问题我也被问了无数次。我的经验是别一上来就强调制度强迫大家每天填跟进。你先让他们用一周只做一件事——打开系统录入一条跟客户的沟通记录。一周后把系统里自动生成的客户时间线展示给他们看他们看到这个客户从第一次接触到最近的互动全部串在一起体验完全不一样。还有个细节我给每个新员工设置账号时会预先帮他创建好他手上的几个重点客户让他一登录就能看到自己熟悉的数据而不是空白页面。这个“低启动成本”的设计对系统推行效果影响很大。5. 后续扩展思路与我的几点心得DeskcommCRM运行了小半年稳定性已经不错了。后续我打算加的功能有两个一个是客户公海池规则是超过30天没有跟进记录的客户自动退回公海池其他销售可以认领另一个是简单的数据看板按周、月统计每个销售的跟进数量和转化率老板看一眼就能掌握全局。实现前一个功能只需要在之前的“沉睡预警”定时任务里把状态改成可重新分配就行。实现后一个功能也只需要在现有数据模型上做聚合查询。所以架构稍微留一点余地就能省下很多后面的麻烦。最后说几点我自己的体会第一别把CRM做成监控工具。一旦销售人员感觉系统是用来考核他的他就会抵触、少填、虚填。我这边强调系统的定位是“帮你不忘事、帮你快速了解客户情况的助手”而不是“用来检查工作的监控器”。这个定位从设计到执行都要贯穿否则系统会死在推行阶段。第二任何自动化操作都要留一个手动兜底的口子。比如自动定时任务把用户标记为沉睡但如果你判断错了要能一键取消。第三客户数据是公司的数字资产这句话不是口号。你把它备份好、权限设计好、操作日志记录好将来不管是做数据分析、二次营销还是团队扩张都会非常省心。如果你也正在犹豫要不要自己搭一套CRM我的经验是别追求一步到位先用最小闭环跑通客户管理、跟进记录、阶段看板这三个核心功能然后根据自己团队的真实使用反馈再迭代。当你打开系统能一眼看清所有客户的最新状态、随时找到任何一个客户的历史沟通记录时你会觉得之前折腾的那些服务器、代码和时间都特别值。
