做CRM系统的这些年我越来越确信一个判断一个CRM好不好用第一眼看的不是功能列表而是打开速度和管理员的脑子清不清楚。这个项目叫DeskcommCRM是一套面向销售团队与小微企业的客户关系管理系统。我把它做成永久在线的Web站就是要让销售人员在客户楼下掏出手机就能录入跟单记录让老板在任意一台电脑上打开浏览器就能看到线索转化漏斗而不是回到办公室补Excel表格。文章里我不会只贴功能清单我会把我自己踩过的坑、设计时的取舍、部署时的细节一起写出来适合正在选型CRM的团队也适合准备自己动手做一套内部工具的开发者参考。1. 需求与观察销售团队为什么离不开CRM1.1 从Excel到CRM痛点在哪个环节很多团队一开始管客户都是用Excel一张表装下所有客户运气好的分几个Sheet运气差的就一列一列往下堆。团队两三个人的时候这套模式勉强能转一旦超过五个人问题马上暴露A销售录入的客户B销售看不见老板要统计本周新增线索得等大家把文件发到群里离职销售带走一张表公司客户资产直接蒸发。我做DeskcommCRM的起点不在“功能要全”而在“状态要透明”。我见过太多团队买了一套功能复杂的系统用了一周就吃灰原因不是系统不好是销售根本没有动力录入。要让他们持续用就必须把“记录”变成“顺手的事”把“查询”变成“比翻Excel快”。所以这个系统在立项的时候优先级排在前面的是录入体验、跟进状态自动流转、以及老板一眼能看懂的报表而不是先堆一堆花哨但没人用的模块。1.2 DeskcommCRM核心功能模块怎么划分站在实际使用者的角度我只保留了几块真正高频的模块任何多余的功能在早期都会变成学习成本。客户管理是地基每条客户记录包含基础资料、来源渠道、当前阶段、负责人和最近跟进时间。线索管理负责承接来自官网、转介绍、展会等不同渠道的原始联系人销售认领后可以转化成正式客户。跟单动态是整个系统价值的集中体现每次电话、拜访、微信沟通都记录成一条时间线后续接手的人点开客户详情就能看到完整历史。公海池机制很关键超过N天未跟进的客户自动掉入公海其他销售可以捡起重新跟进这一条规则解决了很多团队客户资源被私藏的问题。最后是统计看板按销售维度、渠道维度、时间维度看线索转化率与客户分布老板不用问别人自己打开就能看到全局。这套划分思路的核心是“状态驱动”客户不再是一行休眠数据而是带着明确阶段和下一步动作的有生命对象。每个字段、每个按钮都在为“让下一次跟进有依据”服务。1.3 永久在线的含义不只是一个网址很多团队以前也用过单机版CRM管理员在自己电脑上装一套别人要访问就得开着这台电脑人一出差整个系统就瘫痪。所谓的永久在线不是简单地把程序放在服务器上它意味着全年无休销售凌晨出差回来想补记录也能打开多端适配手机、平板、电脑通过浏览器访问不需要安装任何客户端权限集中管控人员变动在线调整离职交接不依赖把文件发给谁数据集中存储统一备份不再出现客户信息分散在个人硬盘上的情况。永久在线的背后是工程问题进程要常驻、数据库要定期备份、服务器重启后要自动拉起服务、前端要适配各种屏幕尺寸。这些细节会在第3部分详细拆解。2. 技术选型与设计逻辑为什么这么搭2.1 技术栈选择背后的考量DeskcommCRM的技术栈不是什么新奇玩意儿恰恰相反我刻意选择了更稳妥、更成熟、社区资料非常密集的组合因为系统要承载业务数据稳定压倒一切。后端使用Python的FastAPI框架原因有几个。第一异步性能足够CRM这种以增删改查为主的业务系统并发压力并不极端FastAPI的吞吐量完全够用。第二PyDantic提供了类型校验和自动API文档这对团队协作非常有帮助前端拿到Swagger文档就能直接联调省去大量沟通成本。第三Python的生态让后续扩展报表分析、导出Excel、对接企业微信这类功能都方便。前端使用Vue 3加Element Plus。Vue的响应式开发体验对表单密集型的CRM系统很友好Element Plus的表格、表单、弹窗、日期选择器这些组件开箱即用不需要从头造轮子。这里我特别说一句很多团队做内部系统上来就搞微前端、搞设计系统真没必要。CRM的核心场景是表单录入和数据展示组件库的成熟度比炫技重要得多。数据库选用PostgreSQL这一点我也是经过对比后确定的。MySQL当然也能做但PostgreSQL在复杂查询、JSON字段处理、行列统计上的能力更强。CRM系统里典型的按负责人分组统计、按渠道维度筛选线索、按时间段聚合跟进记录这些SQL在PostgreSQL里写起来干净利落。同时PostgreSQL的数组类型、全文检索也能为后续扩展搜索功能提供便利。2.2 数据模型设计的一个实用示例很多人觉得数据表设计就是建几个字段真正做过业务系统才发现表结构的设计深度直接决定了后续代码好不好写。我拿客户表举例这是DeskcommCRM项目里我改动次数最多的一张表。CREATE TABLE customers ( id BIGSERIAL PRIMARY KEY, name VARCHAR(100) NOT NULL, phone VARCHAR(20), org_id BIGINT NOT NULL REFERENCES organizations(id), owner_id BIGINT REFERENCES users(id), status VARCHAR(20) NOT NULL DEFAULT new, source VARCHAR(30), level VARCHAR(10), address TEXT, remark TEXT, last_followed_at TIMESTAMPTZ, next_follow_at TIMESTAMPTZ, created_at TIMESTAMPTZ DEFAULT now(), updated_at TIMESTAMPTZ DEFAULT now() ); CREATE INDEX idx_customers_owner ON customers(owner_id); CREATE INDEX idx_customers_status ON customers(status); CREATE INDEX idx_customers_next_follow ON customers(next_follow_at);几个关键点仔细说一下。org_id字段隔离了租户数据哪怕系统同时给多个团队使用数据也不会串。owner_id记录了当前负责人它和org_id一起构成了查询时的天然分区边界。status字段保存生命周期状态从new到following到won再到lost系统里所有的统计报表都围绕这个字段做聚合。最容易被忽视的是next_follow_at字段我建议所有做CRM系统的人都把这个字段加上。公海规则、到期提醒、待办列表全部依赖它没有这个字段系统就得反复扫描全表比对跟进记录不仅慢逻辑也容易出错。字段设计上有一个原则把高频查询条件索引化。只要是出现在where条件里的字段就必须评估是否需要索引。业务量小的时候感觉不到数据量上来之后一个缺失的索引会导致页面秒级响应变半分钟超时。2.3 权限设计老板和销售的边界CRM系统的权限做不好后台垮一半。DeskcommCRM的权限模型并不复杂但边界清晰。我采用RBAC加数据范围双重控制。角色有超级管理员、管理员、销售主管、销售顾问。超级管理员有系统全部权限管理员可以配置员工和客户阶段销售主管能看自己团队的数据销售顾问只能看到自己名下的客户和公海池里的客户。数据范围才是CRM权限设计的核心。同一张客户表不同角色看到的是不同的行。这不是前端隐藏按钮能解决的必须在后端查询层强制注入数据范围过滤条件。比如销售顾问查询客户时后端会自动拼上owner_id current_user.id或者status public的条件。这个逻辑写在获取当前用户的依赖函数里所有接口统一调用不留给业务代码去碰运气。这里我踩过一个教训最初版本为了省事数据范围过滤散落在各个路由函数中结果总有几个接口漏掉。后来把所有涉及客户列表的查询都收敛到一个统一的筛选函数才彻底解决数据越权问题。权限设计宁可早期多花点时间也别上线后收拾漏洞。3. 实操过程从零搭一个永久在线的DeskcommCRM3.1 环境准备与项目初始化先交代服务器环境。一台2核4G的云主机就能带动一个中小团队的CRM日常使用操作系统是Ubuntu 22.04Python 3.10PostgreSQL 15Node.js 18。数据库与后端服务部署在同一台机器上早期团队完全够用等并发量上来了再把数据库拆到独立机器即可。项目结构采用前后端分离目录如下deskcomm-crm/ ├── backend/ # FastAPI 应用 │ ├── app/ │ │ ├── api/ # 路由层 │ │ ├── core/ # 配置与安全 │ │ ├── models/ # 数据库模型 │ │ ├── schemas/ # Pydantic模型 │ │ └── services/ # 业务逻辑层 │ └── requirements.txt ├── frontend/ # Vue 3 应用 │ └── src/ └── deploy/ # 部署脚本与配置初始化后端项目时先把依赖装好mkdir deskcomm-crm cd deskcomm-crm python3 -m venv venv source venv/bin/activate pip install fastapi uvicorn sqlalchemy psycopg2-binary pydantic-settings python-jose[cryptography] passlib[bcrypt] python-multipart依赖里每一行都不白装。SQLAlchemy做ORM映射python-jose处理JWT令牌passlib做密码哈希python-multipart用来处理表单上传。装完之后先用最简单的一个健康检查接口把服务跑起来。3.2 核心接口实现思路后端接口不追求多追求路径清晰、语义明确。我下面给一个客户创建接口的例子这基本上代表了整个系统的编码风格。from fastapi import APIRouter, Depends, HTTPException from sqlalchemy.orm import Session from app.core.auth import get_current_user from app.core.deps import get_db from app.models.customer import Customer from app.schemas.customer import CustomerCreate, CustomerOut router APIRouter(prefix/api/customers, tags[customers]) router.post(, response_modelCustomerOut) def create_customer( data: CustomerCreate, db: Session Depends(get_db), user Depends(get_current_user) ): customer Customer( org_iduser.org_id, owner_iduser.id, namedata.name, phonedata.phone, sourcedata.source, statusnew, next_follow_atdata.next_follow_at ) db.add(customer) db.commit() db.refresh(customer) return customer注意org_id和owner_id都来自当前登录用户而不是让前端传进来。这样设计是为了防止越权创建。请求经过get_current_user依赖解析出当前用户信息后续所有涉及数据归属的字段都以这个为准。客户列表接口要实现筛选和分页并且强制数据范围过滤router.get(, response_modelList[CustomerOut]) def list_customers( status: Optional[str] None, keyword: Optional[str] None, page: int 1, page_size: int 20, db: Session Depends(get_db), user Depends(get_current_user) ): query db.query(Customer).filter(Customer.org_id user.org_id) if user.role sales: query query.filter( or_(Customer.owner_id user.id, Customer.status public) ) elif user.role manager: query query.filter( Customer.owner_id.in_([m.id for m in user.team_members]) ) if status: query query.filter(Customer.status status) if keyword: query query.filter( or_( Customer.name.ilike(f%{keyword}%), Customer.phone.ilike(f%{keyword}%) ) ) total query.count() items query.order_by(Customer.updated_at.desc())\ .offset((page - 1) * page_size)\ .limit(page_size)\ .all() return items这个接口看上去简单但数据范围过滤、关键字模糊搜索、分页逻辑都齐了。关键点在于销售角色判断处这里会检查当前用户是普通销售还是主管不同角色执行不同的过滤逻辑放在统一的位置而不是散落在各个视图里这是CRM系统不越权的核心保障。3.3 部署上云让系统真正7x24小时在线开发完成只是第一步部署才是永久在线的关键。我使用Nginx作为流量入口把来自公网的HTTP请求转发到本机的uvicorn服务进程。这里我只讲几个最容易出问题的环节。先写Nginx配置server { listen 80; server_name crm.example.com; client_max_body_size 20m; location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { root /var/www/deskcomm-crm/dist; index index.html; try_files $uri $uri/ /index.html; } }这段配置里有两个容易踩坑的地方。第一是client_max_body_size如果团队上传的文件比较大不设置这个字段会导致大文件上传直接413报错。第二是try_files指令Vue单页应用使用的是history路由需要把所有的前端路由都回退到index.html否则刷新页面会出现404。服务进程的守护和开机自启用systemd来管理。创建一个服务文件保证服务器重启后CRM能自动拉起不需要人工登录去启动进程。# /etc/systemd/system/deskcomm-crm.service [Unit] DescriptionDeskcommCRM Backend Service Afternetwork.target postgresql.service [Service] Userwww-data WorkingDirectory/var/www/deskcomm-crm/backend ExecStart/var/www/deskcomm-crm/venv/bin/uvicorn app.main:app --host 127.0.0.1 --port 8000 Restartalways RestartSec5 EnvironmentPYTHONPATH/var/www/deskcomm-crm/backend [Install] WantedBymulti-user.targetRestartalways是核心配置。不管是程序崩溃还是服务器重启systemd都会在5秒后自动拉起服务。这一步做到了才算真正意义上“永久在线”的雏形。前端部署流程也顺手写一下避免遗漏。生产环境构建后把dist目录上传到/var/www/deskcomm-crm/dist再通过后端接口实现登录取令牌、存取用户信息、跳转路由。HTTPS证书用一般的免费证书就能搞定配合自动续期脚本基本不用人工干预。3.4 数据备份策略CRM系统的生命线做CRM数据备份这件事我吃过一次亏才总结出完整的方案。有一回数据库文件损坏幸好当时有每天凌晨的全量备份才找回了90%的数据。从那时起我把备份策略定为全量加增量全量每天一次保留近7天增量每小时一次保留近24小时。用crontab写定时任务核心命令就是pg_dump0 2 * * * pg_dump -U deskcomm -F c deskcomm_crm /backup/deskcomm_$(date \%Y\%m\%d).dump备份文件不能放在同一台服务器上。我习惯的做法是每天备份完成后用rsync把文件同步到另一台机器或对象存储里。防止服务器硬盘损坏连带备份文件一起丢。恢复流程也提前演练一次别等到事故出了才发现备份文件无法恢复。4. 免费CRM、私有部署与DeskcommCRM的真实区别4.1 免费SaaS CRM背后真正的成本最近总有人问我市面上像蝉鸣CRM、飞鱼CRM这种免费产品用着不也挺好为什么还要自己搭一套我的回答是要看团队的阶段和诉求。免费SaaS CRM解决的是从无到有的问题厂商把服务器、数据库、运维这些基础设施全部包办上线速度快这是它们的优势。但使用免费产品的同时有几个成本往往被忽略。首先是数据所有权客户资料存放在对方的服务器上数据导出是否顺畅、关闭账号后数据能否完整带走这些都是问题。其次是定制能力免费版的功能基本是标准的销售流程不同、管理方式不同系统不会迁就你只能你去迁就系统的逻辑。最后是隐性付费点免费用户多了自然会推增值服务某些高级报表、API接口、更多存储空间都需要付费解锁。不是说免费CRM不能用而是它适合业务模式偏标准、数据不敏感、预算有限的团队。一旦业务跑起来销售数据成为核心资产就必须重新考虑系统的可控性。4.2 自己搭建私有CRM站点数据在手心里才踏实“私人网站”这个说法不太准确更准确的叫法是“私有化部署”。DeskcommCRM采用的就是这个模式。所有数据存放在自己购买的服务器上客户资料、跟进记录、合同信息都归团队自己支配。系统的逻辑可以进行深度定制销售阶段改成自己公司的叫法公海规则改得符合自己的管理习惯这些需求自己动手就能实现。私有化部署也有门槛这也是很多团队犹豫的原因。需要有人懂Linux操作、数据库维护、基础的前端配置一旦系统出问题不能拨打客服电话只能自己查看日志。但随着低代码服务器管理工具的普及这个门槛在逐渐降低。2G内存的云主机就能跑起来后续数据库扩容、迁移也都灵活可控。我的建议是团队在5人以下、销售流程还很不稳定的阶段先用表格或者免费SaaS工具跑通流程是性价比最高的选择。当团队到了二三十人、销售流程已经形成固定打法的时候数据资产的价值就凸显了这时候私有化部署一套DeskcommCRM长期来看反而省钱省心。4.3 三种方案怎么选一张表看完我做一个常年的对比普通团队可以对照参考。对比维度免费SaaS CRM商业付费CRM私有化部署CRM上线速度极快较快中等需要几天部署数据归属平台方平台方团队完全掌控定制能力弱中等完全可定制使用成本免费或低付费按年付费服务器费用加维护成本技术门槛无较低需要有技术人员或学习意愿长期可靠性依赖厂商策略依赖合同自由度最高依赖自己运维从这张表可以看到没有绝对的“最好”只有“最合适”。DeskcommCRM在做的就是把私有化部署这条路走通、走顺让技术背景有限的团队也能轻松拥有自己的客户数据资产。5. 常见问题排查与运维实录5.1 会话与登录状态到底怎么保持CRM是业务系统不能每次刷新都让用户重新登录会话保持做不好销售用了想骂人。DeskcommCRM采用JWT加Redis双通道的方式。用户登录成功后后端签发一个有效期为12小时的access token同时后端把token的哈希存一份在Redis注销时直接删掉Redis记录实现立即失效。前端把所有API请求统一拦截在请求头里带上token。这里有个细节前端token存储建议放在内存变量里不放到localStorage防止恶意脚本读取到关键凭证。虽然刷新页面会丢内存token但配合refresh token机制可以做到无感续期整体体验还是很顺滑的。5.2 数据库连接数打满怎么办业务上线初期团队不大大家从来没想过连接数的问题。直到有一次大家同时打开报表页面数据库连接数瞬间打满页面全部卡死。当时查下来发现每个接口在查询时都新建了一个连接没有走连接池。解决办法很简单在SQLAlchemy创建引擎的时候配置连接池参数engine create_engine( DATABASE_URL, pool_size20, max_overflow10, pool_pre_pingTrue, pool_recycle3600 )pool_pre_ping这个参数非常推荐加上它会在每次从连接池取连接之前先测试连接是否存活避免取到已经被数据库断开的老连接。这套配置调完连接问题再没出现过。5.3 权限错乱的一个隐蔽原因权限这块我前面说了要统一收口再补一个实战案例。当时系统上线两周有销售人员反馈说能看到其他同事的客户列表。排查发现问题出在列表接口的数据范围过滤条件被一个细节漏掉了get_current_user依赖函数在处理某些请求头时解析出来的user对象没有role字段后续代码默认走了管理员的查询分支。这个问题的根子在于接口依赖了前端传来的一个用户角色字段而不是信任服务端通过token解析出来的用户信息。修复方式就是彻底删掉对前端传递用户身份字段的信任所有身份信息都从JWT里取。这算是一个很经典的越权漏洞也提醒了我CRM系统的权限口子一定要把死任何不该前端传的东西都不能传。5.4 销售在外网环境下打开系统慢怎么办系统虽然部署在国内云主机上但销售在外地出差访问速度还是会有波动。优化策略主要有三个层面。第一是静态资源走CDN前端构建后的js和css文件体积不小CDN能大大缩短加载时间。第二是图片和上传文件不存数据库改用对象存储访问时走独立域名。第三是接口层面只返回必要的字段列表接口不要一次查出所有大字段详情页需要时再单独请求。这套优化做完打开系统的速度体感提升非常明显。我建议做任何Web系统都把这些基础优化做在前面别等用户抱怨了才回头处理。5.5 公海规则引出的业务争议公海池这个功能开发起来并不难难的是规则怎么设置才能既保证积极性又不制造矛盾。我们早期把过期时间设置成3天结果有些销售干脆就等同事的客户掉公海然后捡现成的团队内部闹得很不愉快。后来把规则改成了阶梯制普通客户7天未跟进掉公海重要级别客户15天未跟进掉公海同时销售主动标记“持续跟进中”的客户可以自动延长保护期。加了这些业务约束之后系统体验顺畅不少。这也说明纯工具侧的开发只是基础真正有价值的CRM系统一定要能把团队的运营规则落到代码里。6. 我的一点后续扩展思路与经验DeskcommCRM做到现在主流程已经非常稳定。我后续最想做的一件事是把“跟进动态”模块做成自动化的线索温度计。目前系统已经记录了销售每一次跟进动作、每次通话时长、客户每次查看报价单的时间戳这些数据能提炼出客户热度分比如一周内有3次互动记录的高意向客户自动标星超过30天无任何互动的客户自动提示公海预警。发动机是现成的状态流转逻辑也能撑起来只需要在报表层多加几张统计视图。另一个想扩展的方向是企业微信集成。很多销售习惯用企业微信联系客户如果CRM能把聊天记录自动同步到客户的时间线下面销售连录入这一步都省了。这一步做起来工程量大一些但方向我很确定。最后分享一个成立至今最深的体会做业务系统功能做加法容易做减法很难。研发过程中会有无数人说“这个按钮加上吧”“这个字段加上吧”但每一个多余的功能都在稀释核心场景的体验。DeskcommCRM能一直保持轻快靠的就是不断回头审视哪些功能是真的每天在用。如果你也在做自己的客户管理系统不妨先用纸笔写下一线销售每天真正会打开哪些页面让系统围着这几张页面转后面的事都会顺很多。
入门实战：从环境搭建到CSV转Excel)
